How To Join A RHEL/CentOS 7/8.x System To A Windows Active Directory Domain

Install required packages

1. The first step is to ensure all the required packages are installed. Depending on the current level of installation (Minimal Install, Server with GUI etc) some or all of the packages may already be present.

sudo yum update -y (ensure your current packages are up-to-date).

sudo yum install -y realmd sssd oddjob adcli chrony

Synchronize time

2. Next step is to ensure the clients time is synchronized. Too much drift from the domain controller and the domain join will fail.
sudo systemctl enable chronyd --now will ensure the service is started and will start on boot
If you wish to specify the time server to synchronize with (many organizations have their own), you will need to edit the chrony configuration file.
sudo vi /etc/chrony.conf

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#pool 2.rhel.pool.ntp.org iburst
server mytimeserver.example.com iburst

Any edits made to the configuration will require the service to be restarted:
sudo systemctl restart chronyd

Some useful commands for checking status are:
chronyc sources (view information about current time sources)
chronyc tracking (view parameters on system clock performance)
timedatectl (view current time, date and sync status)

More information on managing chrony can be found here.

Configure Kerberos

3. The next step is to edit the kerberos configuration file:
sudo vi /etc/krb5.conf
Use this example as a template for your configuration, replacing example.com with your required domain. (It’s important to use uppercase/lowercase where applicable)

[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
 default_ccache_name = KEYRING:persistent:%{uid}
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac
 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac arcfour-hmac-#md5

[realms]
EXAMPLE.COM = {
     kdc = example.com
     admin_server = example.com
}

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

If the domain join ultimately fails the first step in remediation could be to tweak these options in the kerberos configuration.

• If rdns = false is set to false, it prevents the use of reverse DNS resolution when translating hostnames into service principal names. The default value is true. Setting this flag to false is more secure, but may force users to exclusively use fully qualified domain names when authenticating to services.
• If dns_lookup_realm = false is set to false then DNS is not contacted for realm.
• If dns_lookup_kdc = false is set to false then DNS is not contacted for kdc server.

Join the domain

4. This is a good point to stop and read the man page for the realmd package and the options available for the realm command:
man realm

Providing DNS is functioning correctly and you have the required domain admin user credentials, the join command could look something like this:
realm join <example.com> -U <domainadminuser>
you’ll be prompted for the user password after which you should now be joined to the domain. Test with the command: realm list

SSSD

5. The domain join operation does a pretty good job of creating a default sssd configuration but it does benefit from some minor tweaking. The file mode must be set to 600, so to access you will have to do so as root user.

[root@control ~]# cd /etc/sssd
[root@control sssd]# ll
total 4
drwx--x--x. 2 sssd sssd   6 Jan 18 03:11 conf.d
drwx--x--x. 2 root root   6 Jan 18 03:11 pki
-rw-------. 1 root root 415 Mar 26 23:50 sssd.conf

vi /etc/sssd/sssd.conf

[sssd]
domains = example.com
config_file_version = 2
services = pam, nss

[domain/EXAMPLE.COM]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
ad_gpo_access_control = permissive
ldap_id_mapping = True

SSSD settings that you may want to tweak:

• ldap_id_mapping = False. SSSD expects that the UID and GID have been manually stored in Active Directory (AD User Attributes: uidNumber,gidNumber). When true, uidNumber and gidNumber are ignored. Refer to the man page sssd-ldap for more details.
• ad_gpo_access_control = permissive. Configures SSSD to apply GPO access control and can retrieve policies applicable to host systems and AD users. The ‘permissive’ value specifies that GPO-based access control is evaluated but not enforced. Read more on this setting here.
• fallback_homedir = /home/%u. Sets a fallback home directory format, which is used only if a home directory is not defined in AD.
• override_homedir = /home/%u. Sets a home directory template, which always overrides the home directory defined in AD
• use_fully_qualified_names = False. AD users can log in without providing their fully qualified domain name, just username.
• cache_credentials = True. Ensures that a user can login if the machine is ever offline.

Additional configuration options for SSSD can be found here.

Making any changes to the sssd configuration file will require the service to be restarted to take effect.
sudo systemctl restart sssd

To test if your configuration will work, you can use the id command to retrieve user data from active directory. Depending on the sssd settings:
id <domain_user> or id <[email protected]>

Additional Configuration Options

SUDO privileges for domain users

You may wish or be required to grant certain domain users or groups sudo privileges. This is easiest by creating and adding them to a file in the /etc/sudoers.d directory
vi /etc/sudoers.d/domain_sudoers

bob ALL=(ALL) ALL
alice ALL=(ALL) NOPASSWD: ALL
%devgroup ALL=(ALL) ALL
%Domain\ Admins ALL=(ALL) NOPASSWD: ALL

Note the use of % when including group names and the use of \ when a group name has a space character.

Register client in DNS

In many cases, the AD server is also the DNS provider. It’s relatively simple, but to register the client in DNS requires that a few additional configuration options are in place.

1. Install samba-client-tools
yum install -y samba-common-tools samba-client

2. Configure /etc/samba/smb.conf

[global]
        workgroup = EXAMPLE
        realm = EXAMPLE.COM
        security = ads
        kerberos method = secrets and keytab
        password server = AD-server.example.com #ipaddr also works here

[... file truncated ...]

3. Ensure these settings are in place and correct:

• /etc/resolv.conf (address of dns server is correct)
• use hostnamectl set-hostname <hostname> to set the hostname if not done already.
• /etc/hosts (your hostname is listed)

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.0.101 hostname.example.com hostname

4. Register with DNS using this command:
net ads dns register -U <domainadminuser>
you’ll be prompted for the user password after which the client should now be registered in DNS.