LDAP statt Datei. Single-Sign-on mit SSSD, LDAP und Kerberos Tickets aus dem Cache

Transkript

1 Security SSSD Anja Kaiser, Fotolia Single-Sign-on mit SSSD, LDAP und Kerberos Tickets aus dem Cache Die Kombination aus LDAP und Kerberos erlaubt eine Benutzer-Authentifizierung auch über unsichere IP-Netzwerke. Dumm für mobile User ist, dass dafür eine Verbindung zum LDAP- und Kerberos-Server notwendig ist. Der System Security Services Daemon (SSSD) hilft ihnen aus der Patsche. Thorsten Scherf Meldet sich ein Benutzer an einem Linux-System an, ist der so genannte Name Service Switch (NSS) dafür zuständig, in der entsprechenden Datenbank nach dem Benutzerkonto zu suchen. Bei dieser Benutzerdatenbank handelt es sich klassischerweise um die Datei»/etc/ passwd«. Ist der Account vorhanden, kümmert sich das PAM-Subsystem um die Authentifizierung des Benutzers, etwa durch den Abgleich des eingegebenen Passworts mit dem Gegenstück in der Datei»/ etc/shadow«. Dieser Ablauf stößt natürlich schnell an Grenzen, besonders wenn sehr viele Benutzerkonten vorhanden sind. Diese müssten im vorliegenden Fall auf jeder einzelnen Maschine angelegt werden, da die Benutzer- und Passwortdatenbanken ja lediglich auf dem lokalen Dateisystem vorhanden sind. Das beschriebene Problem lässt sich jedoch leicht durch den Einsatz eines zentralen Verzeichnisdienstes wie NIS oder LDAP lösen. Hierbei liegen die notwendigen Benutzerdaten nicht lokal, sondern auf einem zentralen Server. Alle Systeme mit Zugang zu diesem zentralen Server können die Informationen bei der Anmeldung eines Benutzers abfragen. Da NIS nicht gerade dafür bekannt ist, eine sichere Umgebung bereitzustellen, kommt in diesem Artikel der Verzeichnisdienst LDAP zum Einsatz. Er stellt, anders als NIS, eine hierarchische Baumstruktur zum Speichern von Informationen in so genannten Attributen zur Verfügung. Kombiniert er sie miteinander, entstehen Objekte, etwa ein Benutzerobjekt. Ein Schema bestimmt dabei, welche Informationen (Attribute) gemeinsam verwendet werden dürfen. Für die RFCs 2307 beziehungsweise 2307bis, die die Attribute für Benutzerobjekte bestimmen, existiert beispielsweise auf dem 389-Directory-Server eine entsprechende Schemadatei namens»/etc/dirsrv/schema/10rfc2307.ldif«. Die Objektklasse, von der sich Benutzeraccounts ableiten, heißt»posixaccount«(listing 1). Alle notwendigen Benutzerattribute wie UID-Nummer, Login-Name und primäre Benutzergruppe sind hinter dem Wort»MUST«aufgeführt, optionale Attribute hinter»may«. Für Gruppen existiert eine ähnliche Objektklasse mit dem Namen»posixGroup«(Listing 2). Eine ausführliche Beschreibung der Funktionsweise des Directory-Servers würde zu weit führen. Unter [1] hat der Autor bereits einen umfangreichen Artikel zu genau diesem Thema veröffentlicht. Der folgende Artikel geht im Weiteren davon aus, dass ein LDAP-Server mit Benutzerkonten existiert. Natürlich spielt es dabei keine Rolle, welches Produkt zum Einsatz kommt, solange es die beiden oben erwähnten RFCs unterstützt. LDAP statt Datei Es ist zwar möglich, auch das Benutzerpasswort in einem solchen LDAP-Objekt für einen Benutzer zu speichern, schließlich sieht die Objektklasse»posixAccount«extra ein Attribut mit Namen»userPassword«für diesen Zweck vor. Aber das führt zu einem Sicherheitsproblem: Bei der Anmeldung eines Benutzers wandert sein Passwort nämlich im Klartext zum LDAP-Server. Kommt zwischen Client und Server keine TLS-Verschlüsselung zum Einsatz, ist jedermann in der Lage, 2 Ausgabe Admin

