Integrating RHEL systems directly with Windows Active Directory

Procedure

1. Install the following packages:

   # dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation

2. Configure the local RHEL system with POSIX ID mapping disabled using the realm join command with the --automatic-id-mapping=no option. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

   # realm join --automatic-id-mapping=no ad.example.com

3. If you already joined a domain, you can manually disable POSIX ID Mapping in SSSD:

   1. Open the /etc/sssd/sssd.conf file.
   2. In the AD domain section, add the ldap_id_mapping = false setting.

   3. Remove the SSSD caches:

      rm -f /var/lib/sss/db/*

   4. Restart SSSD:

      systemctl restart sssd

      SSSD now uses POSIX attributes from AD, instead of creating them locally.

   Note

   You must have the relevant POSIX attributes (uidNumber, gidNumber, unixHomeDirectory, and loginShell) configured for the users in AD.

Procedure

1. Open the /etc/sssd/sssd.conf configuration file in a text editor.

2. Add the following options to the [domain] section for your AD domain to set the DNS record refresh interval to 12 hours, disable updating PTR records, and set the DNS record Time To Live (TTL) to 1 hour.

   [domain/ad.example.com]
   id_provider = ad
   ...
   dyndns_refresh_interval = 43200
   dyndns_update_ptr = false
   dyndns_ttl = 3600

3. Save and close the /etc/sssd/sssd.conf configuration file.

4. Restart the SSSD service to load the configuration changes.

   [root@client ~]# systemctl restart sssd

   Note

   You can disable dynamic DNS updates by setting the dyndns_update option in the sssd.conf file to false:

   [domain/ad.example.com]
   id_provider = ad
   ...
   
   dyndns_update = false

Procedure

1. If your AD requires the deprecated RC4 encryption type for Kerberos authentication, enable support for these ciphers in RHEL:

   # update-crypto-policies --set DEFAULT:AD-SUPPORT

2. Install the following packages:

   # dnf install realmd oddjob-mkhomedir oddjob samba-winbind-clients \
        samba-winbind samba-common-tools samba-winbind-krb5-locator \
        rb5-workstation

3. To share directories or printers on the domain member, install the samba package:

   # dnf install samba

4. Backup the existing /etc/samba/smb.conf Samba configuration file:

   # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

5. Join the domain. For example, to join a domain named ad.example.com:

   # realm join --membership-software=samba --client-software=winbind ad.example.com

   Using the previous command, the realm utility automatically:

   • Creates a /etc/samba/smb.conf file for a membership in the ad.example.com domain
   • Adds the winbind module for user and group lookups to the /etc/nsswitch.conf file
   • Updates the Pluggable Authentication Module (PAM) configuration files in the /etc/pam.d/ directory
   • Starts the winbind service and enables the service to start when the system boots

6. Optional: Set an alternative ID mapping back end or customized ID mapping settings in the /etc/samba/smb.conf file.

   For details, see Understanding and configuring Samba ID mapping.

7. Edit the /etc/krb5.conf file and add the following section:

   [plugins]
       localauth = {
           module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
           enable_only = winbind
       }

8. Verify that the winbind service is running:

   # systemctl status winbind

   Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago

   Important

   To enable Samba to query domain user and group information, the winbind service must be running before you start smb.

9. If you installed the samba package to share directories and printers, enable and start the smb service:

   # systemctl enable --now smb

Verification

1. Display an AD user’s details, such as the AD administrator account in the AD domain:

   # getent passwd "AD\administrator"

   AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash

2. Query the members of the domain users group in the AD domain:

   # getent group "AD\Domain Users"

   AD\domain users:x:10000:user1,user2

3. Optional: Verify that you can use domain users and groups when you set permissions on files and directories. For example, to set the owner of the /srv/samba/example.txt file to AD\administrator and the group to AD\Domain Users:

   # chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt

4. Verify that Kerberos authentication works as expected:

   1. On the AD domain member, obtain a ticket for the administrator@AD.EXAMPLE.COM principal:

      # kinit administrator@AD.EXAMPLE.COM

   2. Display the cached Kerberos ticket:

      # klist

      Ticket cache: KCM:0
      Default principal: administrator@AD.EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      01.11.2018 10:00:00  01.11.2018 20:00:00  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
              renew until 08.11.2018 05:00:00

5. Display the available domains:

   # wbinfo --all-domains

   BUILTIN
   SAMBA-SERVER
   AD

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create ~/vault.yml

      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      usr: administrator
      pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Active Directory integration
     hosts: managed-node-01.example.com
     vars_files:
       - ~/vault.yml
     tasks:
       - name: Join an Active Directory
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.ad_integration
         vars:
           ad_integration_user: "{{ usr }}"
           ad_integration_password: "{{ pwd }}"
           ad_integration_realm: "ad.example.com"
           ad_integration_allow_rc4_crypto: false
           ad_integration_timesync_source: "time_server.ad.example.com"

   The settings specified in the example playbook include the following:

   ad_integration_allow_rc4_crypto: <true|false>

   Configures whether the role activates the AD-SUPPORT crypto policy on the managed node. By default, RHEL does not support the weak RC4 encryption but, if Kerberos in your AD still requires RC4, you can enable this encryption type by setting ad_integration_allow_rc4_crypto: true.

   Omit this the variable or set it to false if Kerberos uses AES encryption.

   ad_integration_timesync_source: <time_server>

   Specifies the NTP server to use for time synchronization. Kerberos requires a synchronized time among AD domain controllers and domain members to prevent replay attacks. If you omit this variable, the ad_integration role does not utilize the timesync RHEL system role to configure time synchronization on the managed node.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Add the following parameter to the AD provider in your /etc/sssd/sssd.conf file:

   ad_maximum_machine_account_password_age = value_in_days

2. Restart SSSD:

   # systemctl restart sssd

3. To disable the automatic Kerberos host keytab renewal, set ad_maximum_machine_account_password_age = 0.

Procedure

1. Remove a system from an identity domain using the realm leave command. The command removes the domain configuration from SSSD and the local system.

   # realm leave ad.example.com

   Note

   When a client leaves a domain, AD does not delete the account and only removes the local client configuration. To delete the AD account, run the command with the --remove option. Initially, an attempt is made to connect without credentials, but you are prompted for your user password if you do not have a valid Kerberos ticket. You must have rights to remove an account from Active Directory.

2. Use the -U option with the realm leave command to specify a different user to remove a system from an identity domain.

   By default, the realm leave command is executed as the default administrator. For AD, the administrator account is called Administrator. If a different user was used to join to the domain, it might be required to perform the removal as that user.

   # realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'

   The command first attempts to connect without credentials, but it prompts for a password if required.

1. Active Directory (AD) child domain subdomain2.ad.example.com
2. AD child domain subdomain1.ad.example.com
3. AD root domain ad.example.com

Procedure

1. Open the /etc/sssd/sssd.conf file in a text editor.

2. Set the domain_resolution_order option in the [sssd] section of the file.

   domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com

3. Save and close the file.

4. Restart the SSSD service to load the new configuration settings.

   [root@ad-client ~]# systemctl restart sssd

Procedure

1. Create an MSA for the host in the production.example.com AD domain.

   [root@client ~]# adcli create-msa --domain=production.example.com

2. Display information about the MSA from the Kerberos keytab that was created. Make note of the MSA name:

   [root@client ~]# klist -k /etc/krb5.keytab.production.example.com

   Keytab name: FILE:/etc/krb5.keytab.production.example.com
   KVNO Principal
   ---- ------------------------------------------------------------
      2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

3. Open the /etc/sssd/sssd.conf file and choose the appropriate SSSD domain configuration to add:

   • If the MSA corresponds to an AD domain from a different forest, create a new domain section named [domain/<name_of_domain>], and enter information about the MSA and the keytab. The most important options are ldap_sasl_authid, ldap_krb5_keytab, and krb5_keytab:

     [domain/production.example.com]
     ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
     ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
     krb5_keytab = /etc/krb5.keytab.production.example.com
     ad_domain = production.example.com
     krb5_realm = PRODUCTION.EXAMPLE.COM
     access_provider = ad
     ...

     Warning

     Even with an existing trust relationship, sssd-ad requires a MSA in the second forest.

   • If the MSA corresponds to an AD domain from the local forest, create a new sub-domain section in the format [domain/root.example.com/sub-domain.example.com], and enter information about the MSA and the keytab. The most important options are ldap_sasl_authid, ldap_krb5_keytab, and krb5_keytab:

     [domain/ad.example.com/production.example.com]
     ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
     ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
     krb5_keytab = /etc/krb5.keytab.production.example.com
     ...

Procedure

1. Optional: Display the current Key Version Number (KVNO) for the MSA in the Kerberos keytab. The current KVNO is 2.

   [root@client ~]# klist -k /etc/krb5.keytab.production.example.com

   Keytab name: FILE:/etc/krb5.keytab.production.example.com
   KVNO Principal
   ---- ------------------------------------------------------------
      2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

2. Update the password for the MSA in the production.example.com AD domain.

   [root@client ~]# adcli update --domain=production.example.com --host-keytab=/etc/krb5.keytab.production.example.com --computer-password-lifetime=0