© Marcel Mende, Fotolia.com

Ausgerechnet Microsoft zeigt der Unix-Welt seit Jahren, wie die Kombination aus dem Verzeichnisdienst Active Directory und Kerberos erfolgreich zentrale Benutzerverwaltung und Single-Sign-on implementiert. Mit nur wenig Handarbeit klinkt sich auch Linux ein.

Linux und Windows leben heute in vielen Unternehmen in friedlicher Koexistenz. Ein Muster heterogener Netze ist das Nebeneinander von Windows-dominierter Bürosoftware und traditionell Unix-lastigen Server- und Netzwerkdiensten. Der Verzeichnisdienst Active Directory, den Microsoft mit Windows 2000 Server einführte, verwaltet vielerorts zentral Benutzerinformationen.

Linux verwendet typischerweise das klassische System der »/etc/passwd« zur Benutzerverwaltung und zur Authentisierung. Es gibt zwar auch im Netzwerk verteilte Lösungen wie NIS oder LDAP, aber wieso sollte eine vorhandene Infrastruktur nicht genutzt werden? Um die Vorzüge der komfortablen Verwaltungswerkzeuge zu nutzen, sind mehrere Teilkomponenten zu konfigurieren.

Dieser Beitrag geht davon aus, dass ein Active-Directory-Server eine vollständige Domänenstruktur unter Windows verwaltet. Die betrachteten Clients hingegen laufen unter Linux. Sie nutzen vorhandene Schnittstellen wie PAM und NSS, um das Login (Authentisierung), Zutrittskontrolle (Autorisierung) und die damit in Verbindung stehende Infrastruktur (Abbilden von User-Informationen auf den Client) bereitzustellen. Als Sahnehäubchen gibt es noch Single-Sign-on-Funktionalität, als Kirsche obendrauf fungiert das automatische Anlegen von Benutzerverzeichnissen auf den Clients.

Erweitertes Potenzial

Um die Welten zusammenzubringen, greift das vorgestellte Beispiel auf den Winbind-Dienst des Samba-Projekts und Kerberos 5 zur Authentisierung zurück. Dabei ist Kerberos keine Erfindung der Redmonder Software-Ingenieure, denn Microsoft hat das Authentifizierungsverfahren von Unix übernommen. Ursprünglich am Massachusetts Institute of Technology (MIT) entwickelt, existiert das Verfahren dort schon seit den 1980er Jahren. Das freie Projekt Heimdal [1] setzt ebenso wie die Referenz des MIT [2] diesen Standard mit vollem Support für Kerberos 5 um. Eine weitere freie Implementierung ist Shishi [3].

Microsoft erkannte das große Potenzial der Technik schneller als die Unix-Welt. Allerdings hat das Unternehmen durch eigene Erweiterungen dafür gesorgt, dass Active-Directory-Server zwar auch Linux-Clients verwalten, Kerberos sich unter Linux hingegen an Windows-Clients die Zähne ausbeißt. Das ändert sich vielleicht, sobald Samba in kommenden Versionen als Domänencontroller für ein Active Directory dienen kann. Bis dahin bleibt in heterogenen Landschaften nur, die Lösung aus Redmond zur Authentifizierung mit Kerberos einzusetzen.

Bewachte Geheimnisse

Kerberos ist ein Ticket-basierter Authentifizierungsdienst in einem ungesicherten TCP/IP-Netzwerk, der auf dem Prinzip des geteilten Geheimnisses (Shared Secret) basiert. Das System nennt einen logisch abgeschlossenen Bereich, der eine Anzahl von Clients und Dienste umfasst, einen Realm.

Im hier vorgestellten Beispiel laufen die Clients und optional einige Dienste, etwa ein Dateiserver, unter Linux. Windows übernimmt den Verzeichnisdienst und die Authentifizierung durch das so genannte Key Distribution Center. Das KDC ist eine vertrauenswürdige dritte Partei und die zentrale Komponente von Kerberos (Abbildung 1). Es umfasst im Wesentlichen den Authentication Server (AS) und den Ticket Granting Server (TGS).