2 SSSD Security das Klartext-Passwort mit Hilfe eines Netzwerkmonitors mitzulesen. Anstatt die Kommunikation zwischen den beteiligten Systemen jedoch mittels TLS zu verschlüsseln, wäre es noch besser, das Benutzerpasswort ginge erst gar nicht über das Netzwerk und würde an einer anderen Stelle als dem LDAP-Server gespeichert. Schließlich stellen fehlerhafte Zugriffsregeln auf das Passwort-Attribut (ACLs) ebenfalls eine nennenswerte Gefahr dar. Eine sichere Alternativlösung stellt das Authentifizierungsprotokoll Kerberos bereit. Dreiköpfiger Hund Statt eines Benutzerpassworts überträgt Kerberos so genannte Tickets übers Netzwerk. Diese werden initial zwischen allen beteiligten Objekten ausgetauscht. Das bietet nicht nur den Vorteil, dass das Passwort selbst nicht mehr übers Netz geht, die Tickets sorgen gleichzeitig auch für die Single-Sign-on-Anmeldung (SSO) eines Benutzers. Im Klartext: Hat ein Benutzer sich erst einmal bei einem Kerberos-Server angemeldet, findet die Authentifizierung an einem anderen Kerberos-basierten Dienst, beispielsweise einem LDAP-Server, komplett transparent statt, der Benutzer muss also nicht erneut sein Passwort angeben. Das Protokoll setzt einen vorhandenen Kerberos-Server, auch Key Distribution Center (KDC) genannt, voraus. Dieser enthält eine Datenbank mit den Passwörtern aller beteiligten Objekte, also der Benutzer, Netzwerkdienste und Maschinen. Zusammengefasst bezeichnet man diese auch als Kerberos-Principals. Die Passwörter dieser Principals unterliegen einem Regelwerk, das festlegt, wie komplex sie sein müssen und welchen Gültigkeitszeitraum sie besitzen. Daneben enthält der Server keine Benutzeroder Systeminformationen, die sind an einer anderen Stelle zu speichern, etwa in einem Directory-Server. Der Ablauf der initialen Kerberos-Anmeldung ist recht einfach: Der Client baut eine initiale Verbindung zu einem Kerberos-Server (KDC) auf. Das geschieht entweder für den User transparent durch das Anmeldeprogramm»login«oder mit Hilfe von»kinit«. Der KDC besteht aus zwei Teilen. Einem Authentication Server (AS) und einem Ticket-Granting Server (TGS). Der AS empfängt die Anfrage des Clients und überprüft seinen Namensraum (Realm) auf den angefragten Usernamen (User Principal). Taucht der Principal in der Kerberos-Datenbank auf, erzeugt der AS einen zufälligen Session Key und ein so genanntes Ticket-Granting Ticket (TGT). Dieses TGT enthält verschiedene Informationen, unter anderem Client-Namen und -IP, eine Gültigkeitsdauer, einen Zeitstempel und den eben erzeugten Session Key. Kerberos kodiert dieses TGT mit einem Schlüssel, der nur dem Authentication Server und dem Ticket-Granting Server bekannt ist. Zusammen mit dem eben erzeugten Session Key geht dieses Ticket nun an den Client. Natürlich nicht im Klartext, sondern mit einem Schlüssel kodiert, der aus dem Passwort des Clients berechnet wurde. Wenn der Client die Antwort des Authentication Servers erhalten hat (kodiertes TGT und Session Key), wird der User dazu aufgefordert, sein Passwort einzugeben. Dieses Passwort wird zu einem Schlüssel konvertiert und dient zur Dekodierung des soeben empfangenen TGT. Der Client speichert das TGT in seinem Credential- Cache und löscht das eingegebene Passwort aus dem Speicher. Mit diesem TGT kann der User für die Gültigkeitsdauer des Tickets seine Identität nachweisen, ohne sich nochmals mit einem Passwort authentifizieren zu müssen. Auf der Workstation ist die Identität eines Benutzers mit Hilfe des TGT nun bereits verifiziert. Möchte der Benutzer jedoch auf einen weiteren Netzwerkdienst, beispielsweise auf den bereits erwähnten LDAP-Server zugreifen, muss er erneut ein Ticket vom KDC anfordern, diesmal vom Ticket-Granting Server. Dieses Service-Ticket (ST) ist für genau den einen Dienst zuständig, für den es angefordert wurde der Server muss dabei Zugriffe auf das GSS-API unterstützen. Die Anforderung an das Service-Ticket ist um einiges komplexer. Der Client sendet eine Anfrage an den TGS, sie besteht aus dem Namen des Dienstes, auf den der Client zugreifen will, einem so genannten Authenticator und dem gespeicherten TGT. Der Authenticator besteht aus dem Namen des Clients, seiner IP-Adresse und einem Zeitstempel (aktuelle Zeit des Clients). Das verschlüsselte TGT wird zusammen mit dem Authenticator an den Ticket-Granting Server geschickt. Der Authenticator wird ebenfalls kodiert, und zwar mit dem Session Key, der mit dem TGT empfangen wurde. Der Ticket- Granting Server dekodiert den Authenticator und das TGT, vergleicht deren Inhalt sowie die IP-Adresse des Clients, von dem die Anfrage kam, und die aktuelle Uhrzeit. Wenn alles zusammenpasst wird ein neuer Session Key generiert, den der Client und der angesprochene Server (etwa der LDAP-Server) künftig benutzen. Dieser neue Session Key ist Bestandteil des Service-Tickets, das der Ticket-Granting-Server ausstellt und verschlüsselt (mit dem Session Key des TGT) an den anfragenden Client sendet. Das Spiel beginnt nun wieder von vorne. Der Client empfängt das Service-Ticket und reicht es an den gewünschten Server (LDAP) weiter, um seine Identität nachzuweisen. Zusätzlich zum Service-Ticket wird ebenfalls wieder ein Authenticator generiert und an den Server geschickt. Stimmen wieder alle Informationen des ST und des Authenticator überein, gilt der Client als echt und somit als authentifiziert, ohne sich nochmals mit Usernamen und Passwort gegen den Server authentifizieren zu müssen. Im Takt Listing 1: Definition von»posixaccount«01 # grep i posixaccount /etc/dirsrv/schema/10rfc2307. ldif 02 objectclasses: ( NAME 'posixaccount' DESC 'Standard LDAP 03 objectclass' SUP top AUXILIARY MUST ( cn $ uid $ uidnumber $ gidnumber $ 04 homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) 05 X ORIGIN 'RFC 2307' ) Der Authenticator schützt davor, dass jemand den Netzwerk-Verkehr mitliest, Listing 2: Definition von»posixgroup«01 # grep i posixgroup /etc/dirsrv/schema/10rfc2307. ldif 02 objectclasses: ( NAME 'posixgroup' DESC 'Standard LDAP 03 objectclass' SUP top STRUCTURAL MUST ( cn $ gidnumber ) MAY ( userpassword 04 $ memberuid $ description ) X ORIGIN 'RFC 2307' ) Admin Ausgabe

