Enterprise Linux Identity Integration: SSSD, Active Directory Realm Joins & FIDO2 Hardware SSH Keys

Managing local Linux user accounts across hundreds of enterprise RHEL and Ubuntu instances leads to credential drift, audit non-compliance, and severe security exposure. By joining Linux hosts directly to an Active Directory domain via SSSD and realm, organizations establish centralized RBAC and Kerberos single sign-on. In this engineering field guide, we take Linux identity hardening to the absolute limit: binding Active Directory accounts to physical FIDO2 hardware security keys (YubiKey) for SSH access, eliminating static passwords, and automating sudoers delegation through AD security groups.

1. The Flaws of Legacy Linux Authentication (Winbind & Local Users)

Legacy methods of authenticating Linux to Windows Active Directory suffered from brittle RPC connectivity, lack of offline credential caching, and frequent domain trust drops. Modern System Security Services Daemon (SSSD) communicates natively over LDAP with Kerberos (GSSAPI), caching credentials locally so developers and sysadmins can authenticate even during transient WAN disconnections.

2. Joining RHEL 9 / Rocky Linux to Active Directory via Realm

Execute the following battle-tested configuration sequence to join the domain, configure PAM, and auto-create home directories:

# Step 1: Install required packages
dnf install -y realmd sssd adcli oddjob oddjob-mkhomedir samba-common-tools krb5-workstation libfido2 pam_u2f

# Step 2: Discover and verify Active Directory domain controllers
realm discover contoso.com

# Step 3: Join domain with designated OU container and automatic SSSD configuration
realm join --user=svc_linux_join --computer-ou="OU=Linux Servers,DC=contoso,DC=com" contoso.com

# Step 4: Configure PAM to auto-generate home directory on initial login
authselect select sssd with-mkhomedir --force
systemctl enable --now sssd oddjobd

3. Production SSSD Configuration (/etc/sssd/sssd.conf)

Harden SSSD for high performance, dynamic DNS updates, and clean user naming conventions (disabling the cumbersome user@contoso.com requirement):

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

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

# Restrict SSH access to authorized AD Security Group
ad_access_filter = (memberOf=CN=Linux-Admins,OU=Groups,DC=contoso,DC=com)

4. Enforcing FIDO2 Hardware Token SSH Authentication

Replace SSH passwords and standard RSA private keys with hardware-bound FIDO2 credentials (ed25519-sk). The cryptographic key resides entirely inside the YubiKey secure element and requires physical user presence (touch):

# Generate FIDO2 resident key bound to hardware token
ssh-keygen -t ed25519-sk -O resident -O application=ssh:contoso-corp -C "user@contoso.com-YubiKey"

# Harden OpenSSH Server Configuration (/etc/ssh/sshd_config.d/50-fido2.conf)
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
AuthenticationMethods publickey
PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com

5. Sudoers Delegation via Active Directory Groups

Grant elevated permissions without managing local files by creating a drop-in sudoers rule tied to your Active Directory security group:

echo "%Linux-Admins ALL=(ALL) ALL" > /etc/sudoers.d/ad_admins
chmod 0440 /etc/sudoers.d/ad_admins