Centralized User Management with SSSD

SSSD (System Security Services Daemon) enables Linux servers to authenticate against LDAP directories and Active Directory using a unified PAM/NSS interface with offline caching. This guide covers installing and configuring SSSD for centralized user management, including access control, sudo rules, and Kerberos integration.

Prerequisites

  • Ubuntu 22.04/Debian 12 or CentOS/Rocky 9
  • Root or sudo access
  • A reachable LDAP server or Active Directory domain controller
  • DNS properly resolving domain names (critical for AD/Kerberos)
  • NTP synchronized (required for Kerberos)

Install SSSD

# Ubuntu/Debian
sudo apt update
sudo apt install -y sssd sssd-tools sssd-ldap sssd-krb5 \
  libpam-sss libnss-sss libsss-sudo sss-client

# CentOS/Rocky
sudo dnf install -y sssd sssd-ldap sssd-krb5 sssd-tools \
  oddjob oddjob-mkhomedir authselect
sudo systemctl enable --now oddjobd

Configure SSSD for LDAP

Create the main SSSD configuration file:

sudo tee /etc/sssd/sssd.conf << 'EOF'
[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = example.com

[domain/example.com]
id_provider = ldap
auth_provider = ldap
sudo_provider = ldap

ldap_uri = ldaps://ldap.example.com:636
ldap_search_base = dc=example,dc=com

# Bind credentials (use a read-only service account)
ldap_default_bind_dn = cn=sssd-reader,ou=ServiceAccounts,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YourServiceAccountPassword

# TLS settings
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

# User and group schema
ldap_user_object_class = posixAccount
ldap_group_object_class = posixGroup
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell

# Performance
ldap_referrals = false
ldap_id_use_start_tls = false

[nss]
homedir_substring = /home

[pam]
offline_credentials_expiration = 7
EOF

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl enable --now sssd

Configure SSSD for Active Directory

For Active Directory domains, use the ad provider with realmd:

# Install realmd for domain joining
# Ubuntu/Debian
sudo apt install -y realmd sssd adcli samba-common-bin

# CentOS/Rocky
sudo dnf install -y realmd sssd adcli samba-common-tools

# Discover the AD domain
realm discover AD.EXAMPLE.COM

# Join the domain (requires AD admin credentials)
sudo realm join --user=Administrator AD.EXAMPLE.COM

# Verify join status
realm list

The resulting /etc/sssd/sssd.conf will look like:

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

[domain/ad.example.com]
ad_domain = ad.example.com
krb5_realm = AD.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = true
id_provider = ad
fallback_homedir = /home/%u@%d
default_shell = /bin/bash
use_fully_qualified_names = false   # login as "user" not "user@domain"
ldap_id_mapping = true              # map AD SIDs to local UID/GID
access_provider = ad

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd

PAM and NSS Integration

Ensure PAM and NSS are configured to use SSSD:

# Ubuntu/Debian - enable automatic home directory creation
sudo pam-auth-update --enable mkhomedir

# CentOS/Rocky - use authselect
sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd

Verify NSS is using SSSD:

# /etc/nsswitch.conf should contain:
grep -E "^(passwd|group|shadow)" /etc/nsswitch.conf
# Expected output:
# passwd:   files sss
# group:    files sss
# shadow:   files sss

# Test user lookup
id [email protected]
getent passwd username

Offline Caching and Enumeration

SSSD caches credentials to allow logins when the LDAP server is unreachable:

# Add to [domain/example.com] in sssd.conf
cache_credentials = true
krb5_store_password_if_offline = true

# How long cached logins work without server contact (days)
offline_credentials_expiration = 7

# Enable user/group enumeration (expensive on large directories)
enumerate = false   # keep false for large directories

Manage the SSSD cache manually:

# Invalidate cached user data (forces fresh lookup)
sudo sss_cache -u username

# Invalidate all cached data
sudo sss_cache -E

# Clear the entire SSSD database (use sparingly)
sudo systemctl stop sssd
sudo rm -rf /var/lib/sss/db/*
sudo systemctl start sssd

Access Control

Restrict which users or groups can log in to the system:

# For AD domains with realmd
sudo realm permit --groups "Linux Admins" "Linux Users"
sudo realm deny --all   # deny everyone first, then add groups

# For LDAP provider - add to [domain] section in sssd.conf

# Simple access control by group membership
access_provider = simple
simple_allow_groups = sysadmins, developers

# Or by individual users
simple_allow_users = alice, bob

sudo systemctl restart sssd

# Test access with a specific user
sudo sss_ssh_authorizedkeys username

Sudo Rules via LDAP

Store sudo rules in LDAP for centralized management:

Add to LDAP (example LDIF):

dn: cn=wheel-sudo,ou=Sudoers,dc=example,dc=com
objectClass: sudoRole
cn: wheel-sudo
sudoUser: %sysadmins
sudoHost: ALL
sudoCommand: ALL
sudoOption: !authenticate

Configure SSSD to query sudo rules:

# In [sssd] section
services = nss, pam, sudo

# In [domain/example.com]
sudo_provider = ldap
ldap_sudo_search_base = ou=Sudoers,dc=example,dc=com

# In [sudo] section (add this section)
[sudo]
sudo_cache_timeout = 600

# In /etc/sudoers or /etc/sudoers.d/sssd, add:
echo "%sudoers ALL=(ALL) ALL" | sudo tee /etc/sudoers.d/sssd-sudoers

# Configure sudo to use SSSD
sudo tee /etc/sudoers.d/sssd << 'EOF'
#includedir /etc/sudoers.d
EOF

# Verify sudo rules are fetched
sudo sss_cache -G
sudo -l -U username

Troubleshooting

SSSD fails to start:

sudo journalctl -u sssd -n 50 --no-pager
# Enable debug logging in sssd.conf:
# [domain/example.com]
# debug_level = 9
sudo systemctl restart sssd
sudo tail -f /var/log/sssd/sssd_example.com.log

User not found after configuration:

# Check if SSSD can reach the LDAP server
ldapsearch -H ldaps://ldap.example.com:636 \
  -D "cn=sssd-reader,ou=ServiceAccounts,dc=example,dc=com" \
  -w password -b "dc=example,dc=com" "(uid=testuser)"

# Force a cache refresh
sudo sss_cache -u testuser
getent passwd testuser

Kerberos/AD authentication failures:

# Verify time sync (Kerberos requires < 5 minute skew)
timedatectl status

# Test Kerberos ticket acquisition
kinit [email protected]
klist

Home directory not created on login:

# Ubuntu/Debian
sudo pam-auth-update --enable mkhomedir

# CentOS/Rocky
sudo authselect select sssd with-mkhomedir --force
sudo systemctl restart oddjobd

Conclusion

SSSD provides a robust solution for centralized user authentication on Linux, supporting LDAP, Active Directory, and Kerberos with transparent offline caching. By combining SSSD with PAM/NSS integration, access control lists, and LDAP-stored sudo rules, you can manage hundreds of Linux servers from a single directory service. Keep debug logging enabled during initial setup and monitor /var/log/sssd/ for authentication issues.