DevStack LDAP plugin — Part 2
OpenStack Keystone domain with LDAP as identity back end
Following up with my previous post, about LDAP plugin for DevStack, both Keystone and LDAP server services should be running. Now the challenge is to integrate those services and make Keystone access LDAP to retrieve information about users of a specific domain. The goal here is to add another domain to Keystone, a domain that uses LDAP as identity back end.
Enabling multiple domains
First of all, let’s enable domain specific drives and multiple domains on both Keystone and Horizon. To do this add these two new lines under identity on etc/keystone.conf
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains
And, to enable multiple domains on Horizon, add the following line to horizon/openstack_dashboard/local/local_settings.py.
Configuring LDAP domain
Using OpenStackClient create a new Keystone domain by running the command
openstack — os-identity-api-version=3 domain create <your-domain-name>
Now to configure your new domain add a new folder to etc/keystone called “domains”. Inside this folder add a conf file with your LDAP domain configuration. The file should be named keystone.<your-domain-name>.conf and contain the following lines
driver = ldap
url = ldap://localhost
user = cn=Manager,dc=openstack,dc=org
password = <password>
suffix = dc=openstack,dc=org
user_id_attribute = uid
user_mail_attribute = mail
user_name_attribute = cn
user_objectclass = inetOrgPerson
user_tree_dn = ou=Users,dc=openstack,dc=org
group_id_attribute = cn
group_name_attribute = cn
group_objectclass = groupOfNames
group_tree_dn = ou=Groups,dc=openstack,dc=org
user_allow_create = False
user_allow_update = False
user_allow_delete = False
group_allow_create = False
group_allow_update = False
group_allow_delete = False
The domain component (dc), organization unit (ou) and common name (cn) configured should match the ones added to slapd by the ldap plugin. (You can check those values running an ldapsearch). As a LDAP domain should be read-only, we should disallow all user and group write actions (creation, update and deletion).
So far we have an extra domain on keystone and a domain configuration file inside etc/keystone/domains which sets the variables of a LDAP domain. It is important that the name of the domain created and the middle part of the file name are the same.
Binding Keystone and LDAP
Now we need to tell Keystone about the configuration file for its newly created domain. To do that we restart apache and keystone services, this should be enough to bind the domain and the LDAP server (slapd).
sudo service apache2 reload
sudo systemctl restart devstack@keystone
To test if everything went fine let’s add a new user to the LDAP service and check if keystone can retrieve it as one of its users. The process of adding a user will be done entirely on the LDAP server because, as mentioned before, the LDAP identity back end on Keystone is read-only.
Create a ldif file to hold your new user’s information, it can be called user.ldif, for example. Inside that file add these lines
Then run the following command
ldapadd -x -w <password> -D “cn=Manager,dc=openstack,dc=org” -H ldap://localhost -c -f user.ldif
This adds a new user called “demo” to LDAP. Now let’s check if Keystone can see the new user by running the command
openstack user list --domain <your-domain-name>
After trying to run this you might be prompt an error message about the need of authentication. If that’s the case, try and login to Horizon, download the OpenStack RC File v3 file and load it using source on your current shell window. Then, rerun the command above.
If you can see your user listed that means the integration was successful and you have got a domain with LDAP as identity back end.
The steps above allow you to add users to your Keystone LDAP domain. In order to interact with those users on Horizon they need to be assigned to a project and, hence, have a specific role.
Projects and roles should not be stored on LDAP, that’s only for users and groups. So we will assign the users on LDAP to SQL projects. (Note that the project should be created on or retrieved from the default SQL domain.)
project=openstack project create <project_name> --domain=default --or-show -f value -c id
user=openstack user show --domain=<your-domain-name> demo -f value -c id
role=openstack role create <role_name> --or-show -f value -c id
openstack role add $role --user $user --project $project
After running these commands you should be able to login as the LDAP demo user on your domain on Horizon.