Wer heterogenen IT-Massenbetrieb administriert, will auch bei der Benutzerverwaltung unnötige Doppelarbeit vermeiden: Liegen die Daten schon im Active Directory eines Windows-2003-Servers, dann soll sich Linux daraus bedienen. Mit einigen Kniffen gelingt das auch.

In einer idealen Welt gibt es nur offene Standards und Systeme, die sich strikt daran halten. In diesem Umfeld könnte jeder Client alle Serverdienste nutzen, unabhängig vom Betriebssystem. In der Realität beherrschen aber oft Windows-Server die IT-Infrastruktur. Wer dort Linux als Client einführt, wird zunächst mit doppelter Benutzerverwaltung arbeiten. Das bedeutet aber doppelten Administrationsaufwand und setzt Kenntnisse beider Server voraus.

Doch es geht einfacher. Selbst wer das proprietäre Windows nicht durch Linux und Samba ersetzen darf, kann beide Systemwelten integrieren. Zu den Linux-Zutaten gehört OpenLDAP[1] als Client, das seit August 2000 auch LDAP v3 beherrscht[2]. Diese Version nutzt Microsoft seit Windows 2000 in seinen Server-Editionen, sie bildet damit den Kern des Active Directory. Zudem löste ein leicht modifiziertes Kerberos v5[9] die bisherige Windows-NT-Authentifizierungsmethode NTLM ab. Auch für Linux gibt es Kerberos-Implementierungen.

Einen weiteren Baustein entwickelte Luke Howard. Der ehemalige Apple-Mitarbeiter gründete 1999 die Firma PADL[12] und zeichnet für RFC 2307[5] verantwortlich (aktuell: Draft »rfc2307bis«,[6]). Howards Vorstoß beschreibt den Einsatz von LDAP als Network Information Service. Während die herkömmliche, auch als Yellow Pages bekannte NIS-Variante auf Textdateien mit Benutzer-, Gruppen- und/oder Host-Informationen basiert, liegen bei RFC 2307 die Daten in einem LDAP-Server (Näheres dazu im Kasten "Schema im LDAP").

Baukastenprinzip

Allerdings muss Linux erst wissen, dass es die Userdaten aus einem LDAP-Verzeichnis beziehen soll. Dank Name Service Switch (NSS,[11]) mit seinen Modulen und Konfigurationsdateien ist es möglich, das komplette System darauf umzustellen. Wie die Elemente zusammenarbeiten, steht im Kasten "Das NSS-Prinzip".

Während NSS die Bibliotheken für NIS und für Files mitbringt und damit ein Eintrag in »/etc/nsswitch.conf« genügt, hat es der Admin bei LDAP als Datenquelle schwerer. Die passende Bibliothek »/lib/libnss_ldap.so.2« fehlt den meisten Standardinstallationen, sie ist ein Produkt der bereits genannten PADL- Software[12]. Nss_ldap leistet die Kernarbeit bei der Verbindung von Linux und Active Directory. Wer die Library selbst übersetzt, sollte folgende Configure-Optionen angeben:

--enable-rfc2307bis
--with-ldap-lib=openldap
--enable-schema-mapping
--enable-paged-results
--enable-configurable-krb5-ccname-gssapi

Gentoo-User modifizieren das Ebuild in »/usr/portage/net-libs/nss_ldap«. Wie RFC 2307[5] beschreibt, zapft Nss_ldap die Benutzerobjekte innerhalb des Active Directory an (siehe Abbildung 2). Benutzerobjekte sind über Attribute definiert, die zu Objektklassen gehören. Das LDAP-Schema bestimmt, welche Attribute und Klassen es gibt (siehe Kasten "Schema im LDAP").

Weil LDAP keine starren Strukturen vorgibt, muss Nss_ldap erst erfahren, wie die Linux-spezifischen Attribute im Active Directory heißen. Diese Information steht - zusammen mit grundlegenden Einstellungen für die Verbindung mit dem Active Directory - als Schema-Mapping in der Nss_ldap-Konfigurationsdatei (passend zum vorliegenden Beispiel in Listing 1). Zu finden ist sie unter »/etc/ldap.conf« (nicht zu verwechseln mit der OpenLDAP-Konfiguration in »/etc/openldap/ldap.conf«).

Das bei Nss_ldap mitgelieferte Konfigurationsfile ist sehr gut dokumentiert und mit vielen Vorlagen gefüllt. Um das passende Schema-Mapping für verschiedene Schema-Erweiterungen zu aktivieren, muss der Admin lediglich einige Kommentarzeichen entfernen (Listing 1 ab Zeile 14). Das Beispiel in diesem Artikel verwendet die Services for Unix 3.5, also gilt das Mapping für dieses Schema.

Das NSS-Prinzip