3 Security SSSD der Admin den Kerberos-Realm ein. Mit dem Kommando»kdb5_util create«erzeugt er die Datenbank im Verzeichnis»/var/kerberos/krb5kdc«. Die Datenbank administriert er entweder lokal mit dem Tool»kadmin.local«oder remote mittels»kadmin«. Allerdings muss hierfür auf dem KDC der Kadmin-Dienst bereits aktiv sein und es muss ein gültiger Admin- Principal in der Datei»/var/kerberos/ krb5kdc/kadm5.acl«existieren. Wird eines der Verwaltungstools aufgerufen, kann»add_principal«einen neuen Principal der Datenbank hinzufügen, beispielsweise»add_principal pw password tscherf«. Für einen Service oder eine Workstation sieht es ähnlich aus:»add_principal randkey ldap/ldap.tuxgeek.de«oder»add_principal randkey host/grobi.tuxgeek.de«. Die Passwörter der Service-Principals müssen auf den entsprechenden Servern bekannt sein. Dies erreicht der Admin, indem er das Passwort für einen Service mit dem folgenden Befehl aus der Kerberos-Datenbank extrahiert:»ktadd k /etc/krb5.keytab host/tiffy.tuxgeek.de«. Die Datei»/etc/krb5.keytab«ist anschließend sicher auf den entsprechenden Service-Rechner zu kopieren, beispielsweise mit»scp«. In der Konfigurationsdatei jedes Kerberos-Dienstes ist dann diese Keytab-Datei mit dem Service-Passwort anzugeben. Meist suchen die Kerberos-Dienste aber bereits nach einer Datei mit dem Defaultein Service-Ticket abfängt und es möglicherweise zu einem späteren Zeitpunkt einem Server anbietet, um sich unberechtigten Zugang zu verschaffen. Ein solcher Angriff ist unter dem Namen Replay-Attacke bekannt. Damit die Authentifizierung des Clients funktioniert, muss natürlich die Uhrzeit auf allen beteiligten System korrekt eingestellt sein. Das lässt sich am einfachsten durch den Einsatz des Network-Time-Protocols (NTP) sicherstellen. Abbildung 1 zeigt noch einmal den Ablauf einer Kerberos-Sitzung im Überblick: 1. Client fordert beim AS ein TGT an 2. AS stellt dieses für den TGS aus und sendet es zum Client zurück 3. Client fordert ein ST an und sendet hier das TGT an den TGS 4. TGS sendet das ST zurück an den Client 5. Client sendet das ST an den Zielserver und authentifiziert diesen 6. Zielserver authentifiziert den Client Der Kerberos-Server führt die Datenbank, in der die Principals gespeichert sind. Dieser Server sollte besonders gesichert sein. Auf keinem Fall sollten zusätzliche Dienste auf diesem Rechner laufen. Es Abbildung 1: Ablauf einer Kerberos-Sitzung. gibt sowohl Principals für Benutzer wie auch für die Kerberos-basierten Dienste und Hosts. Ein Principal hat folgenden Aufbau:»primary/instance@REALM«, wobei»instance«optional ist und lediglich der Gruppierung dient. Beispielsweise könnte ein User-Principal folgendermaßen aussehen:»tscherf/ admin@tuxgeek.de«. Ein Beispiel für einen LDAP-Server:»ldap/tiffy.tuxgeek. de@tuxgeek.de«. Der Realm fasst alle Principals eines Bereichs zusammen und entspricht dem versal geschriebenen DNS-Domänennamen. Zusammen mit den Principals sind auch die Passwörter der User und der Dienste in der Datenbank gespeichert. Der Server ist relativ leicht zu konfigurieren. In der Datei»/etc/krb5.conf«trägt Listing 3: Ablauf einer Kerberos-Sitzung 01 # kinit tscherf 02 Password for tscherf@tuxgeek.de: # klist 5 05 Ticket cache: FILE:/tmp/krb5cc_ Default principal: tscherf@tuxgeek.de Valid starting Expires Service principal 09 08/06/10 15:41:50 08/07/10 15:41:50 krbtgt/tuxgeek.de@tuxgeek.de 10 renew until 08/06/10 15:41: # ldapsearch LLL h localhost b "dc=tuxgeek,dc=de" uid=tscherf 13 SASL/GSSAPI authentication started 14 SASL username: tscherf@tuxgeek.de 15 SASL SSF: SASL data security layer installed. 17 dn: uid=tscherf,ou=people,dc=tuxgeek, dc=de 18 givenname: Thorsten 19 sn: Scherf 20 loginshell: /bin/bash 21 uidnumber: gidnumber: objectclass: top 24 objectclass: person 25 objectclass: organizationalperson 26 objectclass: inetorgperson 27 objectclass: posixaccount 28 uid: tscherf 29 cn: Thorsten Scherf 30 homedirectory: /home/tscherf # klist 5 33 Ticket cache: FILE:/tmp/krb5cc_ Default principal: tscherf@tuxgeek.de Valid starting Expires Service principal 37 08/06/10 15:41:50 08/07/10 15:41:50 krbtgt/tuxgeek.de@tuxgeek.de 38 renew until 08/06/10 15:41: /06/10 15:43:20 08/07/10 15:41:50 ldap/tiffy.tuxgeek.de@tuxgeek.de 40 renew until 08/06/10 15:41:50 4 Ausgabe Admin