Abbildung 1: Innerhalb der Kerberos-Architektur werden alle beteiligten Komponenten in einem eigenen Bereich, dem Kerberos-Realm, zusammengefasst. Den Kern dieses Bereichs bildet das Key Distribution Center mit den Hauptakteuren AS, TGS und der Principal-Datenbank.

Zu Beginn einer Sitzung weist jedes Mitglied des Realm, ein so genannter Principal, seine Authentizität einmalig nach. Dazu fordert er beim AS ein initiales Ticket Granting Ticket (TGT) an. Mit diesem meldet er sich in der Folge am Ticket Granting Service an, um weitere Service Tickets zu bekommen. Tickets versteht Kerberos als elektronischen Legitimationsnachweis (Credential). Hat ein Principal ein Credential erhalten, erhält er ohne weitere Passworteingabe Zugang zu kerberisierten Anwendungen, die einen Identitätsnachweis benötigen (Single-Sign-on). Das Passwort hatte er nur eingetippt, um das TGT zu erhalten.

Abbildung 2: Authentifizierung mit Kerberos ist trickreich, aber flexibel: Ein Client sendet eine TGT-Anfrage zum KDC (1) und erhält ein zeitlich befristetes Ticket (2). Es berechtigt den Client zum weiteren Lösen (3) von Fahrscheinen (4)für kerberisierte Netzdienste (5), ohne das Passwort erneut einzugeben.

Fahrkartenkontrolle

Das Anmeldeprogramm fordert üblicherweise für den Benutzer ein TGT an (siehe Abbildung 2). Alternativ sendet das Programm »kinit« die Anfrage, nachdem er sich angemeldet hat. Der AS sucht im angeschlossenen Active Directory nach dem anfragenden Principal. Sobald der Authentication Server ihn gefunden hat, stellt er ein TGT aus. Er sendet es mit dem geheimen Schlüssel des Principals verschlüsselt zurück. Handelt es sich bei ihm um einen Benutzer, leitet das KDC den Schlüssel aus dem Benutzerpasswort ab und legt ihn verschlüsselt in seiner Principal-Datenbank ab. Das Anmeldeprogramm »login« oder das Tool »kinit« errechnen den geheimen Schlüssel aus dem Passwort, das der Benutzer Client-seitig eingibt, und entschlüsselt das TGT. Keine Instanz schickt jemals ein Kennwort im Klartext übers Netz.

Will ein Benutzer auf einen kerberisierten Dienst innerhalb des Netzes zugreifen, bittet er den TGS unter Vorlage des TGT um ein Service-Ticket für diesen Dienst. Der TGS stellt es im Hintergrund aus. Mit diesem Sercvice-Ticket meldet der Client den Benutzer automatisch am Dienst an, ein Passwort benötigt er nicht mehr.

Kerberos-Tickets haben eine begrenzte Lebensdauer. Daher ist es unerlässlich, dass die Systemzeit auf allen beteiligten Rechnern annähernd übereinstimmt. Weicht sie um mehr als fünf Minuten ab, verweigert der Kerberos-Server das Ausstellen des initialen Tickets mit der Meldung:

kinit(v5): Clock skew too great while getting initial credentials

Die maximal erlaubte Zeitabweichung lässt sich zwar in der Kerberos-Konfiguration des Clients erhöhen, sinnvollerweise stellt der Admin aber einen zentralen Zeitserver zum Abgleich bereit, um zu große Differenzen zu vermeiden.

Außerdem müssen Clients in der Lage sein, den FQDN-Namen des Kerberos-Servers aufzulösen. Das lässt sich durch einen Eintrag im zentralen Nameserver oder zur Not durch die Pflege der statischen »/etc/hosts« auf allen beteiligten Systemen bewerkstelligen.

