Join a Linux Server to Active Directory with SSSD and Realmd: Step-by-Step

Provisioning separate local credentials across 25 or 50 servers eats up hours of operational time. Hire a new engineer, and you must generate accounts, assign UIDs, and distribute SSH public keys across every instance. When someone departs, auditing and scrubbing their credentials across separate boxes turns into an error-prone chore.

Binding your Linux fleet to Microsoft Active Directory (AD) eliminates that overhead. Engineers sign in with their existing domain credentials. Your security team manages accounts and access policies from a single directory console. Here is how to join Ubuntu, Debian, and RHEL-based systems to AD using realmd and sssd.

Table of Contents

Quick start (under 5 minutes)

Assume your Domain Controller (DC) runs at 192.168.10.15, managing the domain corp.example.com. Your Linux server needs connectivity to that DC over standard ports: DNS (53), Kerberos (88), and LDAP (389).

1. Install the required packages

On Ubuntu 22.04 or Debian 12, refresh your apt cache and install the enrollment utilities:

sudo apt update
sudo apt install -y realmd sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

On RHEL 9, Rocky Linux 9, or AlmaLinux 9, pull the equivalent packages with dnf:

sudo dnf install -y realmd sssd adcli samba-common-tools oddjob oddjob-mkhomedir krb5-workstation

2. Discover your domain

Verify that your Linux box resolves SRV records and reaches the domain controller:

realm discover corp.example.com

The output lists the discovered domain name, the recommended client software (sssd), and any missing dependencies. If discovery hangs or throws an NXDOMAIN error, check /etc/resolv.conf. Your host must point directly to your DC or an internal DNS resolver that handles AD records.

3. Join the domain

Authenticate with an account authorized to create computer objects in AD:

sudo realm join -U srv-join-admin corp.example.com

Enter the service account password when prompted. The command executes silently on success, generating the machine account in the default CN=Computers container.

4. Verify user lookup

Confirm that SSSD can pull identity data directly from AD:

id [email protected]

A successful join outputs POSIX attributes like uid=1844800500([email protected]) gid=1844800513(domain [email protected]) groups=.... SSSD synthesizes these numeric IDs automatically through algorithmic mapping.

Under the hood

A quick join gets users authenticated fast. Even so, understanding the core components makes production maintenance and incident triage much simpler.

How realmd, SSSD, and Kerberos fit together

Domain integration relies on three distinct layers:

realmd: A D-Bus coordination utility. It handles initial handshakes, contacts the DC via adcli, generates keytab entries, and writes basic SSSD configurations.
sssd: The background daemon handling NSS identity lookups and PAM authentication requests. It caches directory queries locally in LDB databases under /var/lib/sss/db/, so users can still log in during WAN outages.
Kerberos (krb5) & adcli: Kerberos handles ticket granting (TGT) and cryptographic validation. Meanwhile, adcli rotates the host machine account password every 30 days against AD.

Tuning /etc/sssd/sssd.conf

Initial provisioning writes /etc/sssd/sssd.conf with strict permissions (mode 0600, owned by root:root). Edit this file to customize logon behavior:

sudo nano /etc/sssd/sssd.conf

Below is a field-tested production configuration:

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

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

Setting use_fully_qualified_names = False simplifies daily work. Users log in as jdoe instead of [email protected], preserving compatibility with scripts and tooling that choke on the @ symbol. Setting fallback_homedir = /home/%u keeps home paths clean and familiar.

Restart the daemon after saving any configuration edits:

sudo systemctl restart sssd

Provisioning home directories on first login

AD objects lack native Linux home paths. Without an automated creation hook, users encounter the fallback warning: No home directory, logging in with HOME=/.

On Ubuntu and Debian, register the PAM home creation module:

sudo pam-auth-update --enable mkhomedir

On RHEL 9 and Rocky Linux, enable the feature using authselect and start the helper service:

sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd

Production access controls

Locking down SSH to authorized groups

Fresh domain joins often allow any authenticated AD user to open an interactive session. On production database or application nodes, you should restrict access to designated operational teams.

Use realm permit to control allowed logins:

# Block all domain accounts by default
sudo realm deny --all

# Permit a specific Active Directory security group
sudo realm permit -g "Linux Engineers"

# Whitelist a single emergency break-glass user
sudo realm permit srv-auditor

This command injects a filter into the ad_access_filter or simple_allow_groups parameter in /etc/sssd/sssd.conf. Non-whitelisted accounts will be rejected at the PAM stage with an access denied error.

Delegating sudo privileges to AD groups

Never paste domain accounts straight into /etc/sudoers. Instead, drop a dedicated file into /etc/sudoers.d/.

Open an isolated configuration file with syntax validation:

sudo visudo -f /etc/sudoers.d/ad-linux-engineers

Add this rule, escaping any spaces with a backslash:

%Linux\ Engineers ALL=(ALL:ALL) ALL

If you left use_fully_qualified_names = True in SSSD, provide the complete realm suffix:

%Linux\ [email protected] ALL=(ALL:ALL) ALL

Save and exit. visudo checks your entries before writing to disk, protecting you from syntax typos that break sudo across the system.

Troubleshooting and operational tips

Watch for Kerberos clock skew

Kerberos rejects tickets if client and DC clocks diverge by more than 300 seconds (5 minutes). That drift triggers immediate authentication failures with the error: Clock skew too great.

Sync your host with chrony against your internal PDC emulator or local NTP appliances. Check sync status with:

chronyc sources -v
timedatectl status

Flush stale group memberships

SSSD holds cached identity objects to reduce network calls to domain controllers. If you add an engineer to the Linux Engineers AD group in Active Directory Users and Computers (ADUC), the local server might not see it for several minutes. Flush the local cache to pull the update immediately:

sudo sss_cache -E
sudo systemctl restart sssd

Safeguard your sessions during rollout

Authentication changes alter the PAM pipeline. A misplaced directive can lock you out of SSH entirely.

Follow three defensive habits when touching production auth:

Keep an active root terminal open in a secondary terminal window until you confirm everything works.
Ensure a local administrative account in /etc/passwd has a known password and valid sudo access.
Tail /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (RHEL/Rocky) during test logins to spot failed PAM modules and Kerberos reject codes immediately.