Samba-Winbind schlägt die Brücke zum Active Directory
16. Oktober 2012
Eine durchgängige Anmeldung auf Windows- sowie Unix-/Linux-Systemen – mit den identischen Anmeldeinformationen aus der Windows-Domäne – erlaubt Samba-Winbind. Doch wer diese Vereinfachung in einer heterogenen Umgebung einsetzen möchte, der muss einige Konfigurationsdetails beachten, die relativ komplex sind. Kommerzielle Systeme für diese Aufgabe sind einfacher zu installieren – haben aber ihren Preis.
Bei Winbind handelt es sich um einen Dienst, der zusammen mit der frei verfügbaren Samba-Software gebündelt ist. Samba bietet als ein Opensource-Projekt eine Ansammlung von Programmen und Funktionalitäten, über die Unix- und Linux-Systeme über die Microsoft-Protokolle SMB (Server Message Block) und CIFS (Common Internet File System) Zugriff auf die Datei- und Druckdienste von Windows-Plattformen bekommen. Andererseits können Clients, die auf Windows basieren und die die Protokolle SMB und CIFS verwenden, Datei- und Druckdienste aus der “anderen Welt” bekommen. Mehr Informationen zu Samba gibt es auf der zugehörigen Website.
In Abbildung 1 ist die Architektur von Winbind zu erkennen. Dabei ist eines zu beachten: Winbind ermöglicht es einem Unix-/Linux-Anwender, nicht nur eine Windows-Domäne für die Authentifizierung zu nutzen, sonder auch dass das Unix-/Linux-System der Windows-Domäne beitreten und sich in ihr authentifizieren kann.
Dabei spielt Winbind mit Windows NT 4.0, Windows 2000, Windows Server 2003 sowie mit Domänencontrollern (DCs) – und Domänen – auf der Basis von Windows Server 2008 zusammen. Winbind setzt keine Änderungen auf der Seite eines Windows-DC voraus. Die meisten Änderungen beziehen sich auf den Unix- oder Linux-Client.
Die Winbind-Lösung setzt auf den Winbind-Dämon-Prozess (winbindd) auf. Dazu sind noch ein PAM (Pluggable Authentication Module) namens “pam_winbind”, ein NSS-Modul (Name Service Switch) namens libnss_winbind und eine Datenbankdatei namens winbind_idmap.tdb nötig.
Kommunikation läuft über Microsoft-RPCs
Der Winbindd-Code enthält auch noch eine Unix-Implementierung von Microsofts RPCs (Remote Procedure Calls). Denn Winbindd verwendet RPCs, um die Benutzer an einer Windows-Domäne zu authentifizieren. Dabei werden die Details zu einem Windows-Domänenbenutzer und seine Gruppeninformationen von einem Windows-DC abgefragt. Damit lassen sich dann auch zum Beispiel die Kennworte für Windows-Benutzerkonten ändern.
Das Modul “pam_winbind” versetzt einen Anwneder in die Lage, sich an einem Unix-/Linux-System mit den Annmeldeinformationen von Windows anzumelden. Im folgenden ist ein Auszug einer bespielhaften PAM-Konfigurationsdatei zu sehen. Sie erlaubt es dem Unix-/Linux-Anmeldeprozess, Winbind für die Authentifizierung eines Benutzers aufzurufen. In diesem speziellen Fall würde pam_unix die Anmeldeinformationen wiederverwenden, die der Benutzer eingibt, falls der Winbind-Ansatz fehlschlägt.
login auth sufficient pam_winbind.so login auth required pam_unix.so nullok try_first_pass
Das NSS-Modul libnss_winbind versetzt die Unix-/Linux-Systeme und die darauf laufenden Dienste in die Lage, einen Windows-DC nach dem Benutzerkennwort und den zugehörigen Gruppeninformationen zu fragen. Um dieses Winbind-NSS-Modul nutzen zu können, muss der Administrator die NSS-Konfigurationsdatei (sie heißt nsswitch.conf) wie folgt editieren:
passwd: files winbind group: files winbind
Diese Abbildungen müssen auf jedem Unix-/Linux-System, auf dem sich Benutzer mit ihren Windows-Anmeldeinformationen anmelden, definiert sein. Wenn der Administrator die UID- und GID-Bereiche für ein System in der Idmap angibt, muss er sicherstellen, dass sich diese Bereiche nicht mit den Werten überschneiden, die für die lokalen Unix-/Linux-Benutzer (oder die entsprechenden Gruppen) vorgesehen sind.
Inkonsistenzen können auftreten
Zudem ist im Standardumfang von Winbind nicht die Funktionalität enthalten, die sicherstellt, dass Ein Windows-Benutzer dieselbe UID zugewiesen bekommt, selbst wenn er auf verschiedenen Unix-/Linux-Systemen aktiv ist. Diese Einschränkung erklärt auch, warum Idmap zu Inkonsistenzen führen kann, wenn Windows-Benutzer sich an verschiedenen Unix-/Linux-Systemen angemeldet haben und dann auf gemeinsame Ressourcen – wie etwa einen NFS-basierten Dateiserver, zugreifen.
Da verschiedene Unix-/Linux-Systeme auch unterschiedliche UIDs abbilden können, kann es beim Zugriff eines Benutzers auf eine bestimmte NFS-Ressource darauf ankommen, welche UID er verwendet – oder anders ausgedrückt: welches Unix-/Linux-System sie verwenden, um auf diese Ressource zuzugreifen.
Einige Implementierungen von Winbind bietet für dieses Problem eine Lösung. Sie basiert auf den Konfigurationseinstellungen zu idmap_rid in der Datei „smb.conf“. Die Einstellungen in idmap_rid versetzen Winbind-Dämonprozesse in die Lage, einzigartige UIDs und GIDs über eine Windows-Domäne zu erzeugen. Diese Einzigartigkeit basiert auf der Abbildung des RID-Anteils (Relative Identifier) einer Windows_SID auf eine Unix-/Linux-UID oder -GID. Zusätzliche Informationen, wie man am besten Winbind und die zugehörigen Komponenten aufsetzt, sind in der Howto-Dokumentation von Samba zu finden.
Kommerzielle Alternativen sind leichter zu installieren
Es stehen aber auch kommerzielle Alternativen zu Samba-Winbind zur Verfügung. Zum Beispiel ist Quest Authentication (früher als Vintela Authentication Services bekannt) und Centrify DirectControl zu nennen. Beide Lösungen bieten eine zentralisierte Active Directory-basierte Benutzer- und Computerkonten-Verwaltung für Windows und Unix-/Linux-Clients. Verglichen mit Samba bietet diese Lösungen eine vereinfachte Installation und sie verfügen auch über mehr Konfigurationsoptionen. Doch das alles hat auch seinen Preis.
