Mit LDAP Accounts für Unix und Windows zentral verwalten

Zentrale Benutzerverwaltung - das klingt trocken und bürokratisch, ist aber sehr praktisch: Der Admin verwaltet seine User zentral an einer Stelle und trägt dort alle Daten samt Telefonnummer und E-Mail-Adresse ein. Der Benutzer kann seinen Account auf allen Plattformen nutzen und im LDAP-Verzeichnis nach Telefonnummern suchen.[1]

Ohne Zentralisierung wird die Benutzerverwaltung in großen Netzen mit vielen unterschiedlichen Plattformen zum Problem. Die Admins müssen Accounts und Passwörter an vielen verschiedenen Stellen pflegen - eine lästige und monotone Tätigkeit. Auch für den User ist es lästig, sich für verschiedene Server und Services unterschiedlich zu anzumelden. Das regelmäßige Ändern der Passwörter bleibt dabei ebenso auf der Strecke wie deren Qualität. Stattdessen sind Zettel neben dem Bildschirm zu finden, die Geheimnisse sind einfach zu erraten.

Abhilfe schafft eine Benutzerdatenbank, mit der die User ihren Account auf allen Systemen verwenden können, unabhängig davon, ob es Linux, ein anderes Unix oder ein Windows-PC ist. Für diese Zentralisierung kommt unter Linux und bei vielen Unix-Systemen derzeit am häufigsten NIS (Network Information Service) zum Einsatz. Im Hintergrund sorgen der Name Service Switch (NSS) und die Pluggable Authentication Modules (PAM) dafür, dass die authentifizierenden Programme auf die richtige Benutzerdatenbank zugreifen (siehe Kasten "NSS und PAM").

Samba und LDAP ersetzen das Active Directory

Unter Windows übernimmt der Primary Domain Controller (PDC) die zentrale Benutzerverwaltung. Wer bisher die Authentifizierung zwischen Unix und Windows vereinheitlichen wollte ohne sich dabei in die Abhängigkeit von einem Microsoft-Produkt zu bringen, war auf wackelige Kompromisslösungen oder teure Produkte von anderen Herstellern angewiesen. Die moderne Alternative ist ein (Open-)LDAP-Verzeichnisdienst.

Ein LDAP-Server hat im Vergleich zu NIS klare Vorteile, er ist sicherer, flexibler und besser strukturiert. Die Umstellung von NIS auf LDAP lässt sich technisch einfach realisieren: Ein PAM-Modul bezieht die typischen Datensätze von »/etc /passwd« und »/etc/group« nun aus den Objekten im Verzeichnisserver.

Obwohl Microsoft die Methoden und Protokolle von LDAP für seinen Active Directory Server nutzt, lässt sich die Windows-Welt nicht so einfach an einen Server aus der Unix-Welt anbinden. Als Brückenglied dient hier der Samba-Server, der in seiner aktuellen Version 2.2.3a als PDC für die Windows-Seite arbeitet und die Benutzerdaten andererseits in einem LDAP-Server verwalten kann (siehe Abbildung 1).

Diese Funktionalität ist in Samba zwar nicht neu, sie wird in der Praxis jedoch eher selten genutzt. Der Schritt in diese Art der Benutzerverwaltung ist aber nicht schwer. Die folgende Beschreibung zeigt, wie ein Samba-Sign-On-Server eingerichtet wird.

Samba Sign On in der Praxis

Als Beispiel dient ein Labornetzwerk »labnet« mit einem Linux-Server »lxserver.labnet« und einem Windows-2000-Client »w2kclient.labnet«. Die genaue Linux-Distribution spielt keine Rolle, sie muss nur aktuell sein. Windows 2000 wurde mit Service Pack 2 installiert.

Die LDAP-Anbindung des Linux-Servers klappt mit »nss_ldap-183« und »pam_ ldap-137« von PADL Software[2] sowie »openldap-2.0.21«[3] und »samba-2.2.3a«[4]. Als LDAP-Browser dient »gq-0.4.0«[5]. Bei Samba ist die aktuelle Version entscheidend, bei den anderen spielt die Versionsnummer keine große Rolle.

OpenLDAP, »nss_ldap« und »pam_ldap« unterstützen als Sicherungsschicht SSL (Secure Sockets Layer) und SASL (Simple Authentication and Security Layer). Samba kennt derzeit nur SSL, das Beispiel verzichtet daher auf SASL. Wer sich für Kerberos interessiert, sollte sich mit SASL näher beschäftigen[11]. Die GSSAPI (Generic Security Services API) ermöglicht Kerberos-Authentifizierung mit SASL und damit eine sanfte Umstellung auf echtes Single Sign On.

Sollte die Software noch nicht installiert sein (oder nur eine zu alte Version), empfiehlt es sich, anhand des vom Distributor gelieferten Source-Pakets (etwa SRPM) ein neues Installationspaket zu bauen. Der Mehraufwand lohnt sich, da der Paketmanager die Kontrolle über die installierte Software behält.

Bei Samba ist eine eigene Installation auch dann nötig, wenn bereits die aktuelle Version 2.2.3a vorliegt. Diese macht nämlich ein paar kleine Fehler beim Binden an den LDAP-Server. Damit »pam_smbpass« am Ende auch so funktioniert wie hier beschrieben sind einige Patches nötig[6]. Bei »./configure« sind neben den vom Distributor oder aus eigener Überzeugung gewählten Optionen auch »--with-pam --with-pam_smbpass --with-ldapsam --with-ssl« erforderlich.

Abbildung 1: Der LDAP-Server kann Accounts für Windows- und Linux-Rechner zentral verwalten. Während Linux direkt auf die LDAP-Daten zugreifen kann, benötigt Windows einen Samba-Server als Zwischenstufe.