Integrate RHEL 9 with Active Directory Using SSSD

This guide integrates one RHEL 9 host with an existing Active Directory domain using realmd and SSSD. It covers Linux host logins, not a Samba file server. You need root access, working RHEL repositories, an AD account delegated to join the pilot computer to its approved OU, and two test users: one allowed and one denied. Example domain and group names must be replaced throughout.

Preserve a local recovery account

Use a pilot with console access and a tested local administrator. Keep that session open while changing domain login policy. Save existing SSSD, Kerberos, PAM/authselect, and sudo configuration in a protected change record. Joining and leaving can change authentication configuration and the AD computer account.

01

Record the Pilot and Its Identity Policy

Preflight

Confirm the hostname and domain design with the AD owner. Decide whether this estate uses SSSD SID-based ID mapping or AD POSIX attributes before joining: changing this later can alter numeric ownership. This walkthrough uses default ID mapping and fully qualified names. Record any existing domain membership instead of replacing it.

hostnamectl
hostname -f
realm list
authselect current
sudo test ! -e /etc/sssd/sssd.conf || sudo stat /etc/sssd/sssd.conf

❯ What to Verify

A unique approved FQDN, the current authentication profile, and any existing realm are recorded.

Choose the integration architecture first

Direct SSSD integration supports one AD forest by default. Large estates, cross-forest access, Samba file sharing, NFS numeric ownership, and FIPS policies require additional design. Do not assume a successful pilot resolves those requirements.

02

Verify AD DNS and Time Before Joining

Dependencies

Configure the host to use your organization’s AD-capable DNS resolvers through its existing network management process. DNS must resolve domain-controller service records. Compare chrony synchronization with the AD time source; do not disable clock or Kerberos checks to work around a failure. Allow the documented AD traffic through the approved network path.

cat /etc/resolv.conf
chronyc tracking
chronyc sources -v
# Install DNS query tools if they are not present.
sudo dnf install bind-utils
dig +short SRV _ldap._tcp.dc._msdcs.ad.example.com
dig +short SRV _kerberos._tcp.ad.example.com

❯ What to Verify

SRV queries return reachable DC names and ports; the host is synchronized to an approved time source.

03

Discover the Domain and Join the Approved OU

Domain Join

Install the supported client components, then inspect discovery before joining. The join command prompts for the delegated account’s password; do not put a password in a shell command. Confirm the OU distinguished name with the AD owner. Have the owner verify the resulting computer object after the join.

sudo dnf install realmd sssd sssd-tools adcli oddjob oddjob-mkhomedir samba-common-tools krb5-workstation
realm discover --server-software=active-directory ad.example.com
sudo realm join --user=linux-join \
  --computer-ou='OU=Linux,OU=Servers,DC=ad,DC=example,DC=com' \
  ad.example.com
realm list
sudo authselect current
sudo authselect check
# If the current profile is sssd and with-mkhomedir is absent:
# sudo authselect enable-feature with-mkhomedir
# sudo systemctl enable --now oddjobd
sudo systemctl status sssd oddjobd --no-pager

❯ What to Verify

The discovered domain identifies AD and SSSD; realm list shows configured membership and the expected login policy.

04

Separate Identity Lookup from Authentication

Validation

Use a real pilot account and group. Identity lookup and a valid Kerberos ticket are separate checks; neither proves SSH access is permitted. Inspect SSSD configuration and domain status. Run the ticket test from a dedicated pilot session because destroying a ticket cache can affect other work in that session.

sudo sssctl config-check
sudo sssctl domain-status ad.example.com
getent passwd '[email protected]'
id '[email protected]'
getent group '[email protected]'
kinit [email protected]
klist
kdestroy

❯ What to Verify

The account resolves with the intended numeric identity and groups, and Kerberos issues a ticket for the pilot principal.

Do not clear SSSD databases as a routine fix

Cache deletion can remove offline credentials and identity data. Investigate DNS, clock, account state, keytab validity, and configuration first. Protect keytabs and SSSD configuration as sensitive files; never publish their contents in a screenshot or ticket.

05

Restrict Domain Logins Without Bypassing Policy

Access Control

For a pilot explicitly approved to use realmd’s group allow-list, permit only the designated login group. This can switch the SSSD access provider to simple access rules. If the organization requires AD GPO enforcement, stop and implement the approved AD-provider/GPO design instead; do not replace it with a local allow-list. Review the resulting policy and test both accounts.

sudo realm permit --groups '[email protected]'
realm list
sudo sssctl config-check
sudo sssctl user-checks -a acct -s sshd '[email protected]'
sudo sssctl user-checks -a acct -s sshd '[email protected]'

❯ What to Verify

The policy names only the approved group; the allowed account passes the SSH account check and the denied account fails.

Cached offline access needs its own policy

Previously authenticated users may be able to log in while AD is unavailable if credential caching is enabled. Group removals and account changes are not necessarily reflected immediately offline. Agree on offline access and expiration settings with the identity owner, then test them on an isolated pilot.

06

Grant a Reviewed Sudo Action to an AD Group

Least Privilege

Resolve the admin group before writing a rule. The example permits restarting only nginx; use it only where the service and all root-executed configuration are protected from the delegated users. Confirm nginx exists and the action is authorized. The sudo group should be a subset of users allowed to log in. Validate the file before attempting the action.

getent group '[email protected]'
sudo visudo -f /etc/sudoers.d/linux-ad-nginx
# In the editor, add this reviewed example rule:
# %[email protected] ALL=(root) /usr/bin/systemctl restart nginx.service
sudo chmod 0440 /etc/sudoers.d/linux-ad-nginx
sudo visudo -cf /etc/sudoers.d/linux-ad-nginx
sudo -l -U '[email protected]'

❯ What to Verify

The file parses successfully and the pilot account receives only the reviewed command.

07

Test Real SSH Sessions and Failure Evidence

End-to-End

From a second client, test the allowed and denied accounts with the authentication method required by your SSH policy. An SSSD join does not enable password-based SSH or replace MFA requirements. Verify home creation, groups, and sudo rights in the allowed session. Keep failures tied to their incident time and inspect logs before changing policy.

# Run on a separate client; -l avoids ambiguous user@domain@host syntax.
ssh -l '[email protected]' rhel-pilot.ad.example.com
# In the allowed session:
id
pwd
sudo -l
# On the pilot, inspect the incident window:
sudo journalctl -u sssd -u sshd --since '15 minutes ago' --no-pager
sudo ls -l /var/log/sssd/

❯ What to Verify

The approved account logs in under the required SSH policy; denied accounts remain denied and sudo scope matches the change record.

08

Document Recovery and Leave Only the Pilot

Rollback

If the pilot fails, use the local console account and restore the authentication and sudo settings captured before joining. Leaving a realm can affect domain authentication; schedule it only for this pilot. Coordinate whether the AD computer account is removed or retained, and verify the result with the AD owner. Do not restore PAM files blindly across changed package versions.

# Approved pilot rollback; inspect the local manual first.
man realm
sudo realm leave ad.example.com
realm list
authselect current
sudo visudo -c
# Verify a fresh local administrator login from another console/session.

❯ What to Verify

The pilot is no longer configured for the realm, local administrative access works, and AD object disposition is documented.

Upstream references

See Red Hat’s RHEL 9 SSSD integration guide and manage direct AD connections. Use installed realm(8), sssd-ad(5), sssd-simple(5), and sudoers(5) manuals for the deployed versions.