Linux Active Directory Integration with SSSD, SSH, and PAM – Guide

In Best Practices & Patterns, Linux Basics, Security & Hardening, System Administration, Troubleshooting
August 5, 2025
151 Views

1. Integration Overview – SSSD, SSHD, PAM, and Active Directory

When a RHEL 9 system is integrated with Microsoft Active Directory (AD), several components work together to authenticate users:

Active Directory (AD): Acts as the central identity store, holding user accounts, group memberships, and credentials.
System Security Services Daemon (SSSD): A service on RHEL that communicates with AD to retrieve user information and verify credentials. SSSD caches user identities and credentials (allowing offline login) and provides interfaces for PAM (authentication) and NSS (name service switch).
Pluggable Authentication Modules (PAM): The authentication framework used by Linux. The SSH daemon (and other services) use PAM to verify logins. With AD integration, PAM is configured to use pam_sss (SSSD’s PAM module) for authentication and account information. For example, when a user logs in, PAM prompts SSSD to validate the username/password against AD and check account policies.
Secure Shell (SSH) and NSS: The SSH daemon (sshd) handles remote logins. It delegates authentication to PAM (which calls SSSD), and it uses NSS to resolve user and group information. NSS (Name Service Switch) is configured to use SSSD for user and group lookups (so that getent passwd <user> or SSH can find AD users via SSSD).

Login Flow: When a domain user attempts to SSH into the RHEL server, sshd invokes PAM. PAM’s configuration includes SSSD’s modules, so the user’s credentials are verified via SSSD (which communicates with AD using LDAP/Kerberos). If the password (or Kerberos ticket) is correct, SSSD tells PAM the auth succeeded. PAM then permits the login, and through NSS, the system obtains the user’s UID, GID, home directory, shell, and groups from SSSD/AD. If configured, PAM will also create a home directory on first login. This integration allows AD domain users to log in with their AD username and password (no local Linux user needed). SSSD’s caching means that if the AD server becomes unreachable, users who have logged in before can still log in offline with cached credentials.

Note: By default, AD users may need to log in as username@domain (UPN style) on Linux. SSSD can be configured to allow short names (e.g. just username) if the domain is set as default (using use_fully_qualified_names = False) – see configuration below. It’s important to avoid username collisions between local and AD users.

2. Initial Setup and Domain Join (CLI Only)

Prerequisites: Ensure the RHEL server’s DNS is pointed to the AD domain’s DNS servers and that the system’s time is synchronized with the domain (Kerberos requires time sync within 5 minutes). It’s also recommended to set the host’s hostname to a unique FQDN (e.g. rhelhost.example.com) before joining the domain. Make sure required ports are open to the AD controllers (e.g. DNS 53, Kerberos 88/464, LDAP 389 or LDAPS 636).

Step 1: Install Required Packages. Install the tools for domain joining, SSSD, and Kerberos. For example:

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

This ensures you have realmd (for easy domain enrollment), SSSD (authentication daemon), adcli (AD joining utility), krb5-workstation (Kerberos client), and oddjob/oddjob-mkhomedir (for automatic home directory creation). For instance, Red Hat documentation suggests installing these in one go.

Step 2: Start SSSD and Oddjob Services. Enable and start SSSD, and start the oddjob daemon (which will handle home dir creation):

systemctl enable --now sssd
systemctl enable --now oddjobd

Ensure SSSD is running before attempting a join. The oddjobd service is needed only if using pam_oddjob_mkhomedir to create homedirs on login.

Step 3: (Optional) Discover the AD Domain. You can use the realm command to discover domain configuration from DNS. For example:

realm discover example.com

If DNS is correctly configured, this will show information about the domain (like domain controllers and realm settings). This step can confirm the server can find the AD domain.

Step 4: Join the RHEL System to the AD Domain. Use the realm join command to enroll in the domain. You’ll need an AD account with permissions to join computers (often a Domain Administrator or a user with delegated rights). For example:

realm join --user=Administrator example.com

You will be prompted for the AD user’s password (or you can use -U "[email protected]" syntax). The above command joins the example.com domain using the Administrator account. The realmd service will automatically configure necessary settings: it creates a computer account in AD, writes the machine keytab (Kerberos credentials) to /etc/krb5.keytab, and updates config files like /etc/sssd/sssd.conf and /etc/krb5.conf. It also calls authselect to enable SSSD for NSS and PAM, and if oddjob-mkhomedir is installed, it enables home directory auto-creation. This means you usually do not have to manually edit PAM or nsswitch files after a successful realm join – the tool will do it.