4 SSSD Security Abbildung 3: Die Clientsysteme stellen voneinander unabhängige Verbindungen zu den jeweiligen Serversystemen her. Abbildung 2: Mit Hilfe von»system config authentication«gelingt die Konfiguration des PAM- und NSS- Subsystems sehr schnell. namen»/etc/krb5.keytab«. Nachdem der KDC mit»service krb5kdc start«gestartet wurde, ist er betriebsbereit. Damit nun auch der LDAP-Server zur Authentifizierung der Benutzer auf die Kerberos-Datenbank zurückgreifen kann, muss der Administrator für ihn einen entsprechenden Principal auf dem Kerberos-Server erzeugen und auf den Server kopieren: kadmin.local: add_principal randkey U ldap/tiffy.tuxgeek.de kadmin.local: ktadd k /tmp/ds.keytab U ldap/tiffy.tuxgeek.de Nach dem Kopieren der Datei»/tmp/ ds.key«in das Verzeichnis»/etc/dirsrv«, muss der Admin dem Server selbst noch den Pfad zur Datei mitteilen: echo "KRB5_KTNAME=/etc/dirsrv/ds.keytab;U export KRB5_KTNAME" >> /etc/sysconfig/ dirsrv Ein abschließender Neustart des Servers ermöglicht nun die Anmeldung am Server mittels Kerberos (Listing 3). Hierzu ist zuerst ein entsprechendes TGT erforderlich. Beim aktuellen Stand der Konfiguration ist es noch manuell mittels»kinit«vom KDC anzufordern. Beim Zugriff auf einem Kerberos-Dienst fordert jeder einzelne Client im Hintergrund ein entsprechendes Service- Ticket über die Bibliothek»libnss_ldap.so«die Benutzerdaten von einem LDAP-Server ab. Meldet ein Benutzer sich am System an, erhält er direkt ein Kerberos-TGT zugeteilt das dann später für einen passwortlosen Zugriff auf andere Kerberos- Dienste zum Einsatz kommt. Solange der Rechner immer mit dem Netzwerk verbunden ist, funktioniert die beschriebene Prozedur fehlerfrei, denn jeder Client kann sich mit jedem Server verbinden (Abbildung 3). Problematisch wird es, wenn eines der beiden Serversysteme nicht erreichbar ist, im schlimmsten Fall sogar beide es nicht sind. Das kommt beispielsweise vor, wenn es sich bei der Workstation um ein Notebook handelt. Solange es mit dem Firmennetzwerk verbunden ist, kann sich ein Benutzer mit dem Firmenaccount anmelden. Ist der Benutzer jedoch auf Reisen, klappt die Anmeldung mit diesem Konto nicht mehr. Genau deswegen legen viele Benutzer für die mobile Nutzung ihres Geräts oftmals noch ein zweites, lokales Konto auf dem System an. Mit dem recht neuen System Security Services Daemon (SSSD) ist dies jedoch nicht mehr notwendig. Der SSSD ist Teil des Free-IPA-Projekts [2], existiert jedoch ebenfalls als eifür den angefragten Dienst an. Die Authentifizierung findet dann mit Hilfe dieses Service-Tickets statt. Je nach eingesetztem Directory-Server ist darauf zu achten, dass das Mapping zwischen dem Kerberos-Principal des Benutzers und dem entsprechenden Distinguished Name (DN) auf dem LDAP-Server korrekt funktioniert. Für den 389-Directory-Server existiert hierfür bereits ein passendes Plugin. PAM anpassen Damit nun auch die Anmeldung eines Benutzers an seiner Workstation mittels LDAP und Kerberos klappt, muss der Administrator die entsprechenden Konfigurationsdateien der beiden Subsysteme PAM und NSS anpassen. Die Konfigurationsdateien für PAM liegen üblicherweise im Verzeichnis»/etc/pam.d«, der NSS greift auf die Datei»/etc/nsswitch. conf«zurück. Zur Konfiguration dieser Dateien bietet sich das Tool»system config authentication«an (Abbildung 2). Es kümmert sich um die entsprechenden Konfigurationsänderungen. Das Passwort eines Benutzers überprüft von nun an die PAM-Bibliothek»pam_ krb5.so«. Der Name Service Switch fragt Abbildung 4: Ressourcen-schonend: Auch wenn mehrerer Benutzer angemeldet sind, genügt dank SSSD eine einzelne Verbindung zum LDAP-Server. Admin Ausgabe