Kerberos installieren

Wenn diese beiden Voraussetzungen erfüllt sind, installiert der Administrator Kerberos auf den Linux-Clients aus Paketen seiner Distribution. So benötigt er beispielsweise für die MIT-Variante bei Ubuntu aus dem Universe-Repository die Pakete »krb5-user« und »krb5-config« oder – falls er Fedora benutzt – »krb5-workstation« und »krb5-auth-dialog«. Alternativ dazu lassen sich auch die Quellen des MIT übersetzen.

Zur Konfiguration passt der Systemverwalter die Datei »/etc/kr5b.conf« an. Listing 1 zeigt eine minimale lauffähige Konfiguration des MIT-Pakets, die Clients benötigen, um eine Verbindung zum Kerberos-Server herzustellen. Die andere Kerberos-Implementationen verwenden jedoch weitgehend die gleiche Syntax.

01 [libdefaults]
02   default_realm = KDC.EXAMPLE.ORG
03   dns_lookup_realm = false
04   dns_lookup_kdc   = false
05 [realms]
06   KDC.EXAMPLE.ORG = {
07    kdc = w2k.kdc.example.org
08    default_domain = KDC.EXAMPLE.ORG
09   }
10 [domain_realm]
11    .example.org = KDC.EXAMPLE.ORG

Reiche abstecken

Die Zeile »default_realm« im Abschnitt »[libdefaults]« legt den Realm »KDC.EXAMPLE.ORG« als Standard für die Kerberos-Applikationen fest. Wenn mehrere Realms im Einsatz sind, ist es möglich, einen weiteren Ausdruck im Abschnitt »[realms]« hinzuzufügen. Der Abschnitt »[domain_realm]« teilt der Kerberos-Library die Verknüpfung von Domainnamen und Realms mit. Soll sie beispielsweise eine Verbindung zu einem entfernten Host aufbauen, muss die Kerberos-Library wissen, in welchem Realm sich dieser Host befindet. Einträge, die mit einem ».« beginnen, erfassen alle Hosts mit diesem Suffix und ordnen sie dem angegebenen Kerberos-Realm zu. Es ist für die reibungslose Kommunikation mit dem Kerberos-Server wichtig, den Namen des Realm versal zu schreiben, da sie sonst fehlschlägt.

Mit dieser Konfiguration lässt sich die Kommunikation mit dem Kerberos-Server testen. Das Kommando »kinit« fordert ein TGT an. Ohne Angabe von Parametern versucht das Programm ein TGT für den Principal zu erhalten, der den gleichen Namen hat wie der angemeldete Benutzer. Dazu gibt dieser einmalig sein Kerberos-Passwort ein.

Das Programm »kinit« verschickt nun eine unverschlüsselte TGT-Anfrage zum Authentifizierungs-Server, die unter anderem den Namen des Principals enthält. In der Antwort erhält der Client das TGT in verschlüsselter Form, das »kinit« wieder entschlüsselt und lokal ablegt.

Die Ausgabe des »klist«-Befehls aus Listing 2 enthält neben weiteren Informationen auch die Gültigkeitsdauer des soeben gelösten TGT. Zeigt das Kommando das Ticket an, ist die Konfiguration des Linux-Clients erfolgreich abgeschlossen. Das Test-TGT löscht der Anwender mit »kdestroy« wieder.

01 $ klist
02 Ticket cache: FILE:/tmp/krb5cc_1000
03 Default principal: user@KDC.EXAMPLE.ORG
04 
05 Valid starting     Expires        Service principal
06 03/17/08 11:10:27  03/17/08 21:10 krbtgt/KDC.EXAMPLE.ORG@KDC.EXAMPLE.ORG
07        renew until 03/18/08 11:10
08 
09 Kerberos 4 ticket cache: /tmp/tkt1000
10 klist: You have no tickets cached

Mitglied werden