Example: For a domain ad.example.com, you can run: # realm join ad.example.com and enter credentials. After joining, run realm list to confirm. It should display the domain and show configured: kerberos-member and indicate server-software: active-directory and client-software: sssd – confirming the system is using SSSD for the AD realm.

Step 5: Verify Domain Integration. After the join, test that you can retrieve domain user info. For example:

getent passwd "[email protected]"

This should return the AD user’s info as a Linux user entry if integration is working. For instance:

# getent passwd [email protected] 
[email protected]:*:1450400500:1450400513:Administrator:/home/[email protected]:/bin/bash

. You can also use the id command on a domain user: e.g. id [email protected] should show their UID and group memberships. If these commands return data, the system is successfully talking to AD via SSSD.

Step 6: Test SSH Login. Now try logging in via SSH using an AD account. For example: ssh [email protected]@yourlinux.host (if using fully-qualified names) or ssh [email protected] (if short names are enabled). If everything is correct, you’ll be prompted for the AD password and should get a shell. On first login, the user’s home directory will be created under /home/ (if homedir creation is configured).

Step 7: (Optional) Restrict or Allow Specific Users/Groups. By default, after a join, all AD users can attempt to log in. You can restrict this. For instance, to allow only members of an AD group “LinuxUsers” to log in, you can use the realm permit command or set an access control in SSSD. Example using realmd:

realm permit -g [email protected]

This would update SSSD’s configuration to allow only that group (it effectively sets an access control filter in sssd.conf). Alternatively, you could edit sssd.conf’s domain section to use access_provider = simple and specify simple_allow_groups = LinuxUsers (or use access_provider = ad with ad_access_filter). For simplicity, realm permit/deny is the straightforward way to manage access.

Step 8: Ensure Home Directories Are Created (if not already). If you installed oddjob-mkhomedir, the realm join should have enabled the PAM module for home dirs. To double-check, run authselect list. The active profile should be “sssd with-mkhomedir”. If not, enable it manually:

authselect select sssd with-mkhomedir --force
systemctl restart sssd oddjobd

This ensures that on first login, a directory like /home/<user>@<domain> will be created with proper ownership. (Oddjob’s PAM module will handle this when a user logs in.)

3. Sample Configuration Files

Below are samples of key configuration files after integrating RHEL 9 with AD. These examples assume a domain EXAMPLE.COM (realm) and example.com (DNS domain). Adjust to your environment.

/etc/sssd/sssd.conf – SSSD configuration. This file defines the domain integration with AD and must be owned by root and permission 600 (otherwise SSSD won’t start).

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

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
id_provider = ad
auth_provider = ad
access_provider = ad
fallback_homedir = /home/%u@%d
default_shell = /bin/bash
use_fully_qualified_names = True
ldap_id_mapping = True
cache_credentials = True
krb5_store_password_if_offline = True

Explanation: In this example, SSSD is configured to use the AD provider for the domain example.com. The id_provider=ad, auth_provider=ad, and access_provider=ad direct SSSD to use Active Directory for identity, authentication, and access control, respectively. krb5_realm is the Kerberos realm (usually the uppercase domain). ad_domain is the lowercase DNS domain. We enable caching (cache_credentials=True) to allow offline logins. ldap_id_mapping=True means SSSD will algorithmically map Windows SIDs to Unix UIDs/GIDs (the default behavior). The fallback_homedir template /home/%u@%d means an AD user alice gets home /home/[email protected] by default. use_fully_qualified_names=True forces usernames to appear as [email protected]; if you prefer short names (alice instead of [email protected]), you can set this to False and ensure fallback_homedir = /home/%u (or another scheme to avoid naming collisions). Also note other defaults: by default, enumerate = False (SSSD will not list all domain users), and entry_cache_timeout defaults to 5400 seconds (you can lower it if you want faster cache refresh, e.g. 300s). These can be tweaked as needed.

If your AD users have POSIX attributes (UID, GID, etc.) defined in AD, you might disable SSSD’s automatic ID mapping by adding ldap_id_mapping = False and ensure each AD user has uidNumber/gidNumber. Also consider override_homedir or default_shell if you want to enforce specific shell or homedir patterns. Remember to restart SSSD after any changes to this file.

/etc/krb5.conf – Kerberos configuration. This file defines Kerberos realms and KDCs. With AD, realm join often populates this, but you may customize it. Example:

[logging]
 default = FILE:/var/log/krb5libs.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 rdns = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

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

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

