Chapter 2. Identity Management Integration

This configuration creates a dependency on the availability of a single IdM server: Project users will be affected if Identity Service is unable to authenticate to the IdM Server. There are a number of options available to manage this risk, for example: you might configure keystone to query a DNS alias or a load balancing appliance, rather than an individual IdM server. You can also configure keystone to query a different IdM server, should one become unavailable. See Section 2.11, “Configure for high availability” for more information.

To manage Identity Service domains from the command line, you need to enable access to keystone v3.

Perform this procedure from the controller running the keystone service.

1. Create a copy of the existing environment variable file. In a director-based deployment, it will be called overcloudrc:

$ cp overcloudrc overcloudrc-v3

2. Edit the new overcloudrc-v3 file:

export OS_AUTH_URL=https://controllerIP:5000/v3/

export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default

3. Enable these options for your current command line session by sourcing the file:

$ source overcloudrc-v3

Perform this procedure from the controller running the keystone service:

1. Configure SELinux:

# setsebool -P authlogin_nsswitch_use_ldap=on

2. Create the domains directory:

# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/

3. Configure Identity Service to use multiple back ends:

# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql

4. Configure an additional back end:

a. Create the keystone domain for IdM integration.

+ Select a name to use for your new keystone domain, and create the domain. For example, this command creates a keystone domain named LAB:

# openstack domain create LAB

b. Create the configuration file:

To add the IdM back end, enter the LDAP settings in a new file called /etc/keystone/domains/keystone.LAB.conf (where LAB is the domain name created previously). You will need to edit the sample settings below to suit your IdM deployment:

[ldap]
url =  ldaps://idm.lab.local
user = uid=svc-ldap,cn=users,cn=accounts,dc=lab,dc=local
user_filter = (memberOf=cn=grp-openstack,cn=groups,cn=accounts,dc=lab,dc=local)
password = RedactedComplexPassword
user_tree_dn = cn=users,cn=accounts,dc=lab,dc=local
user_objectclass = inetUser
user_id_attribute = uid
user_name_attribute = uid
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False
tls_cacertfile = /etc/ssl/certs/ca.crt

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

Explanation of each setting:

5. Change ownership of the config file to the keystone user:

# chown keystone /etc/keystone/domains/keystone.LAB.conf

6. Grant the admin user access to the domain:

a. Get the ID of the LAB domain:

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+

b. Get the ID value of the admin user:

# openstack user list --domain default | grep admin

| 3d75388d351846c6a880e53b2508172a | admin      |

c. Get the ID value of the admin role:

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

d. Use the returned domain and admin IDs to construct the command that adds the admin user to the admin role of the keystone LAB domain:

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf

7. Configure the dashboard to use the LAB keystone domain at the login page. Add these lines to /etc/openstack-dashboard/local_settings:

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'

8. Restart the httpd service to apply the changes:

# systemctl restart httpd.service

9. View the list of users in the IdM domain by adding the keystone domain name to the command:

# openstack user list --domain LAB

10. View the service accounts in the local keystone database:

# openstack user list --domain default

Compute uses keystone v2.0 by default, and so needs to be configured to use keystone v3 in order to use multi-domain capabilities.

1. On each Compute node, and the controller, adjust the keystone_authtoken value:

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3

2. Restart these services on the controller to apply the changes:

# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service

3. Restart this service on each Compute node to apply the changes:

# systemctl restart openstack-nova-compute.service

You must also configure Block Storage (cinder) to authenticate to keystone v3.

IdM users that are members of the grp-openstack IdM group can be granted permission to log in to a project in the dashboard:

1. Retrieve a list of IdM users:

# openstack user list --domain LAB
 +------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
| 12c062fidm5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
| afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
| e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
+------------------------------------------------------------------+----------------+

2. Retrieve a list of roles:

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

3. Grant users access to Projects by adding them to one or more of these roles. For example, if you want user1 to be a general user of the demo project, you add them to the _member_ role:

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_

Or, if you want user1 to be an administrative user of the demo project, you add them to the admin role:

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

As a result, user1 is able to log in to the dashboard by entering their IdM username and password.

For certain commands, you might need to specify the applicable domain. For example, appending --domain LAB in this command returns users in the LAB domain (that are members of the grp-openstack group):

# openstack user list --domain LAB

Appending --domain Default returns the built-in keystone accounts:

# openstack user list --domain Default

This procedure validates IdM integration by testing user access to dashboard features:

1. Create a test user in IdM, and add the user to the grp-openstack IdM group.

2. Add the user to the _member_ role of the demo tenant.

3. Log in to the dashboard using the credentials of the IdM test user.

4. Click on each of the tabs to confirm that they are presented successfully without error messages.

5. Use the dashboard to build a test instance.

Use ldapsearch to remotely perform test queries against the IdM server. A successful result here indicates that network connectivity is working, and the IdM services are up. In this example, a test query is performed against the server idm.lab.local on port 636:

# ldapsearch -D "cn=directory manager" -H ldaps://idm.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword

Use nc to check that the LDAPS port (636) is remotely accessible. In this example, a probe is performed against the server idm.lab.local. Press ctrl-c to exit the prompt.

# nc -v idm.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C

Failure to establish a connection could indicate a firewall configuration issue.