Als nächsten Schritt nimmt der Admin den Linux-Client als Mitglied in die Active-Directory-Domäne auf. Dafür installiert er Samba in der Version 3.0.14a oder höher und das Programmpaket Winbind zur einheitlichen Benutzerverwaltung von Windows und Linux. Es nutzt eine Unix-Implementierung der RPC-Aufrufe von Microsoft, die Pluggable Authentication Modules (PAM) und den Name Service Switch (NSS), um es Benutzern aus Windows-Domänen auf Linux-Clients zu ermöglichen, sich wie ein lokaler Anwender anzumelden und zu arbeiten.

Samba konfiguriert der Administrator in der Datei »smb.conf«, die er üblicherweise nach der Installation der Programmpakete im Verzeichnis »/etc/samba/« vorfindet. Eine vollständige Beispielkonfiguration, die einen Active-Directory-Domänenmitglieder-Server mit der notwendigen Winbind-Konfiguration implementiert, zeigt Listing 3.

01 [global]
02 ; Samba als Domänenmitglied
03    workgroup = kdc
04    password server = srv.kdc.example.org
05    security = ads
06    realm = KDC.EXAMPLE.ORG
07    encrypt passwords = yes
08 
09 ; kein Computersuchdienst für das Windows-Netzwerk
10    local master = no
11    os level = 20
12    domain master = no
13    preferred master = no
14 
15 ; Winbind-Konfiguration
16    winbind separator = +
17    idmap gid = 10000-20000
18    idmap uid = 10000-20000
19    template shell = /bin/bash
20    template homedir = /home/%D/%U

Der Parameter »security = ads« in Zeile 5 bewirkt, dass Winbind das Passwort nicht in der lokalen Benutzerdatenbank sucht, sondern die Anfrage an einen Active-Directory-Domänencontroller weiterleitet. Dieser entscheidet dann, ob das Passwort korrekt ist oder nicht.

Wer einen AD-Domänencontroller von Windows 2003 einsetzt, muss zusätzlich in der Sektion »[global]« noch »client schannel = no« setzen. Bevor der Client der Domäne beitritt, teilt der Admin ihr in Zeile 6 mit, welchem Kerberos-Realm der Principal angehört.

Zentrale Userverwaltung

Die Mitgliedschaft in einer Domäne befreit Linux-Systeme nur davon, Passwörter zu verwalten, nicht aber, über die Anwender Buch zu führen. Die Domänenbenutzer sind dem System bis dahin noch unbekannt. Unixe benötigen den Daemon »winbindd«, um sie auch dort sichtbar werden zu lassen. Das Programm der Samba-Suite löst die Identität der Domänen-User mit Hilfe des Name Service Switch (NSS) auf und stellt sie für Linux bereit, als seien sie lokal.

Solange Winbind läuft, überträgt es temporär alle Benutzer und Gruppen aus dem Active Directory auf das Linux-System. Das verringert den administrativen Aufwand einer Benutzerverwaltung erheblich. Winbind konfiguriert der Admin zentral in der »[global]«-Sektion der »smb.conf« in den Zeilen 15 bis 20.

Die Anweisung »workgroup = kdc« in Zeile 3 fällt auf: Samba verwendet »workgroup« sowohl für die Definition einer Arbeitsgruppe als auch einer Domäne. Was Samba konfiguriert, entscheidet das Programm im weiteren Verlauf der Konfiguration. Hier ist es der Name der AD-Domäne in NT4-Schreibweise. Heißt die Windows-2003-Domäne »kdc.example.org«, erwartet Samba hier »kdc«.

Den Realm konfiguriert der Samba-Parameter in Zeile 6, er ist normalerweise der DNS-Name des Domänencontrollers, jedoch in Großbuchstaben, also hier »KDC.EXAMPLE.ORG«.

Schwere Trennung