Explanation: default_realm should be your AD realm (typically the uppercase domain). It’s common to disable DNS lookup for realms/KDC (dns_lookup_realm = false, dns_lookup_kdc = false) and explicitly specify your domain controllers under [realms] for reliability. In this example, dc1 and dc2 are AD domain controllers (KDCs). The [domain_realm] mapping ensures that any host in example.com domain is associated with the EXAMPLE.COM realm. We also set rdns = false (to avoid reverse DNS lookups) and specify ticket lifetimes. The forwardable = true allows Kerberos credentials to be forwardable (useful for scenarios where users might want to use their Kerberos tickets on the server). If your AD uses only secure ciphers, you do not need allow_weak_crypto; by default RHEL9 is strict. (In older releases, enabling RC4 (default_tgs_enctypes = rc4-hmac ...) was sometimes necessary for older AD domains, but modern AD supports AES which RHEL9 uses by default.)

/etc/realmd.conf – Realm configuration (used by the realmd service). Typically, this file is empty or minimal after a join, as most settings were applied during realm join. You can pre-configure this file to customize how the join happens. For example:

[example.com]
 fully-qualified-names = no
 automatic-id-mapping = yes
 computer-ou = "OU=LinuxServers,DC=example,DC=com"

This tells realmd that for domain example.com, we prefer short names (no @DOMAIN suffix), we want automatic ID mapping (let SSSD generate UIDs), and to create the computer account in a specific OU in AD (instead of the default Computers container). In practice, you could achieve the same by adding options to the realm join command (e.g. realm join --computer-ou="OU=LinuxServers,DC=example,DC=com" --automatic-id-mapping=yes --user-principal=host/$(hostname)@EXAMPLE.COM example.com as shown in Red Hat docs). After join, realmd may record some of the configuration here for reference, but adjustments to realmd.conf post-join usually require re-joining to take effect.

/etc/nsswitch.conf – Name Service Switch configuration. This file should include sss for passwd, group, etc., so that system queries go through SSSD. Key lines:

passwd:     files sss
shadow:     files sss
group:      files sss

These lines mean “consult local files (/etc/passwd, /etc/group) first, then SSSD”. Realmd (via authselect) will set this automatically. You may also see passwd: files sss systemd on RHEL 9 (systemd for system users), which is fine. Ensure that sss is present for passwd, shadow, and group at least – this is what allows commands like getent passwd domainuser to retrieve AD users via SSSD.

/etc/ssh/sshd_config – OpenSSH daemon configuration. In general, little change is needed here for basic AD authentication because SSH already uses PAM (and we’ve configured PAM/SSSD). Important settings to check:

UsePAM yes
#UseDNS no
GSSAPIAuthentication yes
# GSSAPIKeyExchange yes  (if you want to allow GSSAPI key exchange)

Ensure UsePAM is enabled (default is “yes” on RHEL, which allows PAM to handle logins) and that GSSAPIAuthentication yes is set if you plan to allow Kerberos single sign-on (SSO) for SSH (this lets domain users with a Kerberos TGT use it to authenticate via SSH without a password, if configured). Also, make sure PasswordAuthentication yes is not disabled unless you intend to enforce key-only auth. By default on RHEL9, password and pubkey auth are allowed.

Optionally, you can configure SSH to fetch users’ authorized SSH keys from AD via SSSD. This is an advanced setup: you’d store public keys in an AD attribute (e.g. altSecurityIdentities or a custom attribute) and add the following to sshd_config:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys %u
AuthorizedKeysCommandUser root

This tells sshd to, whenever an SSH key authentication is attempted, call SSSD’s helper to retrieve the user’s keys. SSSD will supply the keys from the AD attribute (as configured in sssd.conf). In our context, this is optional and only needed if you want centralized SSH keys in AD. If used, ensure the corresponding SSSD settings (ldap_user_ssh_public_key etc.) are set (as shown in the note above from the advanced example) and that sssd-ssh service is enabled in sssd.conf’s services list. For most basic setups, this isn’t required.

PAM configuration (e.g. /etc/pam.d/system-auth & password-auth): RHEL uses authselect profiles to manage PAM. After the join, the “sssd” profile with “mkhomedir” should be active. The PAM stack will include lines for pam_sss.so and pam_oddjob_mkhomedir.so. For instance, in /etc/pam.d/password-auth you might see:

auth    sufficient    pam_sss.so forward_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so
password sufficient    pam_sss.so use_authtok
session  optional      pam_sss.so
session  optional      pam_oddjob_mkhomedir.so umask=0077

