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/


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

dn: cn=demo,ou=Users,dc=openstack,dc=org
cn: demo
displayName: demo
givenName: demo
objectClass: inetOrgPerson
objectClass: top
sn: demo
uid: demo
userPassword: demo

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.

Using Horizon

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.