This article is being updated. Please be aware the content herein, not limited to version numbers and slight syntax changes, may not match the output from the most recent versions of Bright. This notation will be removed when the content has been updated.
Here it is assumed that OpenStack was set up by Bright Cluster Manager 7.1 and is up and running.
The following steps describe the procedure needed to configure Keystone to use LDAP as a backend for user authentication, instead of MySQL.
The OpenLDAP that Bright Cluster Manager provides is used here, but the instructions can be made to work with any other standard LDAP server.
The end result is a Keystone deployment which authenticates users against LDAP. But it still uses its local MySQL database for authorization, storing info on roles, projects, assignments, etc.
Credentials Retrieval From Keystone
First, disable the CMDaemon integration with OpenStack with the following commands using cmsh on the head node:
Next, get the currently configured usernames/passwords for OpenStack service. Since we want keystone to authenticate against LDAP, this will also include authentication of OpenStack services.
The cmsh shell running on the head node can retrieve these pairs as follows:
Next step is to create OpenStack System users in LDAP using the credentials from the previous step. The users can be created by hand using cmgui or cmsh (Chapter 6 – User Management, Bright Cluster Manager administration manual. ).
By default you will want to recreate all of the OpenStack system users in LDAP in the same way they were before you started the process (users nova, glance, keystone, etc.). However, in principle it is also possible to create just one (shared) user for all the services (eg. cmd) and the a separate admin user. This is handy in case of name conflicts in LDAP (e.g. a user ‘nova’ already existing), or if for some reason administrator wants to limit the number of additional accounts in LDAP. If that’s what you will want to do, after determining the new username(s) for OpenStack services, and after creating those accounts in LDAP, you will have to upated the credentials for them services in CMDaemon. This can be done with cmgui in the Openstack menu’ -> Settings -> Credentials settings, or it can be done with cmsh as follows:
OpenStack services can then be enabled again with the following command:
Modifying Keystone To Use LDAP
The Keystone configuration must now be modified to use the LDAP driver for the identity backend, and the MySQL driver for the Assignment backend.
The password, the searchdn and the readonlyuser are extracted with the following command from the headnode, because they are going to be needed soon:
The file ‘/etc/keystone/keystone.conf’ is modified in the ldap section, using the crudini command for Keystone. This should also be done on any Keystone server running on the passive:
For other LDAP servers the key/value pairs may differ. Two important keys are
user_id_attribute and group_id_attribute — they must be mapped to unique values.
In the identity section of keystone.conf, the LDAP backend driver must be set with crudini or cmsh commands:
|$ crudini –set /etc/keystone/keystone.conf identity driver keystone.identity.backends.ldap.Identity|
In the assignment section of keystone.conf, the SQL backend driver must be set with the crudini or cmsh commands:
Keystone must then be restarted on the head node:
Getting A Token For The Admin User, And Assigning Roles
The token for the admin user is set using the following commands. The token is needed for the next step. Wait some seconds before running the grep command:
The role is assigned to the admin and services users as follows (Replace <TOKEN> with the token that was just grepped):
If there is a single user for all the services then run the following command instead (Replace <TOKEN> with the grepped token from earlier):
The configuration is now complete. It is now possible to login with the admin user on the OpenStack dashboard, and assign a role to a user created by Bright Cluster Manager in the OpenLDAP.
That is: It is now possible to, for example, create a user in LDAP/AD, and then immediately log in as that user to Keystone.