These lines work as follows: during auth phase, pam_sss is used (after pam_unix) to validate credentials; in account phase, pam_sss checks if the account is allowed (not disabled/expired in AD); in password phase, pam_sss can handle password changes (passing through to AD) if needed; and in session phase, pam_sss establishes the user cache context, and pam_oddjob_mkhomedir will create a home directory if it doesn’t exist (with mode 0700). These were likely configured automatically by authselect/realmd. It’s good practice not to manually edit the system-auth/password-auth files but rather use authselect. (Always keep a root shell open if manually editing PAM, as mistakes can lock out logins!)

4. Common Login and Authentication Issues

Even with correct setup, you may encounter some common issues. Below is a list of issues frequently seen in RHEL-AD integration:

DNS or Discovery Problems: The system can’t find the AD domain controllers. Login attempts may hang or fail, and realm join may say “domain not found”. This often is due to DNS misconfiguration (e.g. /etc/resolv.conf not pointing to the AD DNS).
Time Synchronization Issues: If the RHEL server’s clock is not in sync with AD, Kerberos authentication will fail (common error: “Clock skew too great”). Users won’t be able to log in because Kerberos tickets cannot be obtained.
Domain Join Failures: Errors during realm join such as “Insufficient permissions to join the domain” or “Failed to enroll machine in realm”. This can happen if the account used to join doesn’t have rights, or if the machine account already exists in AD (name conflict), or if required packages/services aren’t installed and running.
SSSD Fails to Start: SSSD service might be down, or won’t start due to configuration errors. A misformatted sssd.conf, wrong file permissions, or missing directories can cause SSSD to not run, resulting in all AD logins failing (falling back to local accounts only).
Cannot Lookup AD Users/Groups: Even after join, id username@domain or getent doesn’t return anything, and logins fail with “user not found”. This indicates an NSS or SSSD communication issue (SSSD might be offline, or nsswitch.conf not configured for sss, etc.).
Authentication Failures (SSSD Online): SSSD is running and can resolve user info, but authentication fails. For example, “Permission denied” on SSH even with correct password. Possible causes: wrong password (of course), the account is locked or expired in AD, the user is not allowed to log in (by access rules), or Kerberos trust issues (machine account problem).
Home Directory or Shell Issues: The user can authenticate but is immediately disconnected or gets an error. This can happen if the user’s shell is set to something invalid, or if the home directory cannot be created (e.g. oddjob not working). For instance, if pam_mkhomedir is not enabled, the user may log in but end up in “/” with no home, or login might fail if the system is configured to deny login when home is missing.
Offline Login Not Working: A user who logged in before should be able to log in while offline (AD unreachable), but cannot. This could be due to SSSD cache settings or the cache being cleared/expired too soon.
Slow Logins or Delays: Logging in with a domain account takes very long. This might be due to DNS reverse lookup timeouts, or SSSD trying multiple domain controllers or global catalog. It can also be caused by SSSD attempting to enumerate a huge number of groups or chasing referrals if the AD forest has multiple domains.
Kerberos Ticket Issues: In environments using Kerberos (e.g. for SSO), you might find that users don’t get a Kerberos TGT on login when expected, or kinit fails. This could be due to improper krb5.conf or the machine keytab being wrong.
Machine Account Password Expiry: AD by default requires computer accounts to change their password every 30 days. SSSD handles this automatically (it will periodically update the machine password). However, if the system was powered off for a long time or SSSD wasn’t running, the machine’s password might expire, leading to trust failure (SSSD log will show kerberos errors for the machine credential). In this case, logins fail until the machine rejoins or the password is reset.

5. Troubleshooting Tips for Common Issues

When issues arise, systematic troubleshooting will help identify the root cause. Here are tips for each of the common problems:

DNS/Discovery Problems: Verify DNS configuration first. Ensure /etc/resolv.conf points to a valid AD DNS server (the AD domain controller or another DNS that knows about the AD domain). Use tools like dig or nslookup to check records:
dig _ldap._tcp.example.com SRV – should list AD LDAP service records.
dig -t SRV _kerberos._udp.example.com – should list Kerberos KDCs.
Also, test basic name resolution: host -t A ad.example.com and host -t SRV _ldap._tcp.ad.example.com. If these fail, fix DNS or add the domain’s DNS server in resolv.conf.
Check that the system’s search domain is set (or use FQDN for the domain).
If realm discover example.com returns nothing, that’s a sign of DNS issues or no connectivity to AD.
Solution: Point to the correct DNS, and ensure the Linux host can reach the AD DCs on the network (firewalls allowing outbound LDAP/Kerberos). Once DNS is fixed, try realm join again.
Time Sync (Kerberos) Issues: If you suspect clock skew:
Compare the output of date on the RHEL system with the AD domain controller’s time. They must usually be within 5 minutes.
Check if chronyd or NTP is running: chronyc tracking for instance.
In logs (journalctl -u sssd or /var/log/secure), Kerberos failures due to time will often say “KDC has expired” or “Clock skew too great”.
Solution: Synchronize time. Enable chronyd (or ntpd) and point it to the same NTP source as the domain, or even the domain controllers themselves. Once time is synced, Kerberos (kinit) should succeed. Configure ongoing NTP to prevent it from drifting again.
Domain Join Failures: For join errors:
Run realm join with -v (verbose) for more detail. It can show at what step it failed (e.g., contacting KDC, or creating the account).
“Insufficient permissions”: Ensure the username used has rights to join computers to the domain (by default, domain Admins or Account Operators). If not, use a proper account or have an AD admin pre-create the computer account.
“Already joined” or “Already a member”: If the host is already in AD (perhaps from a previous join attempt), you might need to remove the old computer account. You can do realm leave to clean up the local configuration, then ask an AD admin to delete the computer object (or use adcli delete-computer). Then try join again. Alternatively, use a different name (realm join --computer-name newname).
Package issues: If realm join complains about missing packages (e.g. “Required packages not installed”), install those (realmd, sssd, etc.) and try again.
Machine naming: If your Linux hostname is not fully qualified, realm join might append the domain (e.g., hostname becomes hostname.example.com). If you get weird hostname issues, set a proper FQDN with hostnamectl before joining.
Always check /var/log/secure or journalctl -xe for realmd or adcli messages when a join fails. They often contain the exact reason (e.g. DNS lookup failure, permission denied, etc.).
SSSD Fails to Start or Crashes: If SSSD isn’t running, no AD auth will work.
Check status: systemctl status sssd. If it’s not active, try starting it: systemctl start sssd. If it fails immediately, there’s likely a config issue.
The SSSD logs are in /var/log/sssd/ (e.g. sssd.log, or per-domain logs like sssd_example.com.log). Run journalctl -u sssd -b to see recent log entries from SSSD.
A very common mistake: Permissions on /etc/sssd/sssd.conf. If this file is world-readable or not owned by root, SSSD will refuse to start. Ensure ls -l /etc/sssd/sssd.conf shows -rw-------. root root. If not, set chmod 600 /etc/sssd/sssd.conf && chown root:root /etc/sssd/sssd.conf.
Run a syntax check: sssctl config-check – this will validate the config file for any syntax errors or unknown parameters.
If you made manual edits, look for typos (even a missing quote or semicolon can break it). The logs (journalctl -u sssd) will often point to the line number of the error.
After fixing, always restart SSSD and watch the logs for a clean start message (look for “Starting up” and “Backend is online” in SSSD domain logs).
If SSSD is running but AD logins still fail, increase debug level: add debug_level = 9 in the domain section of sssd.conf (temporarily) and restart SSSD to get verbose logging for deeper analysis.
Cannot Resolve AD Users (NSS Issue): If id <ADuser> returns “no such user”:
Ensure SSSD is online: sssctl domain-list will show domain status (should be “connected” or “online”). If it shows “offline”, check network connectivity or DNS.
Check nsswitch: Make sure passwd: and group: lines include sss. If not, add them (or re-run authselect select sssd).
Try getent passwd <ADuser> and see if anything is returned. If not, check SSSD logs for lookup errors.
Use sssctl user-checks <username>@<domain> (if SSSD >= 2.x) – this can reveal if SSSD finds the user and any access control result.
Make sure the domain in sssd.conf exactly matches what you’re using (e.g., if domain is lower-case example.com, using an upper-case in getent might not match unless case_sensitive is off – usually not an issue though).
If you recently changed something like disabling id_mapping or updated schema, the SSSD cache might have old entries. In such cases, you might remove cache files (rm -f /var/lib/sss/db/* to clear cache, then restart SSSD). Only do this with caution, as it forces SSSD to re-retrieve all info.
If getent now works but login doesn’t, ensure PAM is using SSSD (see next issue).
Authentication Failures (PAM/Access Issues): If users are found (e.g. id user works) but login fails with “Permission denied” or similar:
Check /var/log/secure or journalctl -t sshd for messages. PAM will often log why it failed. For instance, “pam_sss(sshd:auth): authentication failure” or “No such user” (which indicates NSS lookup failed in PAM context).
Ensure the sshd is actually using PAM (it should if UsePAM yes in sshd_config). Also ensure PasswordAuthentication is on if using password (or that the user has a key if PasswordAuth is off).
If you set up access control (e.g. allowed groups), verify the user is in the allowed list. SSSD with access_provider=ad will honor AD account policies and logon restrictions. For example, if the account is disabled in AD, SSSD will deny login. Or if an AD GPO is in place restricting that user from this host, it could deny (SSSD supports AD GPO-based access control when ad_gpo_access_control = enforcing).
- SSSD’s domain log (/var/log/sssd/sssd_example.com.log) will show if an account was denied by access control. Look for “Access denied for user …” messages.
- If using simple_allow_groups or similar in sssd.conf, confirm it’s correctly set and the user’s group matches (remember to use the AD group name, and if using short names vs FQDN depending on config).
Try a manual Kerberos authentication: kinit [email protected]. If this fails (wrong password or other error), the issue is with credentials (e.g. password expired, account locked). If kinit succeeds but SSH/PAM fails, then likely a PAM configuration issue.
If the user’s AD password is expired or requires reset, SSH/PAM with SSSD might reject the login (and sometimes gives a message “Password expired” in logs). The user should change their password (likely on a Windows machine or via kpasswd). SSSD does support password change in some cases, but it may not prompt nicely via SSH. Reset the password in AD or enable the user and try again.
Solution: Depending on findings – fix PAM config if it was incorrect (usually by using authselect to re-apply the sssd profile), adjust SSSD access rules if overly restrictive, unlock/enable the account in AD, or handle password expiry. You can temporarily set pam_sss.so in auth to sufficient (which it is by default in RHEL profiles) so that if SSSD auth succeeds it doesn’t fall through to other modules that might fail.
Home Directory Issues: If a user login fails at the session stage, consider whether home directory creation is working:
Check /var/log/secure for pam_oddjob_mkhomedir messages. If it says “mkhomedir: error …”, ensure oddjobd service is running and that the user’s home parent directory (e.g. /home) is writable. Oddjobd should create the directory with the correct SELinux context.
If no homedir was made and the user is logged in anyway, they might be in / as current directory. This is not ideal. Running authselect select sssd with-mkhomedir (and having oddjob installed and running) fixes this by adding the PAM module properly.
If the user’s default shell from AD is something nonexistent (say AD has an attribute for Unix shell that is not on RHEL), login could fail. By default, realmd sets shell to /bin/bash for AD users. Ensure default_shell = /bin/bash in sssd.conf or that the AD user’s unix attributes (if any) are correct.
Solution: Start oddjobd if not started, and ensure PAM session includes the mkhomedir module. You can test creation by deleting a home dir and logging in again to see if it gets created. If SELinux is enforcing, make sure /home has the correct label (home_root_t) – normally not a problem unless home directories are on a separate mount point needing context.
Offline Login Failures: By default, SSSD caches credentials so that if the AD server is unreachable, users can still authenticate (using the last known good password hash). If this isn’t working:
Check if offline caching is enabled: in sssd.conf, cache_credentials = True (should be by default).
How long are cached creds valid? The option offline_credentials_expiration (default is 0 = indefinite in SSSD). If it’s set to a low value (in days), the cache might expire older logins. Increase it or set to 0 for unlimited.
If the system was rebooted while offline and can’t contact AD, SSSD should still allow cached logins. If not, perhaps the cache was cleared or SSSD thinks the domain is offline. You can explicitly put SSSD in offline mode with sssctl offline example.com (and sssctl online example.com to revert) to test offline login.
Also ensure the user logged in successfully at least once before (only then a cache is present).
Solution: Enable caching (cache_credentials) and do not set an expiration, or set it to a reasonable number of days. Always test by disconnecting from network and trying a cached login. If it fails, gather logs with SSSD debug on – it might be looking for AD and not properly detecting offline. In a pinch, having at least one local emergency user with sudo can save you if domain logins fail.
Slow Logins / Performance: If logins are slow (several seconds or more):
Possible DNS or network latency: ensure the RHEL host can quickly reach a local domain controller. If the AD site is far or if DNS is returning a DC in another site, you can configure ad_server or ad_site in sssd.conf to prefer a specific DC or site.
SSSD might be spending time enumerating groups, especially if a user is member of many groups. The setting ldap_use_tokengroups = True (default True for AD) can speed up group lookups by using AD tokenGroups attribute. Ensure it’s on.
If the domain has many trusts or subdomains, SSSD might be chasing referrals. If you are only concerned with one domain, you might set enumerate = False (should be false by default, which is good) and possibly ad_enable_gc = True to use the Global Catalog for faster queries (especially if ldap_id_mapping = False and pulling POSIX attrs, using GC avoids hitting multiple DCs).
Check if SSSD logs show any timeouts or repeated reconnects.
On the client side, also ensure there are no delays in sshd (UseDNS in sshd_config is often set to “no” by default to avoid DNS reverse lookup delay – verify that).
Solution: Tune SSSD if necessary – e.g., disable unused features, use the Global Catalog for queries, restrict the search base (if using ldap_access_filter). Most single-domain setups don’t need much tuning beyond defaults.
Kerberos Ticket Issues: If your goal is to have passwordless SSO (users get TGT on login or use GSSAPI auth):
Ensure the user can manually get a TGT: kinit [email protected] and then klist to see the ticket. If kinit fails, resolve that first (might be DNS, time, or user’s password).
If kinit works but SSH GSSAPI login doesn’t, make sure the SSH client has GSSAPI enabled (ssh -K user@host to forward credentials, or in /etc/ssh/ssh_config set GSSAPIAuthentication yes). The server also needs GSSAPIAuthentication yes (which we set).
If you want the system to automatically obtain a TGT upon login (so that the user can then do Kerberized LDAP or other operations), you might consider enabling pam_krb5 alongside SSSD. SSSD itself doesn’t automatically do a kinit for the user on login (it just authenticates). On RHEL, there is a feature called oddjob for Kerberos cred caching, or you could configure PAM to call pam_krb5 as optional to get a ticket. This is a bit beyond basic setup, but just note that authenticating via SSSD doesn’t automatically put a Kerberos TGT in the user’s ticket cache unless you do extra config.
If machine credentials (host keytab) seem to not work (e.g., kinit -k host/$(hostname) fails), the machine’s password might be out of sync. In logs you might see “Preauthentication failed” for the host principal. In AD Users & Computers, you can reset the computer account password, then rejoin or use adcli update. Usually, rejoining with realm join --client-software=sssd --membership-software=adcli --automatic-id-mapping=yes example.com (with --user as needed) can refresh the trust.
Solution: For user Kerberos issues, double-check realm and service principal configs. For machine trust issues, rejoin the domain. Keep the machine’s clock synced and allow SSSD to rotate the machine password (it does so every 30 days by default – controlled by ad_maximum_machine_account_password_age). If your org disabled machine password change on AD side, set ad_disable_enrollment = True or ensure no conflict.

In all cases, logs are your friend. Check /var/log/secure (for PAM/SSH messages) and SSSD logs under /var/log/sssd/. You can increase SSSD log level by adding debug_level = 8 or 9 in the [domain] section (and maybe in [sssd] section) and restarting SSSD – then re-run the failing scenario and inspect the logs. SSSD’s troubleshooting guide recommends verifying basic connectivity: does DNS resolve, can you reach the LDAP port, is the LDAP certificate trusted (if using LDAPS), etc.. Tools like ldapsearch -Y GSSAPI -h <dc_hostname> can test an LDAP bind via Kerberos (using the host keytab or user’s ticket). The sssctl utility can show cached entries (sssctl user-show username@domain) and domain status (sssctl domain-status example.com) to give clues.

6. Best Practices for Reliable and Secure Integration

Finally, here are some best practices to maintain a robust and secure integration between RHEL and Active Directory:

Maintain Time Synchronization: Use NTP or Chrony to keep the RHEL server’s clock in sync with AD’s time source. Kerberos (and thus AD logins) will fail if clocks drift too much. This is critical for reliability.
DNS and Network Configuration: Always ensure the RHEL server uses an AD DNS server. Avoid using public DNS for name resolution of the AD domain. If the server’s IP or hostname changes, update DNS and consider re-joining if necessary so the AD DNS has the correct records (SSSD can update DNS records dynamically if allowed, using GSS-TSIG).
Use Strong Security (LDAPS/GSSAPI): By default, SSSD will communicate with AD securely. It uses Kerberos for auth and by default signs LDAP connections. If you require LDAPS (LDAP over SSL) for compliance, ensure the AD’s CA certificate is imported into RHEL’s trust store (so SSSD can trust the TLS certificate). Set ldap_id_use_start_tls = true in sssd.conf if you want STARTTLS. But note, SSSD’s AD provider using Kerberos/GSSAPI means LDAP traffic is already authenticated and encrypted at the SASL level, which is usually sufficient. Still, verify that no plain-text communication is happening (sssd logs will indicate if STARTTLS is used, etc.).
Limit Access to Required Users/Groups: Don’t allow all domain users to log in unless necessary. Use SSSD’s access control or realm permit/deny to restrict login to specific AD groups (e.g., an “Linux SSH Users” group) or specific users. This improves security by ensuring unauthorized domain accounts can’t access the server. For example, set in sssd.conf:

  access_provider = simple
  simple_allow_groups = LinuxAdmins, LinuxUsers

or with access_provider=ad, use an AD group or OU filter (ad_access_filter). Test after implementing, as misconfiguration can lock everyone out (keep a local root shell open for safety when changing access settings).

Keep SSSD and Related Packages Updated: SSSD is actively maintained; updates may fix compatibility issues with AD or improve performance. Use the latest patches provided by Red Hat for RHEL 9 to ensure you have fixes for any known bugs (especially if your AD is new or has complex setups like multiple domains or new AD features).
Monitor Logs and Set Up Alerts: Regularly check logs for authentication failures or errors. Repeated “SSSD is offline” messages or pam_sss errors should be investigated immediately (could indicate connectivity issues or an expired machine account). Consider using monitoring tools to alert on SSSD service being down or high failure rates in auth logs, as these could indicate a problem before users start complaining.
Use authselect for PAM Changes: If you need to customize PAM (e.g., to add MFA modules, or enable pam_tally2/faillock for locking out after failed attempts), use authselect to generate a custom profile layered on the sssd profile. Directly editing the system-auth/password-auth files is prone to error and could be overwritten by updates or authselect calls. Authselect lets you add features like “with-faillock” (for account lockout) or “with-smartcard” easily.
Local Administrator Account: Always keep at least one local user (e.g. a local “admin” user in /etc/passwd with wheel sudo rights) for emergency access. In case SSSD or the network fails, you want a way to log in. Domain integration can break, and without a local account you could be locked out.
Test Offline and Cache Behavior: Periodically test that users who have logged in before can log in with no network. This ensures your offline cache is working. You don’t want to find out during an outage that no one can log in. By default, SSSD’s cache allows indefinite offline logins if cache_credentials is true. You can adjust offline_credentials_expiration (in days) if you want caches to expire – some security policies prefer cached creds to expire after X days of not contacting AD. Find a balance between security and availability.
Machine Account Maintenance: SSSD will rotate the machine account password roughly every 30 days (this is an AD requirement by default). It does this in the background. If the machine is off or cannot reach AD for an extended time beyond the password expiration, the trust may break. If you plan to take a system off-network for a long time, consider temporarily disabling machine password changes in AD or rejoin when it comes back. There’s an SSSD setting ad_maximum_machine_account_password_age if you need to tweak the rotation schedule. Do not manually mess with the machine password or keytab unless necessary; use proper tools (adcli, etc.) if you need to reinitialize it.
Backup and Document Configuration: Keep a record of any manual config changes (like a backup of sssd.conf, krb5.conf). If someone else needs to rejoin or rebuild the server, it helps to know what was done. Also consider using automation (like Ansible or Puppet) to apply your domain join and config steps for consistency across multiple servers.
Leverage Advanced Features Cautiously: RHEL-AD integration via SSSD has many features (SSSD can fetch sudo rules from AD, apply SELinux user maps, honor AD group policies for access, retrieve SSH keys as we showed, etc.). These can simplify management, but introduce complexity. Enable one feature at a time and test its impact. For example, if you want centralized sudo, you’d populate sudo rules in AD and set sudo_provider = ad in sssd.conf. Or for SSH keys in AD, as discussed, ensure proper schema or attribute usage. Each such feature should be tested in a staging environment if possible.
Security Hardening: Consider disabling password authentication over SSH if you can rely on keys or GSSAPI, especially for highly privileged accounts – this reduces exposure of passwords. When using AD, ensure your domain users have strong passwords and follow domain security policies (this is more on the AD side). On RHEL, you might still enable MFA (e.g. OTP or Smartcard) in addition to AD auth – SSSD supports pam_sss for 2FA with FreeIPA, but for AD you might integrate other PAM modules (like Google Authenticator or RADIUS) if required by policy.

By following the above practices and understanding the components, you will have a robust setup where RHEL 9 and Active Directory work together for seamless user authentication. The key is to verify each piece (DNS, Kerberos, SSSD, PAM) and use the tools available (logs, realm commands, sssctl, etc.) to diagnose issues. With proper configuration, domain users can log into Linux systems using their AD accounts, and administrators can centrally manage credentials and policies in AD while maintaining Linux-specific settings via SSSD.