Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Chapter 1. Active Directory Integration

This chapter describes how to integrate Identity Service (keystone) with Active Directory Domain Services. In this use case, Identity Service authenticates certain Active Directory Domain Services (AD DS) users, while retaining 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, while retaining management over the privileges assigned to authenticated accounts.

Note

If you are using Red Hat OpenStack Platform director, then you will need to be aware that some of configuration files referenced below are managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. To apply these settings to director-based deployments, see Chapter 4, Using domain-specific LDAP backends with director.

1.1. Key terms
Copiar o link

  • Authentication - The process of using a password to verify that the user is who they claim to be.
  • Authorization - Validating that authenticated users have proper permissions to the resources they are attempting to access.
  • Domain - This term is not the same as an AD DS domain, and instead refers to the additional namespaces that are configured in Identity Service for partitioning users, groups, and projects. These separate domains can be configured to authenticate users in different LDAP or AD DS environments.

1.2. Assumptions
Copiar o link

This example deployment makes the following assumptions:

  • 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.

1.3. Impact Statement
Copiar o link

These steps allow AD DS users to authenticate to OpenStack and access resources. OpenStack service accounts (such as keystone and glance), and authorization management (permissions, roles, projects) will remain in the Identity Service database. Permissions and roles are assigned to the AD DS accounts using Identity Service management tools.

1.3.1. High Availability options
Copiar o link

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

1.4. Outage requirements
Copiar o link

  • The Identity Service will need to be restarted to add the AD DS back end.
  • The Compute services on all nodes will need to be restarted in order to switch over to keystone v3.
  • Users will be unable to access the dashboard until their accounts have been created in AD DS. To reduce downtime, consider pre-staging the AD DS accounts well in advance of this change.

1.5. Firewall configuration
Copiar o link

If firewalls are filtering traffic between AD DS and OpenStack, you will need to allow access through the following port:

Expand
SourceDestinationTypePort

OpenStack Controller Node

Active Directory Domain Controller

LDAPS

TCP 636

1.6. Configure Active Directory Domain Services
Copiar o link

This section describes the tasks that Active Directory administrators will need to complete:

Expand
Table 1.1. Configuration steps

Task

Details

Create a service account.

This can be named according to your naming convention for service accounts, for example: svc-ldap. This can be a regular domain user account. Administrator privileges are not required.

Create a user group.

If a user needs access to OpenStack, they must be a member of this group. This can be named according to your naming convention for user groups, for example: grp-openstack. Members of this group can be granted access to Projects in the dashboard, if they are also members of the Project groups.

Create the Project groups.

Each OpenStack Project will require a corresponding AD group. For example, grp-openstack-demo and grp-openstack-admin .

Configure the service account.

The service account svc-ldap must be a member of the grp-openstack group.

Export the LDAPS public key.

Export the public key (not the private key) in the following format: DER-encoded x509 .cer file.

Send the key to the OpenStack administrators.

The OpenStack administrators will use this key to encrypt LDAPS communications between OpenStack and Active Directory.

Retrieve the NetBIOS name of your AD DS domain.

The OpenStack administrators will use this name for the Keystone domain, allowing consistent domain naming between the environments.

For example, the procedure below shows the PowerShell commands that would be run on the Active Directory Domain Controller:

  1. 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'
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap

  3. Create a group for OpenStack users, called grp-openstack. 

    PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
    Copy to Clipboard Toggle word wrap

  4. 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"
    Copy to Clipboard Toggle word wrap

  5. Add the svc-ldap user to the grp-openstack group: 

    PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
    Copy to Clipboard Toggle word wrap
  6. From an AD Domain Controller, use a Certificates MMC to export your LDAPS certificate’s public key (not the private key) as a DER-encoded x509 .cer file. Send this file to the OpenStack administrators.

  7. Retrieve the NetBIOS name of your AD DS domain. 

    PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB
    Copy to Clipboard Toggle word wrap

Send this value to the OpenStack administrators.

1.7. Configure the LDAPS certificate
Copiar o link

Keystone uses LDAPS queries to validate user accounts. To encrypt this traffic, keystone uses the certificate file defined by keystone.conf. This procedure converts the public key received from Active Directory into the .crt format, and copies to a location where keystone will be able to reference it.

  1. Copy the LDAPS public key to the node running OpenStack Identity (keystone), and convert the .cer to .crt. This example uses a source certificate file named addc.lab.local.cer: 

    # openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/
    Copy to Clipboard Toggle word wrap
Note

Optionally, if you need to run diagnostic commands, such as ldapsearch, you will also need to add the certificate to the RHEL certificate store:

  1. Convert the .cer to .pem. This example uses a source certificate file named addc.lab.local.cer: 

    # openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
    Copy to Clipboard Toggle word wrap

  2. Install the .pem on your OpenStack controller. For example, in Red Hat Enterprise Linux: 

    # cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
    Copy to Clipboard Toggle word wrap

1.8. Configure Identity Service
Copiar o link

These steps prepare Identity Service (keystone) for integration with AD DS.

Note

If you are using Red Hat OpenStack Platform director, then you will need to be aware that some of configuration files referenced below are managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. To apply these settings to director-based deployments, see https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12/html/integrate_with_identity_service/sec-director-ldap

1.8.1. Enable command line access to keystone v3
Copiar o link

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
    Copy to Clipboard Toggle word wrap

  2. Edit the new overcloudrc-v3 file:

    • Change OS_AUTH_URL from v2.0 to v3. For example: 

      export OS_AUTH_URL=https://controllerIP:5000/v3/
      Copy to Clipboard Toggle word wrap

    • Add the following entries to the bottom of overcloudrc-v3: 

      export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
      Copy to Clipboard Toggle word wrap

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

    $ source overcloudrc-v3
    Copy to Clipboard Toggle word wrap

1.8.2. Configure the controller
Copiar o link

Note

If you intend to update any configuration files, you need to be aware that certain OpenStack services now run within containers; this applies to keystone, nova, and cinder, among others. As a result, there are certain administration practices to consider:

  • Do not update any configuration file you might find on the physical node’s host operating system, for example, /etc/cinder/cinder.conf. This is because the containerized service does not reference this file.

  • Do not update the configuration file running within the container. This is because any changes are lost once you restart the container.

    Instead, if you need to add any changes to containerized services, you will need to update the configuration file that is used to generate the container. These are stored within /var/lib/config-data/puppet-generated/

    For example:

  • keystone: /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
  • cinder: /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

  • nova: /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf

    Any changes will then be applied once you restart the container. For example: sudo docker exec -it keystone pkill -HUP -f keystone

Perform this procedure from the controller running the keystone service. If running a HA environment with multiple controllers, then these steps must be performed on each controller:

  1. Configure SELinux: 

    # setsebool -P authlogin_nsswitch_use_ldap=on
    Copy to Clipboard Toggle word wrap

    The output might include messages similar to this. They can be ignored: 

    Full path required for exclude: net:[4026532245].
    Copy to Clipboard Toggle word wrap

  2. Create the domains directory: 

    # mkdir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
# chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
    Copy to Clipboard Toggle word wrap

  3. Configure keystone to use multiple back ends:

    Note

    You might need to install crudini using yum install crudini. 

    # crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql
    Copy to Clipboard Toggle word wrap
    Note

    If you are using Red Hat OpenStack Platform director, then you will need to be aware that /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf is managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. As a result, you might need to re-add this configuration manually each time. For director-based deployments, see https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12/html/integrate_with_identity_service/sec-director-ldap

  4. Enable multiple domains in dashboard. Add these lines to /etc/openstack-dashboard/local_settings: 

    OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
    Copy to Clipboard Toggle word wrap
    Note

    If you are using Red Hat OpenStack Platform director, then you will need to be aware that /etc/openstack-dashboard/local_settings is managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. As a result, you might need to re-add this configuration manually each time. It is expected that a future release of director will include the Puppet parameters that will allow you to re-apply these settings automatically using a post-deployment script.

    Restart httpd to apply the settings: 

    # systemctl restart httpd
    Copy to Clipboard Toggle word wrap

  5. Configure an additional back end:

    In this example, LAB is the NetBIOS name to use as the Identity Service domain.

    1. Create the keystone domain for AD DS integration.

      Use the NetBIOS name value retrieved previously as the domain name. This approach allows you to present a consistent domain name to users during the login process. For example, if the NetBIOS name is LAB: 

      # openstack domain create LAB
      Copy to Clipboard Toggle word wrap
      Note

      If this command is not available, check that you have enabled keystone v3 for your command line session by running # source overcloudrc-v3.

    2. Create the configuration file:

      To add the AD DS back end, enter the LDAP settings in a new file called /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf (where LAB is the NetBIOS name retrieved previously). You will need to edit the sample settings below to suit your AD DS deployment: 

      [ldap]
url                  = ldaps://addc.lab.local:636
user                  = CN=svc-ldap,OU=labUsers,DC=lab,DC=local
password                 = RedactedComplexPassword
suffix                   = DC=lab,DC=local
user_tree_dn             = OU=labUsers,DC=lab,DC=local
user_objectclass         = person
user_filter                  = (|(memberOf=cn=grp-openstack,OU=labUsers,DC=lab,DC=local)(memberOf=cn=grp-openstack-admin,OU=labUsers,DC=lab,DC=local)(memberOf=memberOf=cn=grp-openstack-demo,OU=labUsers,DC=lab,DC=local))
user_id_attribute        = sAMAccountName
user_name_attribute      = sAMAccountName
user_mail_attribute      = mail
user_pass_attribute      =
user_enabled_attribute   = userAccountControl
user_enabled_mask        = 2
user_enabled_default     = 512
user_attribute_ignore    = password,tenant_id,tenants
user_allow_create        = False
user_allow_update        = False
user_allow_delete        = False
group_objectclass        = group
group_tree_dn            = OU=labUsers,DC=lab,DC=local
group_filter             = (CN=grp-openstack*)
group_id_attribute       = cn
group_name_attribute     = name
group_allow_create       = False
group_allow_update       = False
group_allow_delete       = False
use_tls                  = False
tls_cacertfile                  = /etc/ssl/certs/addc.lab.local.crt
query_scope                  = sub
chase_referrals                  = false

[identity]
driver = ldap
      Copy to Clipboard Toggle word wrap

      Explanation of each setting:

      Expand
      SettingDescription

      url

      The AD Domain Controller to use for authentication. Uses LDAPS port 636.

      user

      The Distinguished Name of an AD account to use for LDAP queries. For example, you can locate the Distinguished Name value of the svc-ldap account in AD using Get-ADuser svc-ldap | select DistinguishedName

      password

      The plaintext password of the AD account used above.

      suffix

      The Distinguished Name of your AD domain. You can locate this value using Get-ADDomain | select DistinguishedName

      user_tree_dn

      The Organizational Unit (OU) that contains the OpenStack accounts.

      user_objectclass

      Defines the type of LDAP user. For AD, use the person type.

      user_filter

      Filters the users presented to Identity Service. As a result, only members of the grp-openstack group can have permissions defined in Identity Service. This value requires the full Distinguished Name of the group: Get-ADGroup grp-openstack | select DistinguishedName

      user_id_attribute

      Maps the AD value to use for user IDs.

      user_name_attribute

      Maps the AD value to use for names.

      user_mail_attribute

      Maps the AD value to use for user email addresses.

      user_pass_attribute

      Leave this value blank.

      user_enabled_attribute

      The AD setting that validates whether the account is enabled.

      user_enabled_mask

      Defines the value to check to determine whether an account is enabled. Used when booleans are not returned.

      user_enabled_default

      The AD value that indicates that an account is enabled.

      user_attribute_ignore

      Defines user attributes that Identity Service should disregard.

      user_allow_create

      Set this value to False, as keystone only requires read-only access.

      user_allow_update

      Set this value to False, as keystone only requires read-only access.

      user_allow_delete

      Set this value to False, as keystone only requires read-only access.

      group_objectclass

      Maps the AD value to use for groups.

      group_tree_dn

      The Organizational Unit (OU) that contains the user groups.

      group_filter

      Filters the groups presented to Identity Service.

      group_id_attribute

      Maps the AD value to use for group IDs.

      group_name_attribute

      Maps the AD value to use for group names.

      group_allow_create

      Set this value to False, as keystone only requires read-only access.

      group_allow_update

      Set this value to False, as keystone only requires read-only access.

      group_allow_delete

      Set this value to False, as keystone only requires read-only access.

      use_tls

      Defines whether TLS is to be used. This needs to be disabled if you are encrypting with LDAPS rather than STARTTLS.

      tls_cacertfile

      Specifies the path to the .crt certificate file.

      query_scope

      Configures Identity Service to also search within nested child OUs, when locating users that are members of the grp-openstack group.

      chase_referrals

      Set to false, this setting prevents python-ldap from chasing all referrals with anonymous access.

  6. Change ownership of the configuration file to the keystone user: 

    # chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf
    Copy to Clipboard Toggle word wrap

  7. Restart the keystone service to apply the changes: 

    # sudo docker exec -it keystone pkill -HUP -f keystone
    Copy to Clipboard Toggle word wrap

  8. Grant the admin user access to the domain:

    Note

    This does not grant the OpenStack admin account any permissions on the actual AD DS domain. In this case, the term domain refers to OpenStack’s usage of the keystone domain.

    1. Get the ID of the LAB domain: 

      # openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+
      Copy to Clipboard Toggle word wrap

    2. Get the ID value of the admin user: 

      # openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin      |
      Copy to Clipboard Toggle word wrap

    3. Get the ID value of the admin role: 

      # openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
      Copy to Clipboard Toggle word wrap

    4. 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
      Copy to Clipboard Toggle word wrap

    5. View the list of users in the AD DS domain by adding the NetBIOS name to the command:

      Note

      It might take some time for the LDAP to become queryable after a reboot or service restart. 

      # openstack user list --domain LAB
      Copy to Clipboard Toggle word wrap

    6. View the service accounts in the local Identity Service database: 

      # openstack user list --domain default
      Copy to Clipboard Toggle word wrap

1.8.3. Configure Compute to use keystone v3
Copiar o link

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:

    1. On the Compute nodes: 

      # crudini --set /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf keystone_authtoken auth_version v3
      Copy to Clipboard Toggle word wrap

    2. On the controller: 

      # crudini --set /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf keystone_authtoken auth_version v3
      Copy to Clipboard Toggle word wrap

  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

# sudo docker exec -it keystone pkill -HUP -f keystone
    Copy to Clipboard Toggle word wrap

  3. Restart these services on each Compute node to apply the changes: 

    # systemctl restart openstack-nova-compute.service
    Copy to Clipboard Toggle word wrap

1.8.4. Configure Block Storage to use keystone v3
Copiar o link

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

  1. In /etc/cinder/cinder.conf: 

    [keystone_authtoken]
auth_uri = https://controllerIP:5000/v3
auth_version = v3
    Copy to Clipboard Toggle word wrap
    • auth_uri - replace controllerIP with the IP address of the controller. If your deployment has more than one controller, you should use the keystone endpoint VIP instead of the controller IP.

  2. Restart cinder-api on all controllers: 

    # systemctl restart openstack-cinder-api
    Copy to Clipboard Toggle word wrap

  3. Restart cinder-scheduler on all controllers: 

    # systemctl restart openstack-cinder-scheduler
    Copy to Clipboard Toggle word wrap

  4. Restart cinder-volume (on one controller only): 

    # pcs resource restart openstack-cinder-volume
    Copy to Clipboard Toggle word wrap

1.8.5. Allow Active Directory group members to access Projects
Copiar o link

To allow authenticated users access to OpenStack resources, the recommended method is to authorize certain Active Directory groups to grant access to Projects. This saves the OpenStack administrators from having to allocate each user to a role in a Project. Instead, the Active Directory groups are granted roles in Projects. As a result, Active Directory users that are members of these Active Directory groups will be able to access pre-determined Projects.

Note

If you would prefer to manually manage the authorization of individual Active Directory users, see the following section: Allow individual Active Directory users to access Projects

This section presumes that the Active Directory administrator has already completed these steps:

  • Create a group named grp-openstack-admin in Active Directory.
  • Create a group named grp-openstack-demo in Active Directory.
  • Add your Active Directory users to one of the above groups, as needed.
  • Add your Active Directory users to the grp-openstack group.

These steps assign a role to an AD group. Group members will then have permission to access OpenStack resources.

  1. Retrieve a list of AD groups: 

    # openstack group list --domain LAB
+------------------------------------------------------------------+---------------------+
| ID                                                               | Name                |
+------------------------------------------------------------------+---------------------+
| 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack       |
| a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin |
| d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo  |
+------------------------------------------------------------------+---------------------+
    Copy to Clipboard Toggle word wrap

  2. Retrieve a list of roles: 

    # openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
| 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
+----------------------------------+---------------+
    Copy to Clipboard Toggle word wrap

  3. Grant the Active Directory groups access to 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 the demo project, you must add the group to the _member_ role: 

    # openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8  _member_
    Copy to Clipboard Toggle word wrap

As a result, members of grp-openstack-demo are able to log in to the dashboard by entering their AD DS username and password, when also entering LAB in the Domain field:

domain
View larger image
domain
Note

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.8.6. Allow Active Directory users to access Projects
Copiar o link

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

  1. Retrieve a list of AD users: 

    # openstack user list --domain LAB
 +------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
| 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
| afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
| e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
+------------------------------------------------------------------+----------------+
    Copy to Clipboard Toggle word wrap

  2. Retrieve a list of roles: 

    # openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+
    Copy to Clipboard Toggle word wrap

  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_
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    As a result, user1 is able to log in to the dashboard by entering their AD DS username and password, when also entering LAB in the Domain field:

domain
View larger image
domain
Note

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.9. Grant access to the Domain tab
Copiar o link

To allow the admin user to see the Domain tab, you will need to assign it the admin role in the default domain:

  1. Find the admin user’s UUID: 

    $ openstack user list | grep admin
| a6a8adb6356f4a879f079485dad1321b | admin      |
    Copy to Clipboard Toggle word wrap

  2. Add the admin role in the default domain to the admin user: 

    $ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
    Copy to Clipboard Toggle word wrap

    As a result, the admin user can now see the Domain tab.

1.10. Creating a new project
Copiar o link

After you have completed these integration steps, when you create a new project you will need to decide whether to create it in the Default domain, or in the keystone domain you’ve just created. This decision can be reached by considering your workflow, and how you administer user accounts. The Default domain can be be thought of as an internal domain, used to manage service accounts and the admin project. For separation purposes, you might want to keep your AD-backed users in a separate keystone domain.

1.11. Changes to the dashboard log in process
Copiar o link

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. This field must be manually filled with one of the domains present in keystone. Use the openstack command to list the available entries.

In this example, AD DS accounts will need to specify the LAB domain. The built-in keystone accounts, such as admin, must specify Default as their domain: 