Als Trennzeichen zwischen Domäne und Benutzername verwendet Windows den Backslash »«, der aber für die Shell eine Sonderbedeutung hat. Um Konflikte zu vermeiden, sollten Admins mit »winbind separator« diese Trennung nicht über ein Metazeichen der Shell umsetzen, sondern wie in Zeile 16 mit dem in der Praxis bewährten »+«-Zeichen.

Existiert nur eine Domäne, darf der Administrator auf die Trennung von Domäne und Benutzernamen verzichten. Winbind kennt in der globalen Sektion der Konfigurationsdatei den Parameter »winbind use default domain = yes«. Er weist Linux dazu an, die Benutzernamen aus dem Active Directory ohne Domänenanteil im Namen zu übernehmen. Macht der Admin das nicht, sind die von Winbind überlieferten Domänenbenutzer unter Linux nur mit vorangestellter Domänenbezeichnung einsetzbar (siehe Abbildung 3).

Abbildung 3: Weil der SSH-Server mehr als einen Realm kennt, muss der Benutzer »wane000« die Domäne »EDSB« mitführen. Das »+«-Zeichen trennt beide.

Ohne weitere Nachhilfe ist das Linux-System jedoch nicht in der Lage, die Namen der Domänen-Benutzer und -Gruppen in ihre numerische Form der User Idenfication Number (UID) und Group Identification Number (GID) umzusetzen. Das ist notwendig, weil Linux intern keine Namen, sondern nur UID und GID kennt. Das Kommando »ls« etwa liest aus dem Inode einer Datei deren Besitzer in numerischer Form aus und übersetzt ihn für die Ausgabe in einen Namen.

Dazu bedient es sich der Hilfe des Name System Switch. NSS ist ein universelles API unter Linux, um solche Abbildungen durchzuführen. Es kann sowohl in der »/etc/passwd« nachschlagen als auch mit einem eingebundenen Modul beim Active-Directory-Server rückfragen. So lassen sich alle Benutzer und Gruppen in einem ADS-Realm auflisten und benutzen, als wären sie lokale Accounts.

Dazu fügt der Systemverwalter den Datenbanken »passwd« und »group« den Namensdienst »winbind« in der zentralen Konfigurationsdatei »/etc/nsswitch.conf« hinzu:

passwd: files winbind
group:  files winbind

Der Namensdienst fragt so erst die lokalen Dateien wie »/etc/passwd« und wendet sich dann an »winbindd«. Wer zusätzlich noch NIS betreibt, darf statt »files« auch »compat« verwenden.

Für die erfolgreiche Zusammenarbeit zwischen Linux und dem Windows-basierten Active-Directory-Service fehlt letztlich noch, dass der Linux-Rechner der Domäne beitritt. Das ist notwendig, um auch die Benutzer und Gruppen der Domäne zu erhalten.

Der Parameter »security = ads« in Zeile 5 ist dafür verantwortlich, dass Samba Mitglied einer Domäne des Active Directory wird. Der Beitritt erfolgt mit dem Befehl »net ads«. Das Tool ist Teil von Samba (siehe Abbildung 4). Der Benutzer der Domäne, hier der »Administrator«, muss dazu berechtigt sein, den Linux-Rechner in die Domäne aufzunehmen. »net« erfragt das Passwort des angegebenen Benutzers und erstellt bei korrektem Passwort das Computerkonto auf dem Domänencontroller. Ist dies geglückt, agiert der Linux-Client als vollwertiges Mitglied in der Active-Directory-Umgebung.

Abbildung 4: Um den lokalen Rechner als Mitglied in die Standarddomäne aufzunehmen, benötigt der Anwender auf dem Domänencontroller (DC) die Rechte des Administrators. Weist er diese per Passwort vor, nimmt der DC den neuen Client auf.

Ob die Verbindung zum Domänencontroller einwandfrei funktioniert, lässt sich mit dem Diagnoseprogramm »wbinfo« prüfen. Es ist Teil des Winbind-Pakets. Mit dem Parameter »-u« listet das Kommando alle in der Domäne verfügbaren Domänenbenutzer auf:

