SSSD architecture - the system security services daemon · Linux

SSSD (System Security Services Daemon) is the modern way to integrate Linux with LDAP, Active Directory, and FreeIPA. It provides NSS for user/group lookups, PAM for authentication, and offline support via local caching.

What SSSD does

application (login, ssh, sudo, ...)
       |
       v
   NSS / PAM
       |
       v
   SSSD (sssd_nss, sssd_pam)
       |
       v
   LDAP / Kerberos / AD

SSSD:

Connects to LDAP, AD, or FreeIPA.
Caches identity information locally.
Provides offline auth (cached credentials work when the central server is unreachable).
Handles Kerberos ticket management.

Configuration

/etc/sssd/sssd.conf:

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

[domain/example.com]
id_provider = ad
access_provider = ad
ad_server = dc1.example.com, dc2.example.com
ad_domain = example.com
krb5_realm = EXAMPLE.COM
krb5_server = dc1.example.com, dc2.example.com

# Caching
cache_credentials = true
entry_cache_timeout = 600
offline_credentials_expiration = 30

The file must be mode 600 owned by root, or SSSD refuses to start.

For AD integration

# Install
sudo apt install sssd-ad sssd-tools realmd adcli krb5-user

# Discover
sudo realm discover example.com

# Join (one-time, requires AD admin credentials)
sudo realm join example.com --user=Administrator

realm join configures SSSD, Kerberos, and NSS/PAM automatically.

For OpenLDAP

sudo apt install sssd-ldap

# /etc/sssd/sssd.conf
[domain/ldap]
id_provider = ldap
auth_provider = krb5

# Encrypted transport. Either LDAPS on 636...
ldap_uri = ldaps://ldap.example.com:636
# ...or plain LDAP on 389 upgraded with StartTLS:
# ldap_uri = ldap://ldap.example.com
# ldap_id_use_start_tls = True

# Validate the server certificate. Without this, encryption
# without authentication is just a slower cleartext channel.
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

ldap_search_base = dc=example,dc=com
krb5_server = kdc.example.com
krb5_realm = EXAMPLE.COM

On Debian and Ubuntu the CA bundle is /etc/ssl/certs/ca-certificates.crt; the path above is the RHEL location.

ldap:// with no StartTLS sends your entire directory in the clear

ldap_id_use_start_tls defaults to false. A bare ldap:// URI with that default means no TLS happens at any point. Every lookup - usernames, UIDs, GIDs, group memberships, the full shape of the organisation - crosses the network in plaintext, readable by anything on the path.

It gets worse the moment a site simplifies auth_provider = krb5 to auth_provider = ldap, which is the usual move when Kerberos is unavailable. Now the user’s password is sent in a plaintext bind on every single login.

Encryption alone is not enough either. Without ldap_tls_reqcert = demand, SSSD accepts any certificate, so an attacker who can answer on port 389 or 636 serves a forged directory. Because SSSD’s answers feed NSS, that attacker chooses the UID and GID mappings the host believes - including mapping their own principal to uid 0 or into a privileged group that sudoers trusts. Transport security here is not privacy hygiene; it is what stops identity being injected into the host.

Verify from the command line before trusting the config. -ZZ makes ldapsearch fail rather than fall back if StartTLS is unavailable:

ldapsearch -ZZ -H ldap://ldap.example.com -x -b dc=example,dc=com -s base
ldapsearch -H ldaps://ldap.example.com:636 -x -b dc=example,dc=com -s base

Then confirm SSSD itself is using it: sudo sssctl domain-status ldap should report the domain online, and a packet capture on 389 should show a StartTLS exchange rather than readable DNs.

Diagnose

# SSSD status
sudo systemctl status sssd
sssctl domain-status example.com
sssctl user-show alice@EXAMPLE.COM

# Logs
sudo journalctl -u sssd -f

# Cache
sss_cache -E     # invalidate everything
sss_cache -u alice@EXAMPLE.COM    # specific user

# Test a lookup
getent passwd alice@EXAMPLE.COM

sssctl shows domain status, online/offline state, and cached entries.

Offline behaviour

When the central server is unreachable:

cache_credentials = true allows login with cached credentials (passwords, not Kerberos TGTs).
The host’s sssd switches to offline mode automatically.
After offline_credentials_expiration days, cached credentials expire and login fails.

Offline auth is critical for laptops and for hosts that may lose network connectivity.

Performance tuning

[domain/example.com]
# Cache longer to reduce LDAP load
entry_cache_timeout = 3600

# Cache user credentials longer for offline
cache_credentials = true
offline_credentials_expiration = 30

# Use a single server (less negotiation)
ad_server = dc1.example.com

# Reduce lookup timeouts
ldap_opt_timeout = 5

Common failure modes

SSSD refuses to start: sssd.conf permissions are not 600 or have wrong ownership.
Lookup fails: id_provider misconfigured, base DN wrong.
Auth fails but lookup succeeds: auth_provider and id_provider disagree.
Offline mode stuck: sss_cache -E or restart SSSD.
DNS issues: SSSD relies on DNS to find AD servers.
Plaintext LDAP: ldap:// with no StartTLS sends the whole directory - and, with auth_provider = ldap, user passwords - in the clear, and lets anyone answering on port 389 forge UID and GID mappings. Always set ldap_id_use_start_tls = True and ldap_tls_reqcert = demand, and verify with ldapsearch -ZZ.
TLS misconfigured: SSSD logs Could not start TLS or a certificate verification error and the domain never comes online. Check the CA path in ldap_tls_cacert and that the certificate’s subject matches the hostname in ldap_uri - an IP address in the URI will not match a name in the certificate.