Der Name Service Switch erlaubt es, an zentraler Stelle zu konfigurieren, auf welchem Weg ein Linux-System die Namen von Benutzern oder Rechnern in ihre numerischen Varianten übersetzt (und umgekehrt zu Nummern passende Namen findet). Will etwa das Kommando »ls -la« ausführlich den Inhalt des aktuellen Verzeichnisses auflisten, muss es User-IDs auf Benutzernamen abbilden. Dazu ruft es die C-Funktion »getpwuid()« aus der Libc auf. Das Kommando »getent passwd« hingegen nutzt die Funktion »getpwnam()« und gibt eine Liste von Benutzern im Passwd-Format aus. Die Herkunft der Daten bestimmt der Admin mit Hilfe der NSS-Konfigurationsdatei »/etc/nsswitch.conf«: passwd: files ldap group: files ldap NSS generiert aus diesen Einträgen die Namen von Bibliotheken. Aus »files« wird »libnss_files.so.2«, zu finden ist sie in »/lib«. Diese Bibliothek reagiert auf »getpwnam()«, indem sie die Einträge in »/etc/passwd« in die Struktur »struct passwd« schreibt. Den Zeiger auf diese Struktur übergibt NSS an die Libc und diese weiter zur aufrufenden Applikation, hier »getent«. Diese gibt die Benutzerdaten auf Stdout aus. Abbildung 1 stellt den gesamten Ablauf vom Aufruf der Applikation bis zur Ausgabe der Ergebnisse grafisch dar: 1 Eine Applikation sendet eine Anfrage über den Aufruf einer Libc-Funktion. 2 Die Funktion sucht in »/etc/nsswitch.conf« nach verfügbaren Quellen. 3 Im Beispiel passen zwei Quellen. 4 Die Funktion spricht die Bibliotheken der Reihe nach an. 5 Das Ergebnis geht an die Libc. 6 Die Funktion gibt das Ergebnis als Zeiger zurück an die Applikation. Abbildung 1: Der Name Service Switch gestaltet das Hinzufügen eigener Quellen für Benutzerdaten recht einfach. Ein Eintrag in »/etc/nsswitch.conf« und eine dazu passende Bibliothek genügen.

Schema-Erweiterung

Windows 2003 kennt ohne Nachhilfe weder UID noch GID. Als Nachhilfelehrer dient eine Schema-Erweiterung: Sie kombiniert die Attribute »uidNumber« und »gidNumber« in der Objektklasse »posixAccount«. Schema-Erweiterungen sind allerdings ausschließlich dem Enterprise-Admin vorbehalten. Dahinter verbirgt sich etwa der »Administrator«-Account von Windows 2003.

Abbildung 2: Der Name Service Switch zapft das Active Directory mit Hilfe von Nss_ldap an. Aus ihm liest er die Werte von Attributen, die der Admin mit Schema-erweiternder Software nachträglich hinzugefügt hat. Die SASL-Schicht ergänzt LDAP-Anfragen um Kerberos-Schutz.

Als Schema-erweiternde Software hat sich das von PADL[12] entwickelte Plugin bewährt. Zusätzlich fügt es dem Eigenschaftendialog eines Benutzers das Tab »Unix settings« hinzu (siehe Abbildung 3). Für zentrale Einstellungen ist das GUI das Plugins selbst zuständig; hier darf der Admin vorgeben, welches Homeverzeichnis, welche GID und welche UID die PADL-Software standardmäßig auswählen soll (Abbildung 4).

Allerdings funktioniert die Schema-Erweiterung des PADL-Plugins nur mit Windows 2000. Windows 2003 braucht Microsofts Services for Unix (SFU,[16], siehe Abbildung 5). Eine Schema-Erweiterung ist irreversibel; Einträge können nachträglich nicht mehr entfernt, nur modifiziert werden. Deshalb: Wer die SFU nicht anderweitig benötigt, kann sie getrost gleich wieder deinstallieren. <@99 L_Dreieck (E)>E

01 host              dc.nwtraders.msft
02 base              dc=nwtraders,dc=msft
03 ldap_version 3
04 
05 use_sasl on
06 sasl start_tls
07 scope sub
08 
09 nss_base_passwd   ou=user,dc=nwtraders,dc=msft?sub
10 nss_base_shadow   ou=user,dc=nwtraders,dc=msft?sub
11 nss_base_group    ou=group,dc=nwtraders,dc=msft?one
12 
13 # Services for UNIX 3.5 mappings
14 nss_map_objectclass posixAccount User
15 nss_map_objectclass shadowAccount User
16 nss_map_attribute uid msSFU30Name
17 nss_map_attribute uniqueMember msSFU30PosixMember
18 nss_map_attribute homeDirectory msSFU30HomeDirectory
19 #nss_map_attribute homeDirectory msSFUHomeDirectory
20 nss_map_objectclass posixGroup Group
21 pam_login_attribute msSFU30Name
22 pam_filter objectclass=User
23 
24 sasl_secprops maxssf=0
25 krb5_ccname FILE:/etc/.ldapcache

Das PADL-Plugin erfüllt aber auch unter Windows 2003 sinnvolle Aufgaben. Gerade im plattformübergreifenden Betrieb erweist es sich als sehr praktisch. Bei einer hohen Anzahl an Linux-Benutzern im Active Directory ist es jedoch meist einfacher, Attribute über Windows-Skripte zu setzen (die zum Beispiel CSV-Files zusammen mit »dsmod« oder »csvde« nutzen).

Abbildung 3: Das Tab »Unix settings« fehlt bei einer Standardinstallation von Windows 2003 noch, das PADL-Plugin »AD4Unix« ergänzt es. Hier tippt der Admin die Einträge ein, die Nss_ldap für seine Linux-Benutzer braucht.

Abbildung 4: Praktisch am PADL-Plugin: Der Admin kann viele Vorgaben zentral für alle User einstellen. Leider sind die UIDs hart kodiert. Für mehr Flexibilität ist Skripting gefragt.

Abbildung 5: Während der Installation der SFU 3.5 (Services for Unix) führt Windows 2003 eine Schema-Erweiterung durch. Erst danach können Linux-Clients das Active Directory sinnvoll nutzen.

Wer heterogenen IT-Massenbetrieb administriert, will auch bei der Benutzerverwaltung unnötige Doppelarbeit vermeiden: Liegen die Daten schon im Active Directory eines Windows-2003-Servers, dann soll sich Linux daraus bedienen. Mit einigen Kniffen gelingt das auch.