5 Security SSSD Abbildung 5: Kommt der SSSD zum Einsatz, dann bietet dieser auch ein lokales Interface für die beiden Subsysteme PAM und NSS. tenbank ist in diesem Fall Free IPA auszuwählen, für die Authentifizierung wird ein Kerberos-Server vorrausgesetzt. In der PAM-Konfigurationsdatei (Listing 4) kommt statt»pam_krb5.so«nun»pam_ sssd.so«zum Einsatz. Hierüber erfolgt der Zugriff auf die PAM-Schnittstelle des SSSD. Damit der NSS sich entsprechend an die für ihn gedachte Schnittstelle andockt, erzeugt das Konfigurationstool für die Benutzerdatenbank auch gleich einen Eintrag»sssd«in der Datei»/etc/ nsswitch.conf«. In der Konfigurationsdatei»/etc/sssd/ sssd.conf«für den SSSD sind die einzelnen Abschnitte für den»nss«und»pam«(listing 5) zu erkennen. In der globalen Sektion»sssd«lassen sich Einstellungen für den Dienst selbst vornehmen. Die Angabe von»domains«steuert den Zugenständiges Tool. Beispielsweise hatte bereits die Fedora-Version 11 eine frühe Version mit an Bord, es kommt natürlich auch in aktuellen Versionen zum Einsatz. Benutzer anderer Distributionen installieren den Dienst einfach mit Hilfe des jeweiligen Paketmanagers oder laden das Tool von der Projektseite im Quellcode herunter [3]. Anmeldung ohne Netz Der SSSD stellt verschiedene Funktionen zur Verfügung, von denen drei besonders interessant sind. Zum einen löst das Tool das soeben angesprochene Problem der Offline-Authentifizierung eines Benutzers. Der SSSD hält empfangene Credentials eines zentralen Servers einfach in einem lokalen Cache vor. Meldet sich ein Benutzer also im Fimennetzwerk mit einem Firmenkonto an seinem Notebook an, dann gelangen die Credentials automatisch in den SSSD-Cache. Wie lange diese dort liegen bleiben und gültig sind, Abbildung 6: Auch zur SSSD-Konfiguration bietet sich das Tool»system config authentication«an. lässt sich in einer zentralen Konfigurationsdatei festlegen. Zudem unterstützt der SSSD die Abfrage mehrerer LDAP- oder auch NIS-Server. Damit lässt sich eine Vielzahl unterschiedlicher Benutzerdatenbanken abfragen. Auch aus Performance-Sicht bietet der Einsatz des neuen Daemon einen Vorteil. Statt für jede Abfrage an den LDAP- Server eine eigene Verbindung aufzubauen, ist nur ein Socket vom SSSD zum LDAP-Server nötig (Abbildung 4). Der Daemon bietet dabei eine eigene NSS- und PAM-Schnittstelle für anfragende Clientsysteme an (Abbildung 5). Im Backend sorgen so genannte Security- Provider für Zugriff auf den entsprechenden Identity- oder Authentication-Server. Sind diese nicht zu erreichen, wird der Cache nach bereits vorhandenen Credentials abgefragt. Die Konfiguration des Dienstes geschieht im einfachsten Fall wieder über das bereits erwähnte Tool»system config authentication«(abbildung 6). Für die Benutzerda- Listing 4: PAM-Konfiguration für SSSD 01 /etc/pam.d/system auth 02 auth required pam_env.so 03 auth sufficient pam_unix.so nullok try_first_pass 04 auth requisite pam_succeed_if.so uid >= 500 quiet 05 auth sufficient pam_sss.so use_first_pass 06 auth required pam_deny.so account required pam_unix.so broken_shadow 09 account sufficient pam_localuser.so 10 account sufficient pam_succeed_if.so uid < 500 quiet 11 account [default=bad success=ok user_unknown=ignore] pam_sss.so 12 account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 15 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok 16 password sufficient pam_sss.so use_authtok 17 password required pam_deny.so session optional pam_keyinit.so revoke 20 session required pam_limits.so 21 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid 22 session required pam_unix.so 23 session optional pam_sss.so 6 Ausgabe Admin

