Procedure

1. Install the following packages:

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

2. To display information for a specific domain, run realm discover and add the name of the domain you want to discover:

   # realm discover ad.example.com
   ad.example.com
     type: kerberos
     realm-name: AD.EXAMPLE.COM
     domain-name: ad.example.com
     configured: no
     server-software: active-directory
     client-software: sssd
     required-package: oddjob
     required-package: oddjob-mkhomedir
     required-package: sssd
     required-package: adcli
     required-package: samba-common

   The realmd system uses DNS SRV lookups to find the domain controllers in this domain automatically.

   Note

   The realmd system can discover both Active Directory and Identity Management domains. If both domains exist in your environment, you can limit the discovery results to a specific type of server using the --server-software=active-directory option.

3. Configure the local RHEL system with the realm join command. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

   # realm join ad.example.com

Procedure

1. Install the following packages:

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

2. Configure the local RHEL system with 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 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

Procedure

1. Install required packages.

   # yum install sssd realmd adcli samba-common-tools oddjob oddjob-mkhomedir

2. Use realmd to join the first AD domain, addomain1.com.

   # realm join ADDOMAIN1.COM

3. Rename the system keytab to a unique name.

   # mv /etc/krb5.keytab /etc/addomain1.com.krb5.keytab

4. Use adcli to join the second AD domain, and any additional domains. Use the -K option to specify a unique path for the Kerberos keytab where host credentials will be written.

   # adcli join -D dc2.addomain2.com -K /etc/addomain2.com.krb5.keytab

5. Modify /etc/krb5.conf.

   • Add the includedir option to include SSSD configuration files.

   • Enable DNS lookups for AD Domain Controllers with the dns_lookup_kdc option.

     includedir /var/lib/sss/pubconf/krb5.include.d/
     
     [logging]
      default = FILE:/var/log/krb5libs.log
      kdc = FILE:/var/log/krb5kdc.log
      admin_server = FILE:/var/log/kadmind.log
     
     [libdefaults]
      default_realm = ADDOMAIN1.COM
      dns_lookup_realm = false
      dns_lookup_kdc = true
      ticket_lifetime = 24h
      renew_lifetime = 7d
      forwardable = true
     
     ...

6. Modify /etc/sssd/sssd.conf to include information about all AD domains in use.

   [sssd]
   services = nss, pam
   config_file_version = 2
   domains = addomain1.com, addomain2.com
   
   [domain/addomain1.com]
   id_provider = ad
   access_provider = ad
   krb5_keytab = /etc/addomain1.com.krb5.keytab
   ldap_krb5_keytab = /etc/addomain1.com.krb5.keytab
   ad_server = dc1.addomain1.com
   ad_maximum_machine_account_password_age = 0
   use_fully_qualified_names = true
   default_shell=/bin/bash
   override_homedir=/home/%d/%u
   
   [domain/addomain2.com]
   id_provider = ad
   access_provider = ad
   krb5_keytab = /etc/addomain2.com.krb5.keytab
   ldap_krb5_keytab = /etc/addomain2.com.krb5.keytab
   ad_server = dc2.addomain2.com
   ad_maximum_machine_account_password_age = 0
   use_fully_qualified_names = true
   default_shell=/bin/bash
   override_homedir=/home/%d/%u
   
   [nss]
   
   [pam]

   • For each domain section, specify the path to the Kerberos keytab that corresponds to each domain with the krb5_keytab and ldap_krb5_keytab options.
   • Set ad_maximum_machine_account_password_age = 0 to disable renewing host Kerberos keys.
   • Set use_fully_qualified_names = true to differentiate users from different domains.
   • Set override_homedir = /home/%d/%u so users (%u) from different domains (%d) each receive unique home directories. For example, the home directory for user linuxuser@addomain1.com is /home/addomain1.com/linuxuser.

7. SSH retrieves host keys from the system keytab and provides single sign-on functionality through GSSAPI/Kerberos. If you would like to use single sign-on, copy all current Kerberos host keys to the /etc/kbr5.keytab system keytab.

   # ktutil
   ktutil:  rkt /etc/addomain1.com.krb5.keytab
   ktutil:  rkt /etc/addomain2.com.krb5.keytab
   ktutil:  wkt /etc/krb5.keytab

8. Restart and enable the SSSD service.

   # systemctl restart sssd
   # systemctl enable sssd

