Chapter 2. Integrating OpenStack Identity (keystone) with Red Hat Identity Manager (IdM)

1. Configure the /etc/resolv.conf file:

   Set the appropriate search domains and the nameserver on the undercloud in /etc/resolv.conf. For example, if the deployment domain is example.com, and the domain of the FreeIPA server is bigcorp.com, then add the following lines to /etc/resolv.conf:

   search example.com bigcorp.com
   nameserver $IDM_SERVER_IP_ADDR

2. Install required software:

   sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel

3. Export environmental variables with values specific to your environment.:

   export IPA_DOMAIN=bigcorp.com
   export IPA_REALM=BIGCORP.COM
   export IPA_ADMIN_USER=$IPA_USER 1
   export IPA_ADMIN_PASSWORD=$IPA_PASSWORD 2
   export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
   export UNDERCLOUD_FQDN=undercloud.example.com 3
   export USER=stack
   export CLOUD_DOMAIN=example.com

   1 2

   The IdM user credentials are an administrative user that can add new hosts and services.

   3

   The value of the UNDERCLOUD_FQDN parameter matches the first hostname-to-IP address mapping in /etc/hosts.

4. Run the undercloud-ipa-install.yaml ansible playbook on the undercloud:

   ansible-playbook \
   --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
   /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml

5. Add the following parameters to undercloud.conf

   undercloud_nameservers = $IDM_SERVER_IP_ADDR
   overcloud_domain_name = example.com

6. [Optional] If your IPA realm does not match your IPA domain, set the value of the certmonger_krb_realm parameter:

   1. Set the value of the certmonger_krb_realm in /home/stack/hiera_override.yaml:

      parameter_defaults:
        certmonger_krb_realm = EXAMPLE.COMPANY.COM

   2. Set the value of the custom_env_files parameter in undercloud.conf to /home/stack/hiera_override.yaml:

      custom_env_files = /home/stack/hiera_override.yaml

7. Deploy the undercloud:

   openstack undercloud install

1. List the hosts in IdM:

   $ kinit admin
   $ ipa host-find

2. Confirm that /etc/novajoin/krb5.keytab exists on the undercloud.

   ls /etc/novajoin/krb5.keytab

1. Before deploying the overcloud, create a YAML file tls-parameters.yaml with contents similar to the following. The values you select will be specific for your environment:

   parameter_defaults:
       DnsSearchDomains: ["example.com"]
       DnsServers: ["192.168.1.13"]
       CloudDomain: example.com
       CloudName: overcloud.example.com
       CloudNameInternal: overcloud.internalapi.example.com
       CloudNameStorage: overcloud.storage.example.com
       CloudNameStorageManagement: overcloud.storagemgmt.example.com
       CloudNameCtlplane: overcloud.ctlplane.example.com
       IdMServer: freeipa-0.redhat.local
       IdMDomain: redhat.local
       IdMInstallClientPackages: False
   
   resource_registry:
         OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml

   • The shown value of the OS::TripleO::Services::IpaClient parameter overrides the default setting in the enable-internal-tls.yaml file. You must ensure the tls-parameters.yaml file follows enable-internal-tls.yaml in the openstack overcloud deploy command.
   • For more information about the parameters that you use to implement TLS-e, see Parameters for tripleo-ipa

2. Deploy the overcloud. You will need to include the tls-parameters.yaml in the deployment command:

   DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
   CUSTOM_TEMPLATES=/home/stack/templates
   
   openstack overcloud deploy \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
   -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
   ...

3. Confirm each endpoint is using HTTPS by querying keystone for a list of endpoints:

   openstack endpoint list

1. Adding the undercloud node to the certificate authority (CA)
2. Adding the undercloud node to IdM
3. Optional: Setting the IdM server as the DNS server for the overcloud
4. Preparing the environment files and deploying the overcloud
5. Testing the overcloud enrollment in IdM and in RHOSP
6. Optional: Adding DNS entries for novajoin in IdM

1. Create an environment file called memcached.yaml with the following contents to add TLS support for memcached:

   parameter_defaults:
       MemcachedTLS: true
       MemcachedPort: 11212

2. Include the memcached.yaml environment file in the overcloud deployment process:

   openstack overcloud deploy --templates \
   -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
   -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
   -e /home/stack/memcached.yaml
   ...

1. Create the LDAP lookup account to use in OpenStack Identity Service to query the IdM LDAP service:

   # kinit admin
   # ipa user-add
   First name: OpenStack
   Last name: LDAP
   User  [radministrator]: svc-ldap

   Note

   Review the password expiration settings of this account, once created.

2. Create a group for RHOSP users, called grp-openstack. Only members of this group can have permissions assigned in OpenStack Identity.

   # ipa group-add --desc="OpenStack Users" grp-openstack

3. Set the svc-ldap account password and add it to the grp-openstack group:

   # ipa passwd svc-ldap
   # ipa group-add-member --users=svc-ldap grp-openstack

4. Login as svc-ldap user and change the password when prompted:

   # kinit svc-ldap

Procedure

1. In your IdM environment, locate the LDAPS certificate. This file can be located using /etc/openldap/ldap.conf:

   TLS_CACERT /etc/ipa/ca.crt

2. Copy the file to the Controller node that runs the keystone service. For example, the scp command copies the ca.crt file to the node node.lab.local:

   # scp /etc/ipa/ca.crt root@node.lab.local:/root/

3. Copy the ca.crt file to the certificate directory. This is the location that the keystone service will use to access the certificate:

   # cp ca.crt /etc/pki/ca-trust/source/anchors

4. Optional: If you need to run diagnostic commands, such as ldapsearch, you also need to add the certificate to the RHEL certificate store:

   1. 3. On the Controller node, convert the .crt to .pem format:

      # openssl x509 -in ca.crt -out ca.pem -outform PEM

   2. Install the .pem on the Controller node. For example, in Red Hat Enterprise Linux:

      # cp ca.pem /etc/pki/ca-trust/source/anchors/
      # update-ca-trust

Procedure

1. In the heat template for your deployment, set the KeystoneLDAPDomainEnable flag to true. This configures the domain_specific_drivers_enabled option in keystone within the identity configuration group.
2. Add a specification of the LDAP backend configuration by setting the KeystoneLDAPBackendConfigs parameter in tripleo-heat-templates, where you can then specify your required LDAP options.

3. 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/

4. 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 named testdomain:

       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

   Note

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

5. 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 and domain2; each will have a different LDAP domain with its own configuration.

1. Get the ID of the LAB domain:

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

2. Get the ID of the admin user from the default domain:

   $ openstack user list --domain default | grep admin
   | 3d75388d351846c6a880e53b2508172a | admin      |

3. 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_      |
     +----------------------------------+---------------+

4. Use the 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

Procedure

1. 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  |
     +------------------------------------------------------------------+---------------------+

2. 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 |
     +----------------------------------+---------------+

3. 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 the demo project, you must add the group to the member 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_

Procedure

1. 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          |
   +------------------------------------------------------------------+----------------+

2. 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 |
     +----------------------------------+---------------+

3. 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 the demo project, you add them to the member 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_

4. If you want user1 to be an administrative user of the demo project, add the user to the admin role:

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

Procedure

1. 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. |
   +----------------------------------+---------+---------+----------------------------------------------------------------------+

2. 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 the grp-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

Procedure

1. Create a test user in the external user management service, and add the user to the grp-openstack group.
2. In Red Hat OpenStack Platform, add the user to the _member_ role of the demo project.
3. Log in to the dashboard with 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.

Procedure

1. Test the LDAP connection by using the ldapsearch command 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

   Note

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

2. Use the nc command to check that 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.