Joining RHEL systems to an AD domain using SSSD

AI-generated Image

The System Security Services Daemon (SSSD) is a system service that allows you to access remote directories and authentication mechanisms.

SSSD works in two stages:

1. It connects the client to a remote provider to retrieve identity and authentication information.
2. It uses the obtained authentication information to create a local cache of users and credentials on the client.

To integrate a RHEL system with an Active Directory domain, you can utilize two key components:

SSSD and Realmd.

SSSD facilitates interaction with the central identity and authentication source, while Realmd detects available domains and configures the necessary RHEL system services.

Packages To Install:

Ensure that you install the following packages:

yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Connection Steps:

1. Discover the AD Domain:

Run the following command to discover the AD domain:

realm discover [AD domain]

Example:

realm discover ritaj.local

This command will display the domain’s name, type, and capabilities.

2. Join the Linux System to the AD Domain:

Join the Linux system to the AD domain using the following command:

realm join --user=[domain user account] [AD domain]

It is sufficient to have “Create computer object” permissions to join a computer to a domain.

Example:

realm join --user=rf.biri ritaj.local

Confirm the successful join operation by running the following command:

realm list

The output should display the domain details, confirming that the Linux system has successfully joined the AD domain using Kerberos authentication, with SSSD as the client software:

ritaj.local
type: kerberos
realm-name: RITAJ.LOCAL
domain-name: ritaj.local
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@ritaj.local
login-policy: allow-realm-logins

Confirm that the computer object was added

SSSD Configuration:

SSSD is the primary interface between the directory service and the module requesting authentication services, Realmd.

After joining the AD domain, the SSSD configuration file (/etc/sssd/sssd.conf) is automatically updated with the necessary information for successful logon. However, certain configurations may need to be added manually to the file.

Edit the configuration file:

nano /etc/sssd/sssd.conf

If you want to restrict the login to a specific AD group, add the following line:

access_provider = simple
simple_allow_groups = Linux #This is an example 

If you prefer not to type the full user account name during login, comment the following line:

use_fully_qualified_names = False

To grant sudo permissions to members of an Active Directory group on the machine, follow these steps:

Add this Line to the SSSD configuration file /etc/sssd/sssd.conf:

ad_gpo_access_control = permissive

If for example, the group name is Linux, add the following line to the sudoers file /etc/sudoers to grant sudo access to the Linux group:

%Linux ALL=(ALL) ALL

Note: If a local group with the same name exists, this will not work.

When ad_gpo_access_control is set to permissive, it means that SSSD will allow GPOs to be applied to the system, but it will not enforce any access control restrictions. It can be useful in scenarios where you want to test or evaluate GPO settings without immediately enforcing them.

To use stricter access control settings, use ad_gpo_access_control = enforcing.

Once the configuration is complete, restart SSSD to apply the settings:

systemctl restart sssd

Testing:

To verify the setup, switch to a user account from the AD domain:

[ritaj@rhel-test ~]$ su test
Password:
Password expired. Change your password now.
Current Password:
New password:
Retype new password:
[test@rhel-test ritaj]$

SSSD Version:

Run the following command to check the SSSD version if needed:

sssd --version

SSSCTL:

https://sssd.io/design-pages/sssctl.html

sssctl is a command-line tool that provides a unified way to obtain information about the Security System Services Daemon (SSSD) status.

sssctl domain-status [AD domain]

You can run the following command to check for configuration issues:

sssctl config-check

It verifies the syntax and validity of the SSSD configuration files, ensuring that they are correctly set up and consistent. It checks the configuration files located in the /etc/sssd directory, such as sssd.conf and any additional domain-specific configuration files.

Leaving the AD Domain:

To leave the AD domain, use the following command:

Realm leave

When you use the realm leave command to leave an AD domain, the computer object associated with that system is not automatically deleted from the domain. The realm leave command only removes the system’s association with the AD domain.

If you want to leave the domain and delete the computer object from the AD domain entirely, you can use the following command:

realm leave --remove --user=[Domain User]

SSSD Errors:

For investigating SSSD issues, the logs can be found in the following directory:

/var/log/sssd/

Name conflict in AD:

When joining hostnames longer than 15 characters to the domain using SSSD, the computer object name will be cut short in AD to only 15 characters.

Example:

Server Hostname

SRV-PROD-RFAPP-01

SRV-PROD-RFAPP-02

When joining both servers to the domain, there will only be one computer object with the name (SRV-PROD-RFAPP-) in AD, and there will be an issue with the SPN attribute in that computer object (it will contain both hostnames).

If there are conflicts or duplicate SPNs within the AD environment, it can cause issues with authentication.

SSSD typically uses a keytab file to store the necessary credentials for Kerberos authentication. The keytab file contains the encryption keys associated with the SPNs. It’s important to ensure that the keytab file used by SSSD is generated correctly and contains the appropriate SPNs to enable successful authentication.

Conflicting DNS entries:

Preauthentication failed indicates that the /etc/krb5.keytab file has become invalid and cannot be used by SSSD for establishing the connection to AD.

One example is one IP having two different records in DNS, to confirm the issue run the following command which is used to list the entries in a keytab file along with their key types and encryption types

klist -kte

If you noticed the wrong hostname / old hostname, it should confirm your issue.

Solution:

Leaving the domain will delete the krb5.keytab file:

Realm leave

The file might not get deleted by leaving the realm, so just delete it manually.

Deleting the conflicting DNS entries, and re-joining the domain again will update the contents of the krb5.keytab file:

realm join --user=[user account] [AD domain]

Name Servers:

SSSD relies on DNS for service location and name resolution. If there are any DNS resolution issues, it can impact the functionality of SSSD and the ability to authenticate using Kerberos.

The IP addresses specified in the resolv.conf file should typically be those of the domain controllers (DCs) or DNS servers that are authoritative for the Active Directory (AD) domain you want to join.

References:

• Chapter 2. Understanding SSSD and its benefits Red Hat Enterprise Linux 9
• Introduction — sssd.io
• How often is machine account password renewed with sssd? — Red Hat Customer Portal
• How to update krb5.keytab file on RHEL system using ‘adcli’ utility without re-joining the system to AD domain — Red Hat Customer Portal
• How to join a Linux system to an Active Directory domain | Enable Sysadmin (redhat.com)