Verification steps

1. Display user details for users from each AD domain:

   # id administrator@addomain1.com
   uid=1240800500(administrator@addomain1.com) gid=1240800513(domain users@addomain1.com) groups=1240800513(domain users@addomain1.com),1240800512(domain admins@addomain1.com),1240800518(schema admins@addomain1.com),1240800520(group policy creator owners@addomain1.com),1240800572(denied rodc password replication group@addomain1.com),1240800519(enterprise admins@addomain1.com)
   
   # id administrator@addomain2.com
   uid=1013800500(administrator@addomain2.com) gid=1013800500(administrator@addomain2.com) groups=1013800500(administrator@addomain2.com),1013800513(domain users@addomain2.com)

2. Log in as a user from each domain and verify the correct home directory is created for the user.

   # ssh administrator@addomain1.com@localhost
   administrator@addomain1.com@localhost's password:
   Creating directory '/home/addomain1.com/administrator'.
   
   $ pwd
   /home/addomain1.com/administrator

   # ssh administrator@addomain2.com@localhost
   administrator@addomain2.com@localhost's password:
   Creating directory '/home/addomain2.com/administrator'.
   
   $ pwd
   /home/addomain2.com/administrator

Procedure

1. Grant access to all users:

   # realm permit --all

2. Grant access to specific users:

   $ realm permit aduser01@example.com
   $ realm permit 'AD.EXAMPLE.COM\aduser01'

Verification steps

1. Use SSH to log in to the server as the aduser01@example.com user:

   $ ssh aduser01@example.com@server_name
   [aduser01@example.com@server_name ~]$

2. Use the ssh command a second time to access the same server, this time as the aduser02@example.com user:

   $ ssh aduser02@example.com@server_name
   Authentication failed.

Procedure

1. Deny access to all users within the domain:

   # realm deny --all

   This command prevents realm accounts from logging into the local machine. Use realm permit to restrict login to specific accounts.

2. Verify that the domain user’s login-policy is set to deny-any-login:

   [root@replica1 ~]# realm list
   example.net
     type: kerberos
     realm-name: EXAMPLE.NET
     domain-name: example.net
     configured: kerberos-member
     server-software: active-directory
     client-software: sssd
     required-package: oddjob
     required-package: oddjob-mkhomedir
     required-package: sssd
     required-package: adcli
     required-package: samba-common-tools
     login-formats: %U@example.net
     login-policy: deny-any-login

3. Deny access to specific users by using the -x option:

   $ realm permit -x 'AD.EXAMPLE.COM\aduser02'

Procedure

1. Stop the SSSD service.

   [root@server ~]# systemctl stop sssd

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

3. Set ad_gpo_access_control to permissive in the domain section for the AD domain.

   [domain/example.com]
   ad_gpo_access_control=permissive
   ...

4. Save the /etc/sssd/sssd.conf file.

5. Restart the SSSD service to load configuration changes.

   [root@server ~]# systemctl restart sssd

Procedure

1. Within Active Directory Users and Computers, create an Organizational Unit (OU) to associate with the new GPO:

   1. Right-click on the domain.
   2. Choose New.
   3. Choose Organizational Unit.
2. Click on the name of the Computer Object that represents the RHEL host (created when it joined Active Directory) and drag it into the new OU. By having the RHEL host in its own OU, the GPO targets this host.

3. Within the Group Policy Management Editor, create a new GPO for the OU you created:

   1. Expand Forest.
   2. Expand Domains.
   3. Expand your domain.
   4. Right-click on the new OU.
   5. Choose Create a GPO in this domain.
4. Specify a name for the new GPO, such as Allow SSH access or Allow Console/GUI access and click OK.

5. Edit the new GPO:

   1. Select the OU within the Group Policy Management editor.
   2. Right-click and choose Edit.
   3. Select User Rights Assignment.
   4. Select Computer Configuration
   5. Select Policies.
   6. Select Windows Settings.
   7. Select Security Settings.
   8. Select Local Policies.
   9. Select User Rights Assignment.

6. Assign login permissions:

   1. Double-Click on Allow log on locally to grant local console/GUI access.
   2. Double-click on Allow log on through Remote Desktop Services to grant SSH access.

7. Add the user(s) you would like to access either of these policies to the policies themselves:

   1. Click Add User or Group.
   2. Enter the username within the blank field.
   3. Click OK.