# openstack domain list
+----------------------------------+---------+---------+----------------------------------------------------------------------+
| ID                               | Name    | Enabled | Description                                                          |
+----------------------------------+---------+---------+----------------------------------------------------------------------+
| 6800b0496429431ab1c4efbb3fe810d4 | LAB     | True    |                                                                      |
| default                          | Default | True    | Owns users and tenants (i.e. projects) available on Identity API v2. |
+----------------------------------+---------+---------+----------------------------------------------------------------------+
Copy to Clipboard Toggle word wrap

1.12. Changes to the command line
Copiar o link

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
Copy to Clipboard Toggle word wrap

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

# openstack user list --domain Default
Copy to Clipboard Toggle word wrap

1.13. Test AD DS integration
Copiar o link

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

  1. Create a test user in AD, and add the user to the grp-openstack AD DS group.
  2. Add the user to the _member_ role of the demo tenant.
  3. Log in to the dashboard using the credentials of the AD 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.
Note

If you experience issues with these steps, perform steps 3-5 with the built-in admin account. If successful, this demonstrates that OpenStack is still working as expected, and that an issue exists somewhere within the AD ←→ Identity integration settings. See Section 1.16, “Troubleshooting”.

1.14. Configure high availability
Copiar o link

With keystone v3 enabled, you can make this configuration highly available by listing multiple AD Domain Controllers in the configuration file for that domain.

  1. Add a second server to the url entry. For example, updating the url setting in the keystone.LAB.conf file will have keystone send all query traffic to the first Domain Controller in the list, addc.lab.local: 

    url =  ldaps://addc.lab.local,ldaps://addc2.lab.local
    Copy to Clipboard Toggle word wrap

    If a query to addc.lab.local fails due to it being unavailable, Identity Service will attempt to query the next server in the list: addc2.lab.local. Note that this configuration does not perform queries in a round-robin fashion, so cannot be considered a load-balancing solution.

  2. Set the network timeout in /etc/openldap/ldap.conf: 

    NETWORK_TIMEOUT 2
    Copy to Clipboard Toggle word wrap

In addition, if you have firewalls configured between the controller and the domain controllers, then you should not configure the domain controllers to silently drop packets from the controller. This will allow python-keystoneclient to properly detect outages and redirect the request to the next domain controller in the list.

Note

There might be connection delays while queries are being redirected to the second LDAP server in the list. This is because the connection to the first server must first time out before the second is attempted.

1.15. Create a RC file for a non-admin user
Copiar o link

You might need to create a RC file for a non-admin user. For example: 

$ 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
Copy to Clipboard Toggle word wrap

1.16. Troubleshooting
Copiar o link

1.16.1. Test LDAP connections
Copiar o link

Note

This command expects to find the necessary certificate in your host operating system. See the Configure the LDAPS certificate section for more information.

Use ldapsearch 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 server addc.lab.local on port 636: 

# 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
Copy to Clipboard Toggle word wrap
Note

ldapsearch is a part of the openldap-clients package. You can install this using # yum install openldap-clients

1.16.2. Test the Certificate Trust Configuration
Copiar o link

If you receive the error Peer's Certificate issuer is not recognized. while testing with ldapsearch, confirm that your TLS_CACERTDIR path is correctly set. For example:

  • /etc/openldap/ldap.conf 
TLS_CACERTDIR /etc/openldap/certs
Copy to Clipboard Toggle word wrap
Note

As a temporary workaround, you may want to consider disabling certificate validation.

This setting must not be permanently configured:

  • /etc/openldap/ldap.conf 
TLS_REQCERT allow
Copy to Clipboard Toggle word wrap

If the ldapsearch query works after setting this value, you might need to review whether your certificate trusts are correctly configured.

1.16.3. Test port access
Copiar o link

Use nc to check that LDAPS port 636 is remotely accessible. In this example, a probe is performed against the server addc.lab.local. Press ctrl-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
Copy to Clipboard Toggle word wrap

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

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat