Was ist SSSD?

SSSD (System Security Services Daemon)

SSSD als zentraler Hub zwischen PAM/NSS auf der einen und LDAP/Kerberos/Cache auf der anderen Seite.

Was ist SSSD?

SSSD (System Security Services Daemon) ist der zentrale Vermittler zwischen den lokalen Client-Schnittstellen (NSS und PAM) und externen Identitäts- bzw. Authentifizierungsquellen wie LDAP, Active Directory, Kerberos oder FreeIPA. SSSD selbst spricht kein LDAP-Protokoll "an die Anwendung weiter" – es sitzt dazwischen, cached Ergebnisse lokal und entscheidet, ob eine Anfrage online gegen den Provider oder offline gegen den lokalen Cache beantwortet wird.

Kernidee

• Anwendungen (login, sshd, sudo, su, cron, Samba …) fragen nie direkt LDAP/AD an
• Sie fragen über nsswitch.conf (Namensauflösung) bzw. pam_sss.so (Authentifizierung) bei SSSD an
• SSSD verwaltet pro Domain einen eigenen Provider-Satz und einen eigenen Cache

Das unterscheidet SSSD grundlegend vom alten Ansatz mit nss_ldap/pam_ldap, wo jede Anwendung selbst eine LDAP-Verbindung aufbaute – ohne Cache, ohne Offline-Fähigkeit, mit einer separaten TCP-Verbindung pro Prozess.

Architektur

Die Grafik oben zeigt den Datenfluss abstrakt:

NSS (nsswitch.conf)

• Zuständig für passwd, group, sudoers etc.
• Eintrag sss in /etc/nsswitch.conf leitet Anfragen an SSSD weiter

PAM (/etc/pam.d/*)

• pam_sss.so übernimmt auth, account, password, session
• Wird i.d.R. über authselect (Rocky/RHEL) automatisch eingebunden, nicht händisch in jede PAM-Datei geschrieben

sssd (Daemon)

• Ein Monitor-Prozess plus mehrere Responder-Prozesse (sssd_nss, sssd_pam, sssd_sudo, sssd_ssh …)
• Konfiguration ausschließlich in /etc/sssd/sssd.conf, Rechte zwingend 0600 root:root – sonst startet der Dienst gar nicht erst

Lokaler Cache

• /var/lib/sss/db/*.ldb
• Erlaubt Login auch wenn LDAP/AD gerade nicht erreichbar ist (offline-fähig, TTL konfigurierbar)

Provider (pro Domain in sssd.conf)

• id_provider – woher kommen UID/GID/Home/Shell (z. B. ldap, ad, ipa)
• auth_provider – womit wird authentifiziert (z. B. ldap, krb5)
• access_provider – wer darf sich überhaupt anmelden (z. B. ldap_access_filter, simple)
• chpass_provider – wo Passwortänderungen landen

Minimalbeispiel: sssd.conf für LDAP-Client (it2XX)

Domain gegen den LDAP-Server ns.it2XX.int, mit TLS

[sssd]
config_file_version = 2
services = nss, pam
domains = it2XX.int

[domain/it2XX.int]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ns.it2XX.int
ldap_search_base = dc=it2XX,dc=int
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/it2XX-ca.pem

cache_credentials = True
enumerate = False

[nss]
filter_groups = root
filter_users = root

[pam]
offline_credentials_expiration = 7

Datei-Rechte nicht vergessen

chmod 600 /etc/sssd/sssd.conf
chown root:root /etc/sssd/sssd.conf
systemctl enable --now sssd

ℹ️ Hinweis: cache_credentials = True ist die Voraussetzung dafür, dass sich ein Nutzer auch offline (LDAP-Server nicht erreichbar) noch anmelden kann – SSSD prüft dann gegen den letzten gecachten Passwort-Hash.

Nsswitch- und authselect-Integration

Auf Rocky/RHEL wird SSSD normalerweise nicht händisch in nsswitch.conf und PAM eingetragen, sondern über authselect:

authselect select sssd with-mkhomedir
authselect current

Das setzt automatisch sss in /etc/nsswitch.conf für passwd, group, shadow, sudoers und aktiviert die passenden PAM-Stacks inklusive pam_mkhomedir.so für automatische Home-Verzeichnisse beim Erst-Login.

Caching und Offline-Verhalten

⚠️ Achtung: SSSD ist kein reiner Proxy – der Cache ist ein eigener Zustand mit eigenen TTLs. Änderungen im LDAP-Baum (z. B. neue Gruppenmitgliedschaft) werden nicht sofort sichtbar, sondern erst nach Ablauf des jeweiligen TTL oder nach manueller Invalidierung.

Cache manuell leeren/invalidieren

• sss_cache -E – kompletten Cache invalidieren (erzwingt Neuabgleich beim nächsten Zugriff)
• sss_cache -u it2XXuser – nur einen bestimmten Nutzer invalidieren
• rm -rf /var/lib/sss/db/* + Neustart – harter Reset, nur im Lab sinnvoll

Troubleshooting

Status und Domain-Übersicht

• sssctl domain-list
• sssctl domain-status it2XX.int

Live-Logs

• journalctl -u sssd -f
• Debug-Level pro Domain in sssd.conf erhöhen: debug_level = 9 unter [domain/it2XX.int], danach systemctl restart sssd

Verbindungstest ohne SSSD, direkt gegen LDAP

ldapsearch -x -H ldaps://ns.it2XX.int -b "dc=it2XX,dc=int" -D "cn=admin,dc=it2XX,dc=int" -W

⛔ Warnung: Wenn ldapsearch direkt funktioniert, aber SSSD trotzdem keine Nutzer auflöst, liegt der Fehler fast immer in ldap_search_base, in einem fehlenden/falschen CA-Zertifikat (ldap_tls_cacert) oder an den Dateirechten von sssd.conf. SELinux-Kontext des CA-Zertifikats (cert_t) im Enforcing-Modus ebenfalls prüfen.

Vergleich: SSSD vs. nss_ldap/pam_ldap

Merkmal	nss_ldap / pam_ldap (alt)	SSSD (aktuell)
Verbindung	jeder Prozess einzeln	zentraler Daemon, gebündelt
Cache	kein Cache	lokaler Cache mit TTL
Offline-Login	nicht möglich	möglich (cache_credentials)
Mehrere Domains	nicht vorgesehen	nativ unterstützt (AD-Trusts, mehrere LDAP-Domains)
Kerberos-Ticket-Handling	separat (pam_krb5)	integriert

Siehe auch

• OpenLDAP-Serverkonfiguration (ns.it2XX.int)
• authselect
• Kerberos-Realm-Integration im Cybersec-2-Kurs