Multiple LDAP Integration with Openstack Keystone

I've got a task to integrate Multiple LDAP with Openstack Keystone. Below are the same steps which you have to follow for External LDAP integration with Openstack Keystone also.

I followed below steps for the integration

1) Setup LDAP Servers

2) LDAP as Keystone Backend

3) Verification of Integration

4) Multiple LDAP integration for Openstack Keystone

1)Setup LDAP Server

As we are talking about multiple LDAP's. I'm going to tell how to setup 389ds and Openldap server creation and configuration on ubuntu 20.04.

Follow the steps from below link to set up 389ds LDAP server and create some users

https://www.niteshtech.com/post/389ds-ldap-server-configuration-and-user-creation

Follow the steps from below link to setup Openldap server and create some users

https://www.niteshtech.com/post/openldap-server-configuration-and-user-creation

2) LDAP as Keystone Backend

a) Add the below config data into keystone.conf

[identity]
domain_specific_drivers_enabled = true
domain_config_dir = /etc/keystone/domains

[assignment]
driver = sql

[role]
driver = sql

b) Initially create a domain using admin.rc

openstack domain create ldap_domain

c) Create a folder "domains" under /etc/keystone/

cd /etc/keystone/

mkdir domains

d) Create a keystone.ldap_domain.conf under /etc/keystone/domains

[identity]
driver = ldap

[ldap]
url = ldap://localhost:389
user = cn=external_ldap
password = #external_ldap@123
suffix = dc=openstack1,dc=org
use_dumb_member = False
allow_subtree_delete = False

# mapping to user/group tree dn
user_tree_dn = 'ou=users,dc=openstack1,dc=org'
user_objectclass = "nsOrgPerson"

user_id_attribute      = uidNumber
user_name_attribute    = cn
#user_mail_attribute    = mail
#user_pass_attribute    = userPassword
## user_enabled_attribute = userAccountControl
#user_enabled_mask      = 0
#user_description_attribute = openstackrole
group_tree_dn = 'dc=openstack1,dc=org'
#group_objectclass = "groupOfNames"

# read-only
user_allow_create = False
user_allow_update = False
user_allow_delete = False

group_allow_create = False
group_allow_update = False
group_allow_delete = False

Note: Fill in the details with your LDAP configurations

e) Restart the keystone service

systemctl restart devstack@keystone.service

3) Verification of Integration

Run the "openstack user list" command, it should the users which you have created in Step1.

openstack user list --domain ldap_domain

To authenticate and run the commands from ldap user follow the commands

i) Create a project for this ldap domain

openstack project create ldap_project --domain ldap_domain

ii) Add role for the ldap user under the above created project

openstack role add --user ldap_user1 --project ldap_project  --user-domain ldap_domain --project-domain ldap_domain admin

iii) Create a ldap_user.rc file

export OS_USERNAME="ldap_user1"
export OS_PROJECT_NAME="openldap"
export OS_AUTH_URL="http://localhost:5000/v3"
export OS_PASSWORD="ldap_user1"
export OS_USER_DOMAIN_ID=b3eb210a39da40768f2793dd0b9c2c1f
unset OS_USER_DOMAIN_NAME
export OS_PROJECT_DOMAIN_ID=b3eb210a39da40768f2793dd0b9c2c1f
unset OS_PROJECT_DOMAIN_NAME

iv) Source the newly create ldap_user.rc and list the users

source ldap_user.rc

openstack user list

It should list all the users of ldap servers

4) Multiple LDAP integration for Openstack Keystone

There are two main use cases for multi-domain LDAP with Keystone:

i) A cloud provider who wants to support multiple customers on their cloud, each of which wants to integrate with their own ldap servers.

ii) An enterprise wants to model their internal company structure around domains—for example, each division of the company might be a domain. Each of these divisions might have their own LDAP server, or perhaps a separate tree of users within a common company LDAP server.

In both cases, the first key issue for Keystone is how to hook different LDAP URLs (and other configuration options) to different domains. The domain definitions are stored in the Keystone Resource backend, but somehow the Identity backend needs to know on a domain-by-domain basis to which LDAP server to send the request. Most user and group API calls do not include a domain identifier, so that’s not so easy after all. One of Keystone’s functions for Identity is to be the source (for other OpenStack services) of a globally unique ID (for each user and group).

Repeat the Step 2 for configuring other ldap server and repeat Step 3 for verification of new ldap server integration

When domain-specific configuration files are enabled, each time Keystone is started it will scan the contents of domain_config_dir for any domain-specific configuration files. For each domain a domain-specific configuration file is required that contains the specific details of the ldap server for that domain. For example, if the service provider creates a domain called "openldap_domain" to represent that customer, then they create a domain-specific configuration file called keystone.openldap_domain.conf. (The name is important and is always of the form: keystone.{domain-name}.conf—the domain name must match the name of the domain created in Keystone.)

nitesh@nitesh-Dev-V:/etc/keystone/domains$ ls -lrt

-rw-rw-r-- 1 nitesh nitesh 776 May 4 16:58 keystone.external_ldap.conf

-rw-rw-r-- 1 nitesh nitesh 773 May 6 18:10 keystone.openldap.conf