Linux-Systeme an Identity Provider anbinden
Auf der Gästeliste
Veröffentlicht in Ausgabe 02/2026 - PRAXIS
Linux-Systeme an Identity Provider anbindeniele Unternehmen stehen vor der Aufgabe, moderne Identity-Managementstrukturen mit bestehenden Linux-Systemen zu verzahnen. Während Webanwendungen auf OIDC- und OAuth-basierte Identity Provider wie Keycloak, Entra ID oder Okta setzen, arbeiten Linux-Server weiterhin mit klassischen POSIX-Benutzerkonten. POSIX-Attribute wie UID oder GID fehlen jedoch meist in den Benutzer- und Gruppenobjekten, die primär für die Anmeldung an Webanwendungen dienen.
Um beide Welten zusammenzuführen, benötigen Sie ein zusätzliches Identity-Managementsystem, das zentrale Benutzerkonten verwaltet und gleichzeitig die erforderlichen POSIX-Informationen wie Benutzer-ID, Gruppen-ID oder Login-Shell bereitstellt. Ein bekanntes Beispiel ist FreeIPA [1], das wir bereits in den Open-Source-Tipps behandelt haben. Alternativ integrieren Sie ein Linux-System direkt in eine Microsoft-Active-Directory-Domäne und erzeugen die POSIX-Attribute lokal – etwa über SSSD oder Winbind.
Autorisierung mittels Identity Provider
Im Open-Source-Tipp der Novemberausgabe 2025 [2] haben wir gezeigt, wie Sie FreeIPA an einen externen Identity Provider (IdP) anbinden. In diesem Szenario autorisiert nicht FreeIPA selbst, sondern der zugehörige IdP. Nun rückt ein neues Feature des System Security Services Daemon (SSSD) in den Fokus. Damit binden Sie ein Linux-System direkt an einen externen Identity Provider an – ohne ein zusätzliches Identity-Managementsystem dazwischen. Das lohnt sich vor allem, wenn Sie nur wenige Systeme verwalten und die Benutzerautorisierung vollständig über einen externen IdP abwickeln möchten.
Linux-Systeme an Identity Provider anbindeniele Unternehmen stehen vor der Aufgabe, moderne Identity-Managementstrukturen mit bestehenden Linux-Systemen zu verzahnen. Während Webanwendungen auf OIDC- und OAuth-basierte Identity Provider wie Keycloak, Entra ID oder Okta setzen, arbeiten Linux-Server weiterhin mit klassischen POSIX-Benutzerkonten. POSIX-Attribute wie UID oder GID fehlen jedoch meist in den Benutzer- und Gruppenobjekten, die primär für die Anmeldung an Webanwendungen dienen.
Um beide Welten zusammenzuführen, benötigen Sie ein zusätzliches Identity-Managementsystem, das zentrale Benutzerkonten verwaltet und gleichzeitig die erforderlichen POSIX-Informationen wie Benutzer-ID, Gruppen-ID oder Login-Shell bereitstellt. Ein bekanntes Beispiel ist FreeIPA [1], das wir bereits in den Open-Source-Tipps behandelt haben. Alternativ integrieren Sie ein Linux-System direkt in eine Microsoft-Active-Directory-Domäne und erzeugen die POSIX-Attribute lokal – etwa über SSSD oder Winbind.
Autorisierung mittels Identity Provider
Im Open-Source-Tipp der Novemberausgabe 2025 [2] haben wir gezeigt, wie Sie FreeIPA an einen externen Identity Provider (IdP) anbinden. In diesem Szenario autorisiert nicht FreeIPA selbst, sondern der zugehörige IdP. Nun rückt ein neues Feature des System Security Services Daemon (SSSD) in den Fokus. Damit binden Sie ein Linux-System direkt an einen externen Identity Provider an – ohne ein zusätzliches Identity-Managementsystem dazwischen. Das lohnt sich vor allem, wenn Sie nur wenige Systeme verwalten und die Benutzerautorisierung vollständig über einen externen IdP abwickeln möchten.
Der SSSD fungiert in diesem Modell als Vermittler zwischen dem Identity Provider und dem Linux-System. Er greift über eine REST-Schnittstelle des IdP auf Benutzer- und Gruppeninformationen zu und stellt diese Daten anschließend über die Name-Service-Switch-Schnittstelle (NSS) für das System bereit. Dienste und Werkzeuge wie getent oder id, die sonst auf "/etc/passwd" oder LDAP zugreifen, können dadurch Benutzer- und Gruppenobjekte anzeigen, die ausschließlich im IdP existieren. Für die Authentifizierung nutzt der SSSD den OAuth-Standard "Device Authorization Grant", wie im RFC 8628 beschrieben [3]. Weitere Hintergründe finden Sie im Open-Source-Tipp 11/2025 [2].
Vielleicht fragen Sie sich an dieser Stelle, wie der SSSD die zuvor erwähnten POSIX-Attribute für Benutzer und Gruppen erzeugt. Die Antwort fällt vergleichsweise einfach aus: Der Dienst generiert die fehlenden POSIX-Werte automatisch – analog zur Integration in eine Active-Directory-Domäne. Zunächst betrifft das die Attribute UID und GID, die der SSSD über ein deterministisches Hash-Verfahren auf Basis der Token-URL des Identity Providers berechnet. Die Werte bleiben auf dem jeweiligen System stabil und konsistent.
Weitere POSIX-Informationen wie das Home-Verzeichnis oder die Login-Shell konfigurieren Sie ebenfalls über den SSSD. Eine vollständige Auflistung aller Parameter finden Sie in der Hilfeseite "sssd-idp". So entsteht aus einem reinen Webbenutzer ein vollwertiger Linux-Account mit sämtlichen erforderlichen POSIX-Attributen.
IdP einrichten
Im Idealfall legen Sie auf dem Identity Provider für jedes Linux-System einen eigenen OAuth-Client an. Dieser Schritt ähnelt der Registrierung eines Linux-Systems in einer Active-Directory- oder FreeIPA-Domäne. Während der Registrierung erzeugt der IdP eine individuelle Client-ID und ein Client-Secret. Beide Werte tragen Sie anschließend – zusammen mit weiteren Parametern – in die SSSD-Konfiguration ein. Ausführliche Anleitungen für Keycloak und Entra ID finden Sie unter [3] und [4].
Auch die Integration des Identity Providers auf dem Linux-System verläuft unkompliziert. Der Listing-Kasten zeigt eine Beispielkonfiguration für den SSSD, die sowohl Keycloak als auch Entra ID im Backend nutzt. Dort hinterlegen Sie die Client-ID und das Client-Secret; alle weiteren Angaben können Sie direkt übernehmen. Nach einem Neustart des SSSD greifen Sie auf Benutzer und Gruppen aus Keycloak oder Entra ID zu und autorisieren diese über den OAuth-Device- Authorization-Flow. Die Autorisierung übernimmt nun vollständig der externe Identity Provider.
Listing: Konfigurationsdatei sssd.conf
### SSSD-Konfigurationsdatei für die Integration eines Entra ID und Keycloaks Identity Providers.
[sssd]
services = nss, pam
domains = entra_id, keycloak
[nss]
default_shell = /bin/bash
fallback_homedir = /home/%f
[domain/entra_id]
id_provider = idp
idp_type = entra_id
idp_client_id = 12345678-abcd-0101-efef-ba9876543210
idp_client_secret = CLIENT-SECRET
idp_token_endpoint = https://login.microsoftonline.com/TENANT-ID/oauth2/v2.0/token
idp_userinfo_endpoint = https://graph. microsoft.com/v1.0/me
idp_device_auth_endpoint = https://login. microsoftonline.com/TENANT-ID/oauth2/
v2.0/devicecode
idp_id_scope = https://graph.microsoft.com/.default
idp_auth_scope = openid profile email
[domain/keycloak]
idp_type = keycloak:https://master.keycloak.test:8443/auth/admin/realms/master/
id_provider = idp
idp_client_id = myclient
idp_client_secret = CLIENT-SECRET
idp_token_endpoint = https://master.keycloak. test:8443/auth/realms/master/protocol/ openid-connect/token
idp_userinfo_endpoint = https://master. keycloak.test:8443/auth/realms/master/ protocol/openid-connect/userinfo
idp_device_auth_endpoint = https://master.keycloak.test:8443/auth/ realms/master/protocol/openid- connect/auth/device
idp_id_scope = profile
idp_auth_scope = openid profile email
Melden Sie sich per SSH am Linux-System an, zeigt das Terminal eine URL und einen Device-Code an. Öffnen Sie die URL im Browser, der IdP leitet Sie auf das gewohnte Loginportal weiter. Dort authentifizieren Sie sich mit Ihrem Benutzerkonto, geben den Device-Code ein und gestatten dem zuvor eingerichteten OAuth-Client den Zugriff auf Ihr Konto. Sobald dieser Vorgang abgeschlossen ist, sind Sie auf dem Linux-System angemeldet:
# getent user1@tscherf.onmicrosoft.com
user1@tscherf.onmicrosoft.com:*: 1433210431:1433210431::/home/user1@tscherf.onmicrosoft.com:/bin/bash
# ssh -1 user1@tscherf.onmicrosoft.com `hostname`
(user1@tscherf.onmicrosoft.com@ localhost) Authenticate with PIN ETKTSS217 at https://microsoft.com/devicelogin and press ENTER.
Gruppen, Caching und Performance
In der Praxis spielt die Gruppenauflösung eine wichtige Rolle, weil viele Dienste auf korrekte Gruppenmitgliedschaften angewiesen sind. Der SSSD ruft diese Informationen ebenfalls über die IdP-Schnittstelle ab und speichert sie lokal im Cache. Dadurch reduzieren Sie API-Aufrufe und stellen sicher, dass Anmeldungen auch dann funktionieren, wenn der Identity Provider vorübergehend nicht erreichbar ist. Sie definieren die Cachelaufzeit fein granular in der SSSD-Konfiguration, sodass Sie je nach Systemrolle zwischen kurzen Aktualisierungszyklen und langfristigen Zwischenspeicherungen wählen. Besonders in Umgebungen mit mehreren Linux-Servern wirkt sich dieses Verhalten positiv auf die Stabilität und Reaktionszeit der Authentifizierung aus.
Neben der Authentifizierung sollten Sie auch die Sicherheit des OAuth-Flows im Blick behalten. Der SSSD speichert Access-Tokens verschlüsselt im Systemcache und erneuert sie bei Bedarf automatisch, solange der IdP dies zulässt. Damit verhindern Sie, dass Benutzer während längerer SSH-Sitzungen die Autorisierung wiederholen müssen. Zugleich behalten Sie die Kontrolle über Berechtigungen, weil Sie Scope-Zuweisungen und Claims zentral im Identity Provider verwalten. Auf diese Weise legen Sie granular fest, welche Benutzer auf welche Systeme zugreifen dürfen.
Für den produktiven Betrieb empfiehlt sich ferner ein Blick auf Logging und Monitoring. Der SSSD protokolliert alle IdP-Anfragen detailliert im Debug-Modus, was die Fehlersuche bei fehlerhaften Tokens, ungültigen Client-IDs oder falschen Redirect-URIs erleichtert. Viele Administratoren automatisieren die Clientregistrierung und SSSD-Basiskonfiguration mit Ansible, um mehrere Systeme konsistent aufzusetzen. Achten Sie dabei auf einheitliche Zeitquellen per NTP, da OAuth-Flows empfindlich auf Zeitabweichungen reagieren. Auch Firewalls müssen ausgehende Verbindungen zum Identity Provider erlauben – ein häufiger Stolperstein, der Anmeldungen sonst blockiert.
Fazit
Die direkte Anbindung des SSSD an externe Identity Provider bietet sich besonders an, wenn Sie nur wenige Systeme verwalten und trotzdem vorhandene IdP-Benutzerkonten für die Anmeldung an Linux-Servern nutzen möchten. Ein zusätzliches Identity-Managementsystem allein für POSIX-Benutzerkonten benötigen Sie in solchen Szenarien nicht mehr.
(dr)
Links
[1] FreeIPA: https://it-a.eu/f7z64
[2] Open-Source-Tipp 11/2025: https://it-a.eu/q2pc2
[3] OAuth-Standard Device Authorization Grant - RFC 8628: https://it-a.eu/papc5
[4] Keycloak-OpenID-Clientsetup: https://it-a.eu/q2pc4
[5] Entra-ID-OpenID-Clientsetup: https://it-a.eu/q2pc5