6 SSSD Security griff auf mehrere Benutzerdatenbanken. Diese sind dann im Folgenden durch entsprechende Konfigurationsoptionen näher zu spezifizieren. Die Hilfeseite»man 5 sssd.conf«bietet einen umfassenden Überblick aller zur Verfügung stehenden Konfigurationsoptionen an. Fazit Gerade für mobile Benutzer bietet der Einsatz des System Security Services Daemon (SSSD) große Vorteile. Anstatt mit unterschiedlichen Benutzerkonten arbeiten zu müssen, kommt nun nur Infos [1] Thorsten Scherf, LDAP-Directory-Server 389 : ADMIN-Magazin 01/ 2010, S 72 [2] Free-IPA-Projektseite: [ freeipa. org/ page/ Main_Page] [3] SSSD-Projektseite: [ fedorahosted. org/ sssd/] noch ein einzelnes Konto zum Einsatz. Im Offline-Modus kommen die Benutzer- Credentials dann einfach aus dem Cache. Auch im Datacenter selbst ist diese Funktion recht hilfreich, hilft sie doch dabei, einen temporären Ausfall eines LDAPoder Kerberos-Servers zu überbrücken. 01 [sssd] 02 config_file_version = 2 03 reconnection_retries = 3 04 sbus_timeout = services = nss, pam 06 domains = tuxgeek [nss] 09 filter_groups = root 10 filter_users = root 11 reconnection_retries = [pam] 14 reconnection_retries = [domain/tuxgeek] Im Vergleich zum bereits existierenden Name Service Cache Daemon (NSCD) bietet der SSSD eine wesentlich genauere Verwaltung der Cache-Einträge an. Auch verfallen diese (jedenfalls in der Default-Konfiguration) nicht, solange ein Benutzer offline ist. (ofr) n Listing 5: SSSD-Konfigurationsdatei 17 auth_provider = krb5 18 cache_credentials = True 19 ldap_id_use_start_tls = False 20 debug_level = 0 21 enumerate = True 22 krb5_kpasswd = tiffy.tuxgeek.de 23 ldap_schema = rfc2307bis 24 ldap_search_base = dc=tuxgeek,dc=de 25 krb5_realm = TUXGEEK.DE 26 chpass_provider = krb5 27 id_provider = ldap 28 ldap_uri = ldap:// / 29 krb5_kdcip = tiffy.tuxgeek.de 30 ldap_tls_cacertdir = /etc/openldap/cacerts 1/2 quer A 210 x 148 mm zzgl. Beschnitt??? Admin Ausgabe