KDC+wneu
KDC+mkreis [...]

Die verwendete Domäne heißt »KDC«. Der Domäne folgen der in der Einstellung »winbind separator« konfigurierte Trenner »+« sowie der Benutzername. Die angezeigten Namen aus dem Active Directory sind Linux damit bekannt und kommen für eine Anmeldung in Frage. Die im Active Directory definierten Gruppen listet »wbinfo -g« auf:

KDC+buchhaltung
KDC+asp [...]

Eine Zusammenfassung aller bekannten Benutzer und Gruppen, die entweder in der Domäne oder lokal verzeichnet sind, lässt sich mit Hilfe von »getent passwd« oder »getent group« anzeigen. Die Ausgabe ähnelt der Form in »/etc/passwd« und »/etc/group«.

Ein Test soll zeigen, ob Linux die Namen und Gruppen aus dem Active Directory kennt: Wenn der Linux-Systemverwalter Eigentümer und Gruppenzugehörigkeit einer auf dem Linux-Rechner abgespeicherten Datei in einen Domänenbenutzer und eine Gruppe aus dem Active Directory ändern kann, ist das Ziel erreicht. Abhängig vom Parameter »winbind use default domain« der Samba-Konfiguration, gibt Root den neuen Besitzer unter Umständen in der Form »Domäne+User« und die Gruppe mit »Domäne+Gruppe« an (Listing 4).

01 # ls -l foo.txt
02 -rw-r--r-- 1 root root May 02 15:53 foo.txt
03 # chown KDC+wneu foo.txt
04 # chgrp KDC+asp foo.txt
05 # ls -l foo.txt
06 -rw-r--r-- 1 KDC+wneu KDC+asp May 02 15:53 foo.txt

Als Kür integriert der Admin Kerberos, die Domänenbenutzer aus dem Active Directory und den Anmeldemechanismus von Linux: Solange noch jeder Dienst, der vom Benutzer erwartet, dass er sich authentisiert, seinen eigenen Weg hatte, um Benutzern Zugriff auf von ihm angebotene Dienste zu gewähren, haben diese die Authentifizierungs- und Autorisierungsmechanismen immer wieder neu implementiert. Die Pluggable Authentication Modules (PAM) schaffen eine einheitliche Schnittstelle [4].

Kerberos heiratet PAM

Unter PAM beschränkt sich der Wechsel der Authentisierungsmethode auf das Ändern und das Bereitstellen passender Module. Auf sie greifen alle Programme zu. PAM trennt also die Authentifizierung von den eigentlichen Diensten, ohne die Anwendung selbst zu ändern. Anwendungen wie Server für FTP und Telnet verbinden sich dazu mit einem Authentifizierungsdienst. Dazu rufen sie Funktionen aus der PAM-Bibliothek auf, die als Shared Libraries vorliegen. Abbildung 5 zeigt den Kommunikationsfluss zwischen Applikation und PAM.

Abbildung 5: Das konkrete Authentifizierungsverfahren bleibt den Anwendungen verborgen. Die PAM-Lib sucht die Prüfmethode selbst und meldet das Ergebnis.

Um die Authentifizierungsmethode des Benutzer-Logins mit Hilfe der Pluggable Authentication Modules auf Kerberos umzustellen, gibt es eine spezielle Modul-Bibliothek, die für die gängigen Distributionen als Paket verfügbar ist. Das darin enthaltene Modul heißt »pam_krb5.so« und liegt typischerweise im Verzeichnis »/lib/security« [5].

Individuelle Konfiguration

Das Modul zeichnet nicht nur für die Anmeldung per Kerberos verantwortlich, sondern bezieht nach erfolgreicher Authentifizierung für den Benutzer völlig transparent vom Authentication Server das Ticket Granting Ticket. Dazu sind aber einige Konfigurationen im Verzeichnis »/etc/pam.d/« nötig.

Für jede Anwendung, die eine Authentifizierung erfordert und dazu PAM verwendet, existiert eine individuelle Datei in »/etc/pam.d/«. Die einzelnen Distributionen organisieren die Konfigurationen jeweils etwas unterschiedlich und importieren teilweise gemeinsam genutze Dateien. Jede Zeile dieser Dateien enthält, abgetrennt durch Whitespaces, nacheinander den Typ, ein Kontroll-Flag, den Dateipfad zum verantwortlichen Modul sowie optionale Argumente (siehe Listing 5). Bringen Fedora & Co. von Haus aus das Tool »authconfig« und Open Suse Yast zur Manipulation der PAM-Konfiguration mit, so legen Anhänger von Debian und seiner Derivate noch selbst mit dem Editor Hand an die Dateien.

01 # /etc/pam.d/common-auth
02 auth     sufficient pam_krb5.so forwardable
03 auth     required   pam_unix.so nullok_secure use_first_pass
04 auth     required   pam_deny.so
05 
06 # /etc/pam.d/common-account
07 account  sufficient pam_krb5.so forwardable
08 account  required   pam_unix.so
09 
10 # /etc/pam.d/common-session
11 session  sufficient pam_krb5.so
12 session  required   pam_unix.so
13 
14 # /etc/pam.d/common-password
15 password sufficient pam_krb5.so nullok obscure md5
16 password required   pam_unix.so nullok obscure md5

Abschnittsweise

Systemverwalter finden in den Konfigurationsdateien Abschnitte für die vier PAM-Modultypen »auth«, »account«, »password« und »session«. Der Abschnitt »auth« definiert zwei alternative Authentisierungsverfahren, um zu entscheiden, ob der User derjenige ist, der er vorgibt zu sein (Zeilen 2 bis 3). PAM erfragt das Passwort des Benutzers einmalig, dann überprüft Kerberos die Angaben (Zeile 2). War dies erfolgreich, fordert »pam_krb5.so« ein TGT mit gesetztem Forwardable-Bit an, um das Ticket auf einem entfernten System weiterverwenden zu können.

Der Erfolg terminiert den Authentisierungsprozess, weitere Module werden nicht mehr abgearbeitet, weil »pam_krb5.so« als »sufficient«, also für die Anmeldung ausreichend, markiert ist.

Zweite Chance

Schlägt die Authentifizierung allerdings fehl, prüft PAM mit dem zweiten Modul »pam_unix.so«, ob der Benutzer lokal verzeichnet ist (Zeile 3). Erreicht PAM einmal den Authentisierungsserver nicht, kann sich Root immer noch einloggen. Das Modul-Argument »use_first_pass« bedeutet, dass die zweite Authentifizierungsmethode das bereits vom Benutzer übermittelte Passwort erneut verwendet, ohne dass er es noch einmal einzugeben hat. Dank »nullok_secure« muss ein Passwort in der lokalen Passwortdatei aber nicht zwingend gesetzt sein. Auch ein Login mit einem leeren Passwort ist möglich, dann allerdings nur an den Terminals, die in der »/etc/securetty« aufgelistet sind.

Nachdem PAM die Module vom Typ »auth« abgearbeitet hat, verarbeitet es die nächste »include«-Anweisung. Die Datei »common-account« enthält wieder die zwei Module »pam_krb5.so« sowie »pam_unix« und regelt den Zugang zum System. Der PAM-Dienst »account« ermittelt, ob das Passwort des Benutzers abgelaufen ist oder der Zugang zum System Beschränkungen nach beispielsweise Uhrzeit, Ressourcenbedarf oder Anwendungsort unterworfen ist.

Wenn der Benutzer existiert und sich anmelden darf, wird der nächste Modulstapel in Angriff genommen, den die Datei »common-password« beschreibt. Er ermöglicht es dem Benutzer, sein Passwort zu ändern. Im Gegensatz zur üblichen Prozedur unter Linux, dass ein Benutzer nur sein eigenes Passwort ändern darf, erlaubt es das Kerberos-Modul jedem Benutzer, auch das Passwort eines anderen zu ändern. Voraussetzung allerdings ist, dass bei der Änderung das aktuelle Passwort bekannt ist.

Sitzungsverwaltung

Zuletzt ruft PAM die in »common-session« konfigurierten Module auf. Der Typ »session« verantwortet alle zusätzlichen Jobs, die vor oder nach der Authentifizierung zu erledigen sind. Das kann etwa das Setzen von Variablen oder das Mounten eines Verzeichnisses sein. »pam_krb5« innerhalb dieses PAM-Dienstes führt eine entscheidende Aufgabe durch: Es löscht die Tickets des Benutzers, wenn dieser sich abmeldet.

Nach der Konfiguration greifen alle PAM-fähigen Programme via PAM auf das Active Directory zu. Der KDE-Displaymanager »kdm« zum Beispiel bietet sowohl alle lokalen als auch die Domänenbenutzer zur Anmeldung an und startet nach der Authentifizierung am Kerberos-Server die gewünschte Sitzung (Abbildung 6).

Abbildung 6: Der Displaymanager KDM zeigt neben den lokalen Benutzern auch die Benutzer aus dem Active Directory, die für eine Anmeldung in Frage kommen.

Benutzer aus dem Active Directory benötigen als letzten Schritt noch ihre Homeverzeichnisse. Wenn der Name System Switch keine Angaben über das Verzeichnis erhält oder es nicht existiert, schickt Linux einen Benutzer entweder in das Wurzelverzeichnis »/« oder lässt ihn trotz erfolgreicher Authentifizierung erst gar nicht ins System – etwa weil ein Desktop-Environment wie KDE bestimmte Dateien lesen und schreiben möchte, die in diesem Fall nicht vorhanden sind.

»/home«, sweet »/home«

Die Homeverzeichnisse konfiguriert der Admin in der »smb.conf« aus Listing 4 in der letzten Zeile mit dem Eintrag »template homedir = /home/%D/%U«. Samba ersetzt »%D« durch den kurzen Domänennamen und »%U« durch den Domänenbenutzer. Der Administrator legt die Verzeichnisse entweder für jeden einzelnen Benutzer an oder er automatisiert diesen Vorgang. Dazu macht er sich das Modul »pam_mkhomedir« zunutze, das dem PAM-Paket beiliegt und das er in der »session«-Sektion konfiguriert:

# /etc/pam.d/common-session
session required   pam_mkhomedir.so silent skel=/etc/skel/ umask=0022 
session sufficient pam_krb5.so
session required   pam_unix.so

So konfiguriert legt das Modul fehlende Homeverzeichnisse dynamisch an. Sein Argument »silent« unterdrückt informative Meldungen, die beim Kopiervorgang aus dem Skeleton-Verzeichnis entstehen. Mit dem letzten Argument setzt PAM die »umask« als Default für Datei- und Verzeichnisrechte auf »0022«. Die Einstellung lässt Programme in der Sitzung Verzeichnisse mit den Rechten »rwxr-xr-x« und Dateien mit »rw-r–r–« anlegen.

Eine Alternative zu lokalen Verzeichnissen auf den kerberisierten Clients bieten Homedirectories, die vom zentralen Fileserver gemountet werden. Das PAM-Modul »pam_mount.so« liefert dazu Hilfestellung. Will der Systemverwalter generische Kommandos nach dem Login ausführen, trägt er sie beispielsweise in die Startskripte in »/etc/profile« ein.

Voll integriert

Mehrere Schritte sind nötig, um Benutzern aus dem Active Directory ein automatisches Login inklusive Homedirectory an jedem Linux-Client zu verschaffen, aber mit Kerberos, NSS, PAM und Samba gelingt dieses Integrationsprojekt mit den Nachbarn aus Redmond. (mg)