Configuring OpenStack Identity for LDAP Integration

The OpenStack Identity service that we have built so far provides you with a functional, but isolated, set up for your OpenStack environment. This is a useful setup for Proof of Concept and lab environments. However, it is likely that you will need to integrate OpenStack with your existing authentication system. OpenStack Identity provides a pluggable authentication back end for this, with LDAP being the most widely used.

Getting ready

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Tip

You can use the controller node if no other machines are available on your network, as this has the python-keystoneclient and the relevant access to the OpenStack environment. If you are using the Vagrant environment, issue the following command to get access to the Controller:

vagrant ssh controller

Additionally, to connect to an external LDAP service, you will need to possess the hostname or IP address of the LDAP server and have appropriate access to the server. You will also need to have the LDAP path information for an admin user, and for the Organizational Units that contain the Users, Roles, and Tenants.

Note

We have provided a sample OpenLDAP server that is prepopulated with the required values as part of this book's supplementary materials, and instructions on how to use it located on our book blog at http://bit.ly/OpenStackCookbookLDAP

How to do it...

To configure OpenStack Identity to communicate with LDAP, perform the following steps:

1. Using your favorite editor, enable LDAP authentication in the keystone.conf file:

   [identity]
   driver=keystone.identity.backends.ldap.Identity

2. Next, create the ldap section and add the URL to your existing LDAP server:

   [ldap]
   url = ldap://openldap

3. On the following lines, specify the LDAP path for the admin user you will use, along with its password and the suffix, or where you would like Keystone to begin searching LDAP:

   user = cn=admin,dc=cook,dc=book
   password = openstack
   suffix = cn=cook,cn=book

4. In the same [ldap] section, we tell Keystone four pieces of information about how to find users. user_tree_dn specifies which OU within the LDAP tree to search for users. user_objectclass specifies how a user is represented within LDAP. user_id_attribute tells Keystone which property of the user to use as a username. Similarly, user_mail_attribute tells Keystone where to find the user's e-mail address. The code is as follows:

   user_tree_dn = ou=Users,dc=cook,dc=book
   user_objectclass = inetOrgPerson
   user_id_attribute = cn
   user_mail_attribute = mail

5. Next, add the same details for Tenants and Roles:

   tenant_tree_dn = ou=Projects,dc=cook,dc=book
   tenant_objectclass = groupOfNames
   tenant_id_attribute = cn
   tenant_desc_attribute = description
   
   role_tree_dn = ou=Roles,dc=cook,dc=book
   role_objectclass = organizationalRole
   role_id_attribute = cn
   role_member_attribute = roleOccupant

6. Save the file and restart keystone:

   sudo stop keystone
   sudo start keystone
   

How it works...

The OpenStack Identity service, like other OpenStack services, is based on plugins. In its default state, Keystone will store and access all user identity and authentication data from a SQL database. However, when integrating OpenStack into an existing environment, this is not always the most desirable or secure method. To accommodate this, we changed the identity back end to LDAP. This allows for integration with OpenLDAP, Active Directory, and many others. However, when configuring the backend, you need to pay special attention to the LDAP paths.

Note

Where are the entries for the services catalog? These are still stored in Keystone's SQL database, as they aren't specifically related to user identity or authentication.