Integrate with Identity Service

1. Configure SELinux:

   # setsebool -P authlogin_nsswitch_use_ldap=on

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

   Full path required for exclude: net:[4026532245].

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/

3. Configure keystone to use multiple back ends:

   Note

   You might need to install crudini using dnf 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

   Note

   If you are using director, note 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 Chapter 4, Using domain-specific LDAP backends with director.

4. Enable multiple domains in dashboard. Add these lines to /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings:

   OPENSTACK_API_VERSIONS = {
       "identity": 3
   }
   OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
   OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'

   Note

   If you are using director, note that /var/lib/config-data/puppet-generated/horizon/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.

   Restart the horizon container to apply the settings:

   $ sudo systemctl restart tripleo_horizon

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

      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
      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
      use_tls                  = False
      tls_cacertfile                  =/etc/pki/ca-trust/source/anchors/anchorsaddc.lab.local.pem
      
      query_scope                  = sub
      chase_referrals                  = false
      
      [identity]
      driver = ldap

      Explanation of each setting:

      Setting	Description
      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.
      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.
      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

7. Restart the keystone service to apply the changes:

   # sudo podman exec -it keystone pkill -HUP -f keystone

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

   2. Get the ID value of the admin user:

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

   3. Get the ID value of the admin role:

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

   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

   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

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

      # openstack user list --domain default

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

2. Retrieve a list of roles:

   # openstack role list
   +----------------------------------+---------------+
   | ID                               | Name          |
   +----------------------------------+---------------+
   | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
   | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
   | 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
   | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
   +----------------------------------+---------------+

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_

1. Retrieve a list of AD users:

   # openstack user list --domain LAB
    +------------------------------------------------------------------+----------------+
   | ID                                                               | Name           |
   +------------------------------------------------------------------+----------------+
   | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
   | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | 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 AD DS username and password, when also entering LAB in the Domain field:

1. Configure SELinux:

   # setsebool -P authlogin_nsswitch_use_ldap=on

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

   Full path required for exclude: net:[4026532245].

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/

3. Configure Identity Service to use multiple back ends:

   Note

   You might need to install crudini using dnf 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

   Note

   If you are using director, note 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 Chapter 4, Using domain-specific LDAP backends with director.

4. Enable multiple domains in dashboard. Add these lines to /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings:

   OPENSTACK_API_VERSIONS = {
       "identity": 3
   }
   OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
   OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'

   Note

   If you are using director, note that /var/lib/config-data/puppet-generated/horizon/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.

   Restart the horizon container to apply the settings:

   $ sudo systemctl restart tripleo_horizon

5. Configure an additional back end:

   1. Create the keystone domain for IdM integration. You will need to decide on a name to use for your new keystone domain, and then create the domain. For example, this command creates a keystone domain named LAB:

      $ openstack domain create LAB

      Note

      If this command is not available, check that you have enabled keystone v3 for your command line session.

   2. Create the configuration file:

      To add the IdM 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 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 =
      group_tree_dn               = cn=groups,cn=accounts,dc=lab,dc=local
      group_objectclass              = groupOfNames
      group_id_attribute            = cn
      group_name_attribute       =  cn
      group_member_attribute  = member
      group_desc_attribute        = description
      use_tls                  = False
      query_scope                  = sub
      chase_referrals                  = false
      tls_cacertfile =/etc/pki/ca-trust/source/anchors/anchorsca.crt
      
      [identity]
      driver = ldap

      Explanation of each setting:

      Setting	Description
      url	The IdM server to use for authentication. Uses LDAPS port 636.
      user	The account in IdM to use for LDAP queries.
      password	The plaintext password of the IdM account used above.
      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.
      user_tree_dn	The path to the OpenStack accounts in IdM.
      user_objectclass	Defines the type of LDAP user. For IdM, use the inetUser type.
      user_id_attribute	Maps the IdM value to use for user IDs.
      user_name_attribute	Maps the IdM value to use for names.
      user_mail_attribute	Maps the IdM value to use for user email addresses.
      user_pass_attribute	Leave this value blank.

      Note

      Integration with an IdM group will only return direct members, and not nested groups. As a result, queries that rely on LDAP_MATCHING_RULE_IN_CHAIN or memberof:1.2.840.113556.1.4.1941: will not currently work with IdM.

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

   # chown 42425:42425 /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf

7. Grant the admin user access to the domain:

   Note

   This does not grant the OpenStack admin account any permissions in IdM. 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                              |
      +---------+----------------------------------+

   2. Get the ID value of the admin user:

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

   3. Get the ID value of the admin role:

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

   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

8. Restart the keystone service to apply the changes:

   $ sudo podman restart keystone

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

1. Retrieve a list of IdM groups:

   $ openstack group list --domain LAB
   +------------------------------------------------------------------+---------------------+
   | ID                                                               | Name                |
   +------------------------------------------------------------------+---------------------+
   | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack       |
   | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin |
   | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo  |
   +------------------------------------------------------------------+---------------------+

2. Retrieve a list of roles:

   $ openstack role list
   +----------------------------------+---------------+
   | ID                               | Name          |
   +----------------------------------+---------------+
   | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
   | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
   | 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
   | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
   +----------------------------------+---------------+

3. Grant the IdM 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_

1. Retrieve a list of IdM users:

   # openstack user list --domain LAB
    +------------------------------------------------------------------+----------------+
   | ID                                                               | Name           |
   +------------------------------------------------------------------+----------------+
   | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
   | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | 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, when also entering LAB in the Domain field:

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.

1. On the undercloud node, install the python3-novajoin package:

   $ sudo dnf install python3-novajoin

2. On the undercloud node, run the novajoin-ipa-setup script, adjusting the values to suit your deployment:

   $ sudo /usr/libexec/novajoin-ipa-setup \
       --principal admin \
       --password <IdM admin password> \
       --server <IdM server hostname> \
       --realm <overcloud cloud domain (in upper case)> \
       --domain <overcloud cloud domain> \
       --hostname <undercloud hostname> \
       --precreate

   In the following section, you will use the resulting One-Time Password (OTP) to enroll the undercloud.

1. The novajoin service is disabled by default. To enable it:

   [DEFAULT]
   enable_novajoin = true

2. You need set a One-Time Password (OTP) to register the undercloud node with IdM:

   ipa_otp = <otp>

3. Set the overcloud’s domain name to be served by neutron’s DHCP server:

   overcloud_domain_name = <domain>

4. Set the appropriate hostname for the undercloud:

   undercloud_hostname = <undercloud FQDN>

5. Set IdM as the nameserver for the undercloud:

   undercloud_nameservers = <IdM IP>

6. For larger environments, you will need to review the novajoin connection timeout values. In undercloud.conf, add a reference to a new file called undercloud-timeout.yaml:

   hieradata_override = /home/stack/undercloud-timeout.yaml

   Add the following options to undercloud-timeout.yaml. You can specify the timeout value in seconds, for example, 5:

   nova::api::vendordata_dynamic_connect_timeout: <timeout value>
   nova::api::vendordata_dynamic_read_timeout: <timeout value>

7. Save the undercloud.conf file.

8. Run the undercloud deployment command to apply the changes to your existing undercloud:

   $ openstack undercloud install

Verification

1. Check the keytab files for a key entry for the undercloud:

    [root@undercloud-0 ~]# klist -kt
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       1 04/28/2020 12:22:06 host/undercloud-0.redhat.local@REDHAT.LOCAL
       1 04/28/2020 12:22:06 host/undercloud-0.redhat.local@REDHAT.LOCAL
   
   
    [root@undercloud-0 ~]# klist -kt /etc/novajoin/krb5.keytab
    Keytab name: FILE:/etc/novajoin/krb5.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       1 04/28/2020 12:22:26 nova/undercloud-0.redhat.local@REDHAT.LOCAL
       1 04/28/2020 12:22:26 nova/undercloud-0.redhat.local@REDHAT.LOCAL

2. Test the system /etc/krb.keytab file with the host principle:

    [root@undercloud-0 ~]# kinit -k
    [root@undercloud-0 ~]# klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: host/undercloud-0.redhat.local@REDHAT.LOCAL
   
    Valid starting       Expires              Service principal
    05/04/2020 10:34:30  05/05/2020 10:34:30  krbtgt/REDHAT.LOCAL@REDHAT.LOCAL
   
    [root@undercloud-0 ~]# kdestroy
    Other credential caches present, use -A to destroy all

3. Test the novajoin /etc/novajoin/krb.keytab file with the nova principle:

    [root@undercloud-0 ~]# kinit -kt /etc/novajoin/krb5.keytab 'nova/undercloud-0.redhat.local@REDHAT.LOCAL'
    [root@undercloud-0 ~]# klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: nova/undercloud-0.redhat.local@REDHAT.LOCAL
   
    Valid starting       Expires              Service principal
    05/04/2020 10:39:14  05/05/2020 10:39:14  krbtgt/REDHAT.LOCAL@REDHAT.LOCAL

1. Connect to your undercloud:

   $ source ~/stackrc

2. Configure the control plane subnet to use IdM as the DNS name server:

   $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>

3. Set the DnsServers parameter in an environment file to use your IdM server:

   parameter_defaults:
     DnsServers: ["<idm_server_address>"]

   This parameter is usually defined in a custom network-environment.yaml file.

1. To enable IdM integration, create a copy of the /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml environment file:

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
     /home/stack/templates/custom-domain.yaml

2. Edit the /home/stack/templates/custom-domain.yaml environment file and set the CloudDomain and CloudName* values to suit your deployment. For example:

   parameter_defaults:
     CloudDomain: lab.local
     CloudName: overcloud.lab.local
     CloudNameInternal: overcloud.internalapi.lab.local
     CloudNameStorage: overcloud.storage.lab.local
     CloudNameStorageManagement: overcloud.storagemgmt.lab.local
     CloudNameCtlplane: overcloud.ctlplane.lab.local

3. Include the following environment files in the overcloud deployment process:

   • /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
   • /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml

   • /home/stack/templates/custom-domain.yaml

     For example:

     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 /home/stack/templates/custom-domain.yaml \

     As a result, the deployed overcloud nodes will be automatically enrolled with IdM.

4. This only sets TLS for the internal endpoints. For the external endpoints you can use the normal means of adding TLS with the /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml environment file (which must be modified to add your custom certificate and key). Consequently, your openstack deploy command would be similar to this:

   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 /home/stack/templates/custom-domain.yaml \
     -e /home/stack/templates/enable-tls.yaml

5. Alternatively, you can also use IdM to issue your public certificates. In that case, you need to use the /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml environment file. For example:

   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 /home/stack/templates/custom-domain.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml