Chapter 1. Integrating OpenStack Identity (keystone) with Active Directory
You can integrate OpenStack Identity (keystone) with Microsoft Active Directory Domain Service (AD DS). Identity Service authenticates certain Active Directory Domain Services (AD DS) users but retains authorization settings and critical service accounts in the Identity Service database. As a result, Identity Service has read-only access to AD DS for user account authentication and continues to manage privileges assigned to authenticated accounts.
By integrating the Identity service with AD DS, you allow AD DS users to authenticate to Red Hat OpenStack Platform (RHOSP) to access resources. RHOSP service accounts, such as the Identity Service and the Image service, and authorization management remain in the Identity Service database. Permissions and roles are assigned to the AD DS accounts using Identity Service management tools.
The process to integrate OpenStack Identity with Active Directory includes the following stages:
- Configure Active Directory credentials and export the LDAPS certificate
- Install and configure the LDAPS certificate in OpenStack
- Configure director to use one or more LDAP backends
- Configure Controller nodes to access the Active Directory backend
- Configure Active Directory user or group access to OpenStack projects
- Verify that the domain and user lists are created correctly
- Optional: Create credential files for non-admin users.
1.1. Configuring Active Directory credentials
To configure Active Directory Domain Service (AD DS) to integrate with OpenStack Identity, set up an LDAP account for Identity service to use, create a user group for Red Hat OpenStack users, and export the LDAPS certificate public key to use in the Red Hat OpenStack Platform deployment.
Prerequisites
- Active Directory Domain Services is configured and operational.
- Red Hat OpenStack Platform is configured and operational.
- DNS name resolution is fully functional and all hosts are registered appropriately.
- AD DS authentication traffic is encrypted with LDAPS, using port 636.
- Recommended: Implement AD DS with a high availability or load balancing solution to avoid a single point of failure.
Procedure
Perform these steps on the Active Directory server.
Create the LDAP lookup account. This account is used by Identity Service to query the AD DS LDAP service:
PS C:\> New-ADUser -SamAccountName svc-ldap -Name "svc-ldap" -GivenName LDAP -Surname Lookups -UserPrincipalName svc-ldap@lab.local -Enabled $false -PasswordNeverExpires $true -Path 'OU=labUsers,DC=lab,DC=local'
Set a password for this account, and then enable it. You will be prompted to specify a password that complies with your AD domain’s complexity requirements:
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
Create a group for RHOSP users, called
grp-openstack
. Only members of this group can have permissions assigned in OpenStack Identity.PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
Create the Project groups:
PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local" PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
Add the
svc-ldap
user to thegrp-openstack
group:PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
-
From an AD Domain Controller, use a
Certificates MMC
to export your LDAPS certificate’s public key (not the private key) as a DER-encodedx509
.cer file. Send this file to the RHOSP administrators. Retrieve the NetBIOS name of your AD DS domain.
PS C:\> Get-ADDomain | select NetBIOSName NetBIOSName ----------- LAB
Send this value to the RHOSP administrators.
1.2. Installing the Active Directory LDAPS certificate
OpenStack Identity (keystone) uses LDAPS queries to validate user accounts. To encrypt this traffic, keystone uses the certificate file defined by keystone.conf
. To configure the LDAPS certificate, convert the public key received from Active Directory into the .crt
format and copy the certificate to a location where keystone will be able to reference it.
When using multiple domains for LDAP authentication, you might receive various errors, such as Unable to retrieve authorized projects
, or Peer's Certificate issuer is not recognized
. This can arise if keystone uses the incorrect certificate for a certain domain. As a workaround, merge all of the LDAPS public keys into a single .crt
bundle, and configure all of your keystone domains to use this file.
Prerequisites
- Active Directory credentials are configured.
- LDAPS certificate is exported from Active Directory.
Procedure
Copy the LDAPS public key to the node running OpenStack Identity and convert the
.cer
to.crt
. This example uses a source certificate file namedaddc.lab.local.cer
:# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.crt # cp addc.lab.local.crt /etc/pki/ca-trust/source/anchors
Optional: If you need to run diagnostic commands, such as
ldapsearch
, you also need to add the certificate to the RHEL certificate store:Convert the
.cer
to.pem
. This example uses a source certificate file namedaddc.lab.local.cer
:# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
Install the
.pem
on the Controller node. For example, in Red Hat Enterprise Linux:# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
1.3. Configuring director to use domain-specific LDAP backends
To configure director to use one or more LDAP backends, set the KeystoneLDAPDomainEnable
flag to true
in your heat templates, and set up environment files with the information about each LDAP backend. Director then uses a separate LDAP backend for each keystone domain.
The default directory for domain configuration files is set to /etc/keystone/domains/
. You can override this by setting the required path with the keystone::domain_config_directory
hiera key and adding it as an ExtraConfig
parameter within an environment file.
Procedure
-
In the heat template for your deployment, set the
KeystoneLDAPDomainEnable
flag totrue
. This configures thedomain_specific_drivers_enabled
option in keystone within theidentity
configuration group. -
Add a specification of the LDAP backend configuration by setting the
KeystoneLDAPBackendConfigs
parameter intripleo-heat-templates
, where you can then specify your required LDAP options. Create a copy of the
keystone_domain_specific_ldap_backend.yaml
environment file:$ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
Edit the
/home/stack/templates/keystone_domain_specific_ldap_backend.yaml
environment file and set the values to suit your deployment. For example, this parameter create a LDAP configuration for a keystone domain namedtestdomain
:parameter_defaults: KeystoneLDAPDomainEnable: true KeystoneLDAPBackendConfigs: testdomain: url: ldaps://192.0.2.250 user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword suffix: dc=director,dc=example,dc=com user_tree_dn: ou=Users,dc=director,dc=example,dc=com user_filter: "(memberOf=cn=OSuser,ou=Groups,dc=director,dc=example,dc=com)" user_objectclass: person user_id_attribute: cn
NoteThe
keystone_domain_specific_ldap_backend.yaml
environment file contains the following deprecated write parameters:-
user_allow_create
-
user_allow_update
-
user_allow_delete
The values for these parameters have no effect on the deployment, and can be safely removed.
-
Optional: Add more domains to the environment file. For example:
KeystoneLDAPBackendConfigs: domain1: url: ldaps://domain1.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ... domain2: url: ldaps://domain2.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ...
This results in two domains named
domain1
anddomain2
; each will have a different LDAP domain with its own configuration.
1.4. Granting the admin user access to the OpenStack Identity domain
To allow the admin
user to access the OpenStack Identity (keystone) domain and see the Domain
tab, get the ID of the domain and the admin
user, and then assign the admin
role to the user in the domain.
This does not grant the OpenStack admin account any permissions on the external service domain. In this case, the term domain refers to OpenStack’s usage of the keystone domain.
Procedure
This procedure uses the LAB
domain. Replace the domain name with the actual name of the domain that you are configuring.
Get the ID of the
LAB
domain:$ openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
Get the ID of the
admin
user from thedefault
domain:$ openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
Get the ID of the
admin
role:$ openstack role list
The output depends on the external service you are integrating with:
Active Directory Domain Service (AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat Identity Manager (IdM):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
Use the domain and admin IDs to construct the command that adds the
admin
user to theadmin
role of the keystoneLAB
domain:# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
1.5. Granting external groups access to Red Hat OpenStack Platform projects
To grant multiple authenticated users access to Red Hat OpenStack Platform (RHOSP) resources, you can authorize certain groups from the external user management service to grant access to RHOSP projects, instead of requiring OpenStack administrators to manually allocate each user to a role in a project. As a result, all members of these groups can access pre-determined projects.
Prerequisites
Ensure that the external service administrator completed the following steps:
-
Creating a group named
grp-openstack-admin
. -
Creating a group named
grp-openstack-demo
. - Adding your RHOSP users to one of these groups as needed.
-
Adding your users to the
grp-openstack
group.
-
Creating a group named
-
Create the OpenStack Identity domain. This procedure uses the
LAB
domain. -
Create or choose a RHOSP project. This procedure uses a project called
demo
that was created with theopenstack project create --domain default --description "Demo Project" demo
command.
Procedure
Retrieve a list of user groups from the OpenStack Identity domain:
# openstack group list --domain LAB
The command output depends on the external user management service that you are integrating with:
Active Directory Domain Service (AD DS):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
Red Hat Identity Manager (IdM):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
Retrieve a list of roles:
# openstack role list
The command output depends on the external user management service that you are integrating with:
Active Directory Domain Service (AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat Identity Manager (IdM):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
Grant the user groups access to RHOSP projects by adding them to one or more of these roles. For example, if you want users in the
grp-openstack-demo
group to be general users of thedemo
project, you must add the group to themember
or_member_
role, depending on the external service that you are integrating with:Active Directory Domain Service (AD DS):
# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 member
Red Hat Identity Manager (IdM):
$ openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
Result
Members of grp-openstack-demo
can log in to the dashboard by entering their username and password and entering LAB
in the Domain
field:
![domain](https://access.redhat.com/webassets/avalon/d/Red_Hat_OpenStack_Platform-16.1-Integrate_OpenStack_Identity_with_external_user_management_services-en-US/images/c87cda89329065ffda8cc3e90d3501e2/domain.png)
If users receive the error Error: Unable to retrieve container list.
, and expect to be able to manage containers, then they must be added to the SwiftOperator
role.
Additional resources
1.6. Granting external users access to Red Hat OpenStack Platform projects
To grant specific authenticated users from the grp-openstack
group access to OpenStack resources, you can grant these users direct access to Red Hat OpenStack Platform (RHOSP) projects. Use this process in cases where you want to grant access to individual users instead of granting access to groups.
Prerequisites
Ensure that the external service administrator completed the following steps:
-
Adding your RHOSP users to the
grp-openstack
group. -
Creating the OpenStack Identity domain. This procedure uses the
LAB
domain.
-
Adding your RHOSP users to the
-
Create or choose a RHOSP project. This procedure uses a project called
demo
that was created with theopenstack project create --domain default --description "Demo Project" demo
command.
Procedure
Retrieve a list of users from the OpenStack Identity domain:
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2 | | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3 | | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4 | +------------------------------------------------------------------+----------------+
Retrieve a list of roles:
# openstack role list
The command output depends on the external user management service that you are integrating with:
Active Directory Domain Service (AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat Identity Manager (IdM):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
Grant users access to RHOSP projects by adding them to one or more of these roles. For example, if you want
user1
to be a general user of thedemo
project, you add them to themember
or_member_
role, depending on the external service that you are integrating with:Active Directory Domain Service (AD DS):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e member
Red Hat Identity Manager (IdM):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
If you want
user1
to be an administrative user of thedemo
project, add the user to theadmin
role:# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
Result
The user1
user is able to log in to the dashboard by entering their external username and password and entering LAB
in the Domain
field:
![domain](https://access.redhat.com/webassets/avalon/d/Red_Hat_OpenStack_Platform-16.1-Integrate_OpenStack_Identity_with_external_user_management_services-en-US/images/c87cda89329065ffda8cc3e90d3501e2/domain.png)
If users receive the error Error: Unable to retrieve container list.
, and expect to be able to manage containers, then they must be added to the SwiftOperator
role.
1.7. Viewing the list of OpenStack Identity domains and users
Use the openstack domain list
command to list the available entries. Configuring multiple domains in Identity Service enables a new Domain field in the dashboard login page. Users are expected to enter the domain that matches their login credentials.
After you complete the integration, you need to decide whether to create new projects in the Default
domain or in newly created keystone domains. You must consider your workflow and how you administer user accounts. If possible, use the Default
domain as an internal domain to manage service accounts and the admin
project, and keep your external users in a separate domain.
In this example, external accounts need to specify the LAB
domain. The built-in keystone accounts, such as admin
, must specify Default
as their domain.
Procedure
Show the list of domains:
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and projects available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
Show the list of users in a specific domain. This command example specifies the
--domain LAB
and returns users in the LAB domain that are members of thegrp-openstack
group:# openstack user list --domain LAB
You can also append
--domain Default
to show the built-in keystone accounts:# openstack user list --domain Default
1.8. Creating a credentials file for a non-admin user
After you configure users and domains for OpenStack Identity, you might need to create a credentials file for a non-admin user.
Procedure
Create a credentials (RC) file for a non-admin user. This example uses the
user1
user in the file.$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
1.9. Testing OpenStack Identity integration with an external user management service
To test that OpenStack Identity (keystone) successfully integrated with Active Directory Domain Service (AD DS), test user access to dashboard features.
Prerequisites
- Integration with an external user management service, such as Active Directory (AD) or Red Hat Identity Manager (IdM)
Procedure
-
Create a test user in the external user management service, and add the user to the
grp-openstack
group. -
In Red Hat OpenStack Platform, add the user to the
_member_
role of thedemo
project. - Log in to the dashboard with the credentials of the AD test user.
- Click on each of the tabs to confirm that they are presented successfully without error messages.
- Use the dashboard to build a test instance.
If you experience issues with these steps, log in to the dashboard with the admin
account and perform the subsequent steps as that user. If the test is successful, it means that OpenStack is still working as expected and that an issue exists somewhere in the integration settings between OpenStack Identity and Active Directory.
Additional resources
1.10. Troubleshooting Active Directory integration
If you encounter errors when using the Active Directory integration with OpenStack Identity, you might need to test the LDAP connection or test the certificate trust configuration. You might also need to check that the LDAPS port is accessible.
Depending on the error type and location, perform only the relevant steps in this procedure.
Procedure
Test the LDAP connection by using the
ldapsearch
command to remotely perform test queries against the Active Directory Domain Controller. A successful result here indicates that network connectivity is working, and the AD DS services are up. In this example, a test query is performed against the serveraddc.lab.local
on port636
:# ldapsearch -Z -x -H ldaps://addc.lab.local:636 -D "svc-ldap@lab.local" -W -b "OU=labUsers,DC=lab,DC=local" -s sub "(cn=*)" cn
Note-
ldapsearch
is a part of theopenldap-clients
package. You can install this using# dnf install openldap-clients
- This command expects to find the necessary certificate in your host operating system.
-
If you receive the error
Peer's Certificate issuer is not recognized.
while testing theldapsearch
command, confirm that yourTLS_CACERTDIR
path is correctly set. For example:TLS_CACERTDIR /etc/openldap/certs
As a temporary workaround, consider disabling certificate validation.
ImportantThis setting must not be permanently configured.
In the
/etc/openldap/ldap.conf
, set theTLS_REQCERT
parameter toallow
:TLS_REQCERT allow
If the
ldapsearch
query works after setting this value, you might need to review whether your certificate trusts are correctly configured.Use the
nc
command to check that LDAPS port636
is remotely accessible. In this example, a probe is performed against the serveraddc.lab.local
. Pressctrl-c
to exit the prompt.# nc -v addc.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 might indicate a firewall configuration issue.