25 Samba als Domänenmitglied

Transkript

1 Samba als Domänenmitglied Wenn man mehr als einen Samba-Server oder einen echten Windows- Server betreibt, benötigt man genauso wie mit einer echten Windows- Domäne eine zentrale Benutzerverwaltung Einer NT-Domäne beitreten Die zentrale Verwaltung der Passwörter ist ein erster Schritt zur zentralen Benutzerverwaltung. Um dies zu erreichen, muss man mit Samba einer Domäne beitreten. Im Folgenden wird erläutert, wie einer NT- Domäne beigetreten werden kann. Was alles zu beachten ist, wenn man eine Active-Directory-Domäne betreten möchte, wird weiter unten beschrieben. Man setzt in der smb.conf folgende Parameter: [global] workgroup = windows security = domain Im Kapitel 13 wurde beschrieben, wie eine SMB-Sitzung aufgebaut wird. Dort wurde auf den Unterschied zwischen security = share und security = user eingegangen. Mit der Einstellung security = domain verhält sich ein Samba-Server aus der Sicht eines Clients genau wie mit security = user, es wird vom Benutzer im Session Setup ein Benutzername, eine Domäne und ein Kennwort verlangt. Ist das Kennwort nicht korrekt, so wird der Benutzer zurückgewiesen. Der Parameter security = domain bewirkt nun, dass das Passwort nicht wie bei security = user in der lokalen Benutzerdatenbank nachgesehen wird, sondern an einen Domänencontroller weitergeleitet wird. Dieser entscheidet dann, ob das Passwort korrekt ist oder nicht. Bestätigt der DC das Passwort, akzeptiert Samba den Benutzer. Kann der DC die Benutzeridentität nicht bestätigen, macht Samba einen zweiten Versuch anhand der lokalen Benutzerdatenbank. Damit kann man erreichen, dass für Administratoren der Zugriff auf den Samba-Server noch möglich ist, falls einmal kein Domänencontroller verfügbar sein sollte. security = domain entspricht aus Clientsicht security = user

2 Samba als Domänenmitglied Zusätzlich zu security = domain gibt es noch security = server. Diese Einstellung ist jedoch nicht mehr zu empfehlen, dazu mehr am Ende des Kapitels. Damit Samba den Domänencontroller finden kann, ist es notwendig, dass die NetBIOS-Namensauflösung im Netzwerk korrekt funktioniert. Daher ist es hier möglicherweise nötig, die name resolve order korrekt zu setzen. Insbesondere ist dies wichtig, wenn die Namen der DCs im DNS bereits vergeben sind und vielleicht auf andere Maschinen zeigen als die entsprechenden NetBIOS-Namen. Um für bestimmte Benutzer nicht auf den PDC angewiesen zu sein, versucht Samba bei einem erfolglosen Versuch der Domänenanmeldung zusätzlich, den Benutzer in der lokalen Benutzerdatenbank zu finden. Damit kann der Server mit möglicherweise nicht aktuellen Passwörtern funktionsfähig gehalten werden, auch wenn der PDC einmal ausfallen sollte. Mit folgendem Befehl legt Samba auf dem Windows- Domänencontroller ein Maschinenkonto an und tritt der Domäne bei: root@host: > net rpc join -U Administrator Password: Joined domain WINDOWS. net erfragt das Passwort des angegebenen Benutzers. Ist das eingegebene Passwort korrekt, wird das Computerkonto auf dem PDC erstellt und das Passwort für dieses Konto gesetzt. Ist Samba Domänenmitglied, so wird das Passwort zum Computerkonto in der Datei secrets.tdb abgespeichert. Diese übernimmt damit die Aufgabe der Datei DOMAIN.MACHINE.mac, die es bis Samba 2.0 gab. Geht diese Datei verloren, muss die Domäne neu betreten werden Mitglied einer Active-Directory-Domäne werden Wie bereits am Anfang dieses Buches erwähnt, kann Samba 3 auch Mitgliedsserver in einer Active-Directory-Domäne werden. Dazu dient der Parameter security = ads. Im Unterschied zu security = domain erfolgt die Authentifizierung hier mit Kerberos, nicht mit NTLM. Weitere Informationen über Kerberos erhalten Sie in Abschnitt Bevor nun der Domänenbeitritt erfolgen kann, müssen noch einige Dinge beachtet und konfiguriert werden:

3 25.3 Zentrale Benutzerverwaltung 179 Systemuhrzeiten: Zunächst einmal ist es unerlässlich, dass die Systemuhrzeiten des zukünftigen Samba-Mitgliedsservers und des Active-Directory-Domänencontrollers nahezu identisch sind. Am besten setzt man einen zentralen Zeitserver im LAN ein und konfiguriert alle Server so, dass sie regelmäßig ihre Systemzeit aktualisieren. Namensauflösung: Es sollte einen Windows-DNS-Server geben. Dies kann zum Beispiel der AD-Controller sein. Der DNS-Server muss in der Datei /etc/resolv.conf des Samba-Servers eingetragen werden. Wenn kein Windows-DNS vorhanden ist, muss die Datei /etc/krb5.conf angelegt beziehungsweise konfiguriert werden. Eventuell muss auch der Samba-Parameter password server = ADCONTROLLER gesetzt werden. smb.conf: Auch die Samba-Konfiguration muss vorbereitet werden. realm = IHRREALM definiert den Realm, security = ads gibt an, dass wir einem Active Directory beitreten. Windows-2003-AD: Wird ein Windows-2003-Active-Directory- Domänencontroller eingesetzt, muss zusätzlich noch client schannel = no gesetzt werden. Auch hier wird der Befehl net zum Beitreten der Domäne verwendet, diesmal allerdings mit dem Unterbefehl ads join: root@host: > net ads join -U Administrator Administrator s password: [2006/03/24 13:36:16, 0] libads/ldap.c:ads _ add _ machine _ acct(1414) Joined BANDO to realm EXAMPLE.DE root@host: > 25.3 Zentrale Benutzerverwaltung Mit der Domänenmitgliedschaft wird der Samba-Server nur von der Passwortverwaltung befreit. Um die Benutzer und Gruppen muss er sich weiterhin selbst kümmern. Eine gewisse Erleichterung kann dabei das add user script bringen. Arbeitet Samba als PDC, sorgt dieses Skript dafür, die Computerkonten in der /etc/passwd automatisch zu erstellen. Ist Samba Domänenmitglied, so wird bei einer Benutzeranfrage auf den Server zunächst der PDC nach der Richtigkeit des Passwortes befragt. Bestätigt dieser das Passwort und will der Benutzer dann auf das Dateisystem des Samba-Servers zugreifen, so wird eine Unix- User-ID benötigt. Diese sucht Samba in der normalen Unix-Benutzerdatenbank. Findet Samba dort trotz erfolgreicher Anmeldung am PDC Unix-Benutzer automatisch anlegen

4 Samba als Domänenmitglied Gruppen müssen gepflegt werden keinen Benutzer, so wird das add user script mit entsprechenden Argumenten aufgerufen, um den Benutzer zu erstellen. Damit muss man sich teilweise nicht mehr um die Verwaltung der Benutzer auf dem Samba-Server kümmern.»teilweise«deswegen, da von dem neu anzulegenden Benutzer ausschließlich der Name bekannt ist. Es fehlt jegliche Information darüber, in welchen Gruppen sich der Benutzer in der Domäne befindet. Diese Einschränkung macht eine Rechteverwaltung auf dem Samba-Server sehr schwierig bis unmöglich Zentrale Benutzerverwaltung mit Winbind Echtes Domänenmitglied durch Winbind Wenn Sie Samba als Domänenmitglied betreiben, haben Sie die größte Hürde zu einer problemlosen Integration bereits genommen: die Passwortverwaltung. Jeder Benutzer kann sein Passwort in der Domäne ändern, und die Änderung wird sofort auf allen Domänenmitgliedern sichtbar. Ein Problem bleibt jedoch bestehen: Sie müssen auf den Samba-Servern, die Domänenmitglieder sind, die Benutzer nachpflegen. Wenn Sie einen neuen Benutzer in der Domäne anlegen oder Gruppenmitgliedschaften ändern, müssen Sie dies manuell auf den Samba- Servern eintragen. Ist auch der Primary Domain Controller ein Samba- Server, konnten Sie sich zu Zeiten von Samba 2 mit dem Network Information System (NIS) behelfen, aber wenn die Benutzerdatenbank auf einem Windows-Server liegt, ist dieser Weg verschlossen. Eine zwischen Windows und Unix wirklich vereinheitlichte Benutzerdatenbank bietet heute der Dämon winbind. Er ermöglicht die volle Einbindung eines Unix-Systems in eine Windows-Domäne. Voraussetzung dafür ist die Unterstützung der nsswitch-module. Dies bieten inzwischen Linux, FreeBSD, Solaris, AIX, Irix, HP-UX und Tru64. Systeme, für die es keinen nsswitch-mechanismus gibt oder für die noch kein entsprechendes Modul portiert wurde, bleiben außen vor. Wenn Sie den winbind korrekt konfiguriert haben, können Sie Zugriffsrechte an Freigaben Ihres Samba-Servers direkt anhand von Domänengruppen steuern. Sie können beispielsweise Folgendes eintragen: valid users Windows kann NIS-Server werden und so allen Benutzern der Gruppe edv Ihrer Domäne Zugriff auf eine Freigabe geben. Seit Microsoft die Services for Unix 1 (SFU) veröffentlicht hat, gibt es zum winbind noch eine andere Alternative. Die SFU beinhalten unter 1 Die Services für Unix sind eine Erweiterung von Microsoft, die die Integration von Windows in Unix-Umgebungen erleichtern sollen. Mehr Informatio-

5 25.4 Zentrale Benutzerverwaltung mit Winbind 181 anderem einen NIS-Server für NT und Wenn Sie diesen installieren, bekommen der NT-Benutzermanager und der Benutzer-Editor für das Active Directory einen weiteren Eigenschaftsreiter, in dem Sie die Unix-spezifischen Eigenschaften des Benutzers wie z. B. die numerische ID und das Heimatverzeichnis setzen können. Weiterhin bekommen Sie einen Unix-Dämon 2 geliefert, mit dem Sie Passwortänderungen von NT an Unix weitergeben können. Der Dämon nutzt die PAM-Schnittstelle zur Änderung der Passwörter nsswitch-module Viele Programme unter Unix müssen auf Datenbanken im Verzeichnis /etc zugreifen. Beispielsweise muss ls -l den Dateibesitzer, der in der Datei nur in numerischer Form vorliegt, in einen Benutzernamen übersetzen. Dazu muss die numerische User-ID in der Datei /etc/passwd gesucht werden. Dass diese Übersetzung tatsächlich stattfindet, kann man leicht überprüfen: Man muss nur die Leserechte für others von der Datei /etc/passwd mit chmod o-r /etc/passwd entfernenund ls -l aufrufen. Die Dateibesitzer werden danach nur noch numerisch angezeigt 3. Sauber geschriebene Programme greifen nicht direkt auf die Dateien in /etc zu, sondern durch Bibliotheksaufrufe wie beispielsweise getpwuid(3). Dieser Aufruf würde einen Eintrag für einen Benutzer aus der /etc/passwd anhand der numerischen UID lesen. Seit der glibc- Version 2 werden diese Bibliotheksaufrufe in dynamisch geladenen Modulen implementiert. Gesteuert werden diese Module über die Datei /etc/nsswitch.conf. Für jede der Dateien in /etc, die von allgemeinem Interesse ist, gibt es eine Zeile in der /etc/nsswitch.conf. Beispielsweise wird der Zugriff auf die Datei /etc/passwd über die Zeile Programme lesen /etc/passwd nicht direkt passwd: compat gesteuert. Damit wird ein Kompatibilitätsmodul zum Zugriff herangezogen. Mit passwd: files nis nen finden Sie unter unix/sfu/default.mspx. 2 Sie bekommen sogar die Quellen des Dämons, der für Red Hat Linux 6.x kompiliert wurde. Der Versuch einer Neukompilation auf einer SuSE 8.0 wurde nach vier Stunden aufgegeben. So wie dieser Quellcode aussieht, muss es sich um einen der schlechter gepflegten Teile von Microsofts Programmen handeln... 3 Sollte dies nicht spontan funktionieren, kann der nscd schuld sein. Siehe hierzu Seite 187.

6 Samba als Domänenmitglied Libc lädt Shared Objects legen Sie explizit fest, dass zuerst in der lokalen Benutzerdatenbank /etc/passwd nach Benutzern gesucht werden soll. Schlägt dies fehl, wird das NIS befragt. Wie funktioniert diese Steuerung? Die Option compat im Eintrag für passwd bewirkt, dass zur Laufzeit eines Programms die dynamische Bibliothek /lib/libnss _ compat.so.2 geladen wird und die Anfrage beantworten muss. files und nis beziehen sich auf /lib/libnss _ files.so.2 und /lib/libnss _ nis.so.2. Winbind besteht aus zwei Teilen: einem Dämon winbindd und einer Datei libnss _ winbind.so. In den Samba-Quellen findet sich der Winbind unter source/nsswitch. Dort wird auch die Datei libnss _ winbind.so kompiliert. Zur Installation muss sie manuell nach /lib kopiert werden: cp source/nsswitch/libnss _ winbind.so /lib/libnss _ winbind.so.2 Der winbindd selbst wird im sbin-unterverzeichnis von Samba automatisch mitinstalliert Winbind konfigurieren Winbind aktivieren Sie, indem Sie die beiden Einträge für passwd und group in der /etc/nsswitch.conf um die Angabe winbind ergänzen. Das könnte etwa so aussehen: # /etc/nsswitch.conf passwd: files winbind group: files winbind Winbind braucht Computerkonto Damit werden Benutzer und Gruppen zuerst in den lokalen Dateien gesucht. Danach wird der winbindd befragt, der im Hintergrund laufen muss. Für die Konfiguration des winbindd muss Samba ein normales Domänenmitglied sein (siehe hierzu Kapitel 25). Der winbindd benötigt in der /etc/smb.conf einige zusätzliche Parameter. Eine vollständige Beispielkonfiguration ist die folgende: ; Samba als Domaenenmitglied workgroup = windows security = domain password server = * ; Winbind-Konfiguration winbind separator = + idmap uid = idmap gid = template shell = /bin/bash template homedir = /home/%d/%u

7 25.4 Zentrale Benutzerverwaltung mit Winbind 183 Die Parameter bedeuten im Einzelnen: winbind separator: Unter Windows wird ein Benutzername mit Domäne in der Form DOMAENE\benutzername angegeben. Unter Unix hat dies Nachteile, da der Backslash \ für die Shell eine Sonderbedeutung hat. Daher kann man den Trenner zwischen Domäne und Benutzername separat konfigurieren. Als unkritisch erweist sich das +-Zeichen. Ein Benutzer wird somit als DOMAE- NE+benutzername angegeben. Vorsicht aber beim unbedachten Ändern des Winbind-Separators: Alle Stellen, an denen Domänenbenutzer und -gruppen angegeben sind, müssen evtl. angepasst werden, insbes. auch in der smb.conf. winbind use default domain: Hiermit kann man bewirken, dass Benutzer, die Winbind erzeugt, nur aus dem eigentlichem Benutzerlogin-Namen bestehen, ohne den vorangestellten Domänenanteil. Ein Benutzer DOMAENE\benutzer1 würde also im System nur als benutzer1 erscheinen. idmap uid: Der winbindd muss dynamisch für Domänenbenutzer numerische User-IDs vergeben. Damit er dies tun kann, müssen Sie ihm mit dem Parameter idmap uid einen Bereich von User-IDs übergeben, die Sie nicht in der /etc/passwd oder im NIS verwenden. Wird auf einen Benutzernamen das erste Mal zugegriffen, wählt der winbindd für diesen Benutzer aus seinem Pool die nächste freie User-ID aus und speichert diese Zuordnung fest in der internen Datenbank winbindd _ idmap.tdb 4. idmap gid: Für Group-IDs gilt das Gleiche wie für User-IDs. idmap backend: Die Zuordnungen zwischen numerischen IDs und Benutzer- und Gruppennamen können unterschiedlich gespeichert werden. Weitere Informationen zu diesem Parameter finden Sie in Abschnitt template shell: Der Primary Domain Controller kennt das Konzept der Login-Shell nicht. Diese muss zentral für alle Winbind- Benutzer in der smb.conf vergeben werden. template homedir: Auch ein Heimatverzeichnis wird in der Benutzerdatenbank von Windows nicht abgespeichert und muss in der smb.conf vorgegebenwerden. Hierbeisollten Sieaufjeden Fall die Domäne des Benutzers in den Pfad mit aufnehmen, um Namenskollisionen bei Vertrauensstellungen sauber zu behandeln. Der Benutzer schmidt in der Domäne GOEsollte ein anderes Heimatverzeichnisbekommen alsderbenutzerschmidt in der Domäne HD. Die Heimatverzeichnisse werden selbstverständlich nicht 4 Das gilt nicht, wenn idmap backend nicht leer ist, siehe dazu Abschnitt winbindd _ idmap.tdb ist extrem wichtig Heimatverzeichnisse können kollidieren

8 Samba als Domänenmitglied automatisch erzeugt, sondern müssen manuell angelegt und den Benutzern übergeben werden. Auf einem reinen Dateiserver mit gemeinsamen Dateien ist es jedoch möglicherweise nicht notwendig, für jeden Benutzer eigene Heimatverzeichnisse anzulegen. Mit diesen Einstellungen kann man den winbindd zusätzlich zu den Dämonen smbd und nmbd starten, die ebenfalls laufen müssen Zuordnung von Unix-IDs zu Windows-SIDs Da Unix mit andersartigen numerischen IDs arbeitet als Windows, müssen die Windows-SIDs immer auf Unix-UIDs und -GIDs abgebildet werden. Dieser Vorgang wird als Identity Mapping bezeichnet. Der Winbind-Dämon beherrscht unterschiedliche Verfahren des Identity Mappings. Welches verwendet wird, bestimmt der Parameter idmap backend. Standardmäßig ist der Parameter idmap backend leer und es bekommt der erste vom System angefragte Benutzer- bzw. Gruppenname die nächste freie ID aus dem Zahlenbereich, der mit idmap uid und idmap gid bestimmt wurde, zugeordnet. Diese Zuordnungen werden in der Datei winbindd _ idmap.tdb gespeichert. Das Verfahren hat den Nachteil, dass die IDs zufällig den Namen zugeordnet werden. Zwei verschiedene Samba-Server haben also auch mit großer Wahrscheinlichkeit unterschiedliche Zuordnungen von IDs zu Benutzern und Gruppen. Beim Verlust der winbindd _ idmap.tdb hat man außerdem ein Problem hat man keine aktuelle Sicherung, so gehören anschließend einige Dateien evtl. anderen Benutzern als zuvor, weil für die jetzt unbekannten Benutzer wieder neue IDs»ausgewürfelt«werden. Das regelmäßige Sichern dieser TDB-Datei ist folglich enorm wichtig, wenn dieses Verfahren angewendet wird! Mehr zum Sichern von TDB-Dateien erfahren Sie in Abschnitt Falls Sie doch einmal in die missliche Lage kommen, dass Ihre winbindd _ idmap.tdb beschädigt ist, so haben Sie eine Chance, sie zu reparieren. Dazu gibt es die net-unterbefehle idmap dump und idmap restore. Der Name net idmap dump lässt bereits erahnen, dass er zum Ausgeben der winbindd _ idmap.tdb im Klartext dient. root@host: > net idmap dump /var/lib/samba/winbindd _ idmap.tdb UID S UID S UID S GID S UID S USER HWM 10006

9 25.4 Zentrale Benutzerverwaltung mit Winbind 185 UID S GROUP HWM UID S > Hier sieht man sehr schön, dass in dieser Datei einfach nur bestimmt wird, ob es sich um einen Benutzer oder eine Gruppe handelt (Spalte 1) und welche Unix-ID (Spalte 2) welchem Windows-SID (Spalte 3) zugeordnet wird. Eine Ausnahme sind die Einträge USER HWM und GROUP HWM Die Abkürzung HWM steht für High Water Mark.Die beiden Einträge sind Merker für die höchste vergebene Benutzer-ID und für die höchste vergebene Gruppen-ID. Das entsprechende Gegenstück zum Wiederherstellen der Datei ist net idmap restore. > net idmap dump /var/lib/samba/winbindd _ idmap.tdb net idmap restore ignoring invalid line [USER HWM 10006] ignoring invalid line [GROUP HWM 10001] USER HWM: GROUP HWM: root@host: > Die beiden Fehlermeldungen bezüglich der HWM-Einträge können ignoriert werden. Die maximal vergebenen IDs werden neu ermittelt und nicht aus der Datei übernommen. Vielleicht können auf diese Weise nicht alle Zuordnungen wiederhergestellt werden, aber mit etwas Glück wenigstens der größte Teil. Eine Methode, die ID-Mappings auf verschiedenen Samba-Servern identisch zu halten, existiert mit dem idmap _ rid-modul. Hierbei werden die Unix-IDs algorithmisch aus dem Windows-SID der Benutzer und Gruppen ermittelt, d. h., sie sind auf allen Samba-Servern identisch, und die Zuordnungen sind nicht in einer Datei abgelegt, deren Verlust oder Beschädigung schmerzliche Folgen haben kann. Um das idmap _ rid-modul zu verwenden, kann z. B. folgende Konfiguration eingesetzt werden: Reparieren der winbindd _ idmap.tdb idmap _ rid macht winbindd _ idmap.tdb überflüssig idmap backend = rid:"builtin= DOMAENE= " In älteren Samba-Versionen musste man statt rid im obigen Beispiel noch idmap _ rid schreiben. Die Zahlenbereiche legen fest, welche Unix- ID-Bereiche für die Zuordnung verfügbar sind und vom winbindd verwendet werden sollen.

10 Samba als Domänenmitglied ID-Mappings im LDAP speichern Wird LDAP als Benutzerdatenbank benutzt, so bietet es sich an, auch die ID-Mappings im LDAP abzulegen. Das wird durch folgenden Parameter realisiert: idmap backend = ldap:ldap://ldapmaster.dom.de ID-Mappings im Active Directory ablegen Wenn auf einem Windows-AD-Controller die Services for Unix (SFU) installiert sind und Samba im ADS-Mode läuft, gibt es jetzt auch die Möglichkeit, die POSIX-UIDs bzw. -GIDs, die den Benutzern im AD zugeordnet sind, zu benutzen. Hierbei werden zudem auch verschiedene Attribute wie z. B. die Loginshell berücksichtigt. Folgende Konfiguration würde das bewirken: idmap backend = ad winbind nss info = template sfu Winbind abfragen mit wbinfo Abfrage von Domänendaten per wbinfo Laufen winbindd, smbd und nmbd in der Domäne, kann man das Setup testen. Das Utility zum Testen heißt wbinfo. Der wichtigste Test ist der Aufruf wbinfo -t. Damit wird die Verbindung zum Domänencontroller geprüft, winbindd sucht den PDC und meldet sich mit dem Workstation- Konto an. wbinfo muss die Ausgabe Secret is good geben. Gibt wbinfo diese Ausgabe, so ist der winbindd gültiges Domänenmitglied und kann Informationen vom PDC abrufen. wbinfo kennt noch eine Reihe weiterer Parameter, mit denen die Benutzerdatenbank der Domäne abgefragt werden kann. Die Ausgabe des Aufrufs wbinfo ohne Parameter gibt einen Hilfetext mit den verfügbaren Optionen aus. Schlägt wbinfo -t fehl, so muss die Domänenmitgliedschaft überprüft werden. Verläuft der Test mit wbinfo -t erfolgreich, so kann man sich sämtliche verfügbaren Benutzer mit getent passwd und die Gruppen mit getent group auflisten lassen pam_winbind PAM steht für Pluggable Authentication Modules und stellt eine allgemeine API für Authentifizierungsdienste zur Verfügung. Es ist z. B. für Linux, AIX, HP-UX, Solaris verfügbar. Samba bietet auf Systemen, die PAM unterstützen, ein pam _ winbind-modul an, mit dem die Benutzerauthentifizierung gegen eine Windows-Domäne gemacht werden kann. Tru64 bietet übrigens eine ähnliche API namens SIA, die Samba auch inzwischen unterstützt.

11 25.4 Zentrale Benutzerverwaltung mit Winbind 187 Bevor man versucht, das Winbind-PAM-Modul einzurichten, sollte man sicher sein, dass Winbind richtig konfiguriert wurde und die Domänenbenutzer auflistet. Die PAM-Module, die man kombiniert benutzen kann, befinden sich meist in /lib/security hier sollte man auch pam _ winbind.so finden. Dieses kann man für jeden Dienst, der PAM unterstützt, in einer separaten Datei konfigurieren. Die Konfigurationsdateien dieser Dienste finden sich unter /etc/pam.d/. Um z. B. für den sshd Winbind-Authentifizierung zuzulassen, müsste man folgende Zeilen in die /etc/pam.d/sshd hinzufügen: auth sufficient pam _ winbind.so account sufficient pam _ winbind.so password sufficient pam _ winbind.so session sufficient pam _ winbind.so Ein Problem, das beim Login auftreten könnte, ist, dass das Homeverzeichnis der Benutzer nicht existiert und es daher zu Fehlern kommt. Es sollte also darauf geachtet werden, dass dieses existiert. Alternativ kann das pam _ mkhomedir-modul so konfiguriert werden, dass es das Anlegen der Homeverzeichnisse beim ersten Benutzer-Login übernimmt. Wer PAM für Domänenlogins anpassen will, sollte sich auf jeden Fall auch mit der Dokumentation von PAM beschäftigen nscd Unter Linux ist der Name Service Caching Daemon nscd ein Programm, mit dem sämtliche Abfragen durch den nsswitch-mechanismus gecacht werden können. Der nscd macht Sinn, wenn diese Anfragen sehr lange dauern. Dies kann der Fall sein, wenn die Dateien sehr groß sind, etwa wenn hunderte von Benutzern im System angelegt sind. Ein anderer Verzögerungsgrund ist die Abfrage von Benutzerdaten über ein Netzwerk beim Einsatz von NIS oder dem Verzeichnisdienst LDAP. Ein Nachteil des nscd kann sein, dass er Änderungen in der Benutzerdatenbank nicht schnell genug mitbekommt. Insbesondere beim Testen des winbindd kann dies sehr hinderlich sein. Wer beispielsweise Folgendes schon einmal erlebt hat, hat ein Problem mit dem nscd: nscd nur bei großen oder langsamen Benutzerdatenbanken benutzer@host: > ~ # useradd -m vl benutzer@host: > ~ # passwd vl passwd: Unknown user vl benutzer@host: > ~ # In diesem Falle sollte man den nscd schleunigst beenden und dafür sorgen, dass er beim nächsten Systemstart nicht wiederkommt. Erst wenn

12 Samba als Domänenmitglied Sie eine stabile Umgebung haben und der Zugriff auf die Benutzerdatenbank spürbar langsam ist, sollten Sie ihn wieder aktivieren Hintergrund: security = server Zentrale Passwörter ohne Domänenprotokoll Pro SMB-Verbindung nur eine Herausforderung Vor Samba 2.0 gab es für die zentrale Verwaltung von Passwörtern nur die Möglichkeit, security = server zu setzen. Damit konnte ein Samba- Server sehr einfach die Anmeldung von einem weiteren Server oder einer NT Workstation beziehen. Samba 3 beherrscht diese Möglichkeit immer noch, man sollte jedoch strikt von ihrer Nutzung abraten, da sie erhebliche Probleme mit sich bringt. security = server nutzt nicht das Domänencontroller-Protokoll, sondern leitet den Benutzernamen und das Passwort an einen Server weiter. Dies ist im Prinzip nicht schlecht, birgt aber ein subtiles Problem. Setzt man keine verschlüsselten Passwörter ein, verschicken viele Clients die Passwörter in Großbuchstaben. Wenn der Passwort-Server nun verschlüsselte Passwörter verlangt, muss Samba raten. Dies kostet Last und Zeit. Wenn man auf dem Samba- Server verschlüsselte Passwörter einsetzt, dann handelt man sich ein noch subtileres Problem ein. Um das zu verstehen, sollte man sich das Kapitel 21 auf jeden Fall genau angesehen haben. In der Antwort zur Anfrage»Negotiate Protocol«liefert der Server dem Client eine Herausforderung (challenge). Im Session Setup muss der Client die mit dem Passwort verschlüsselte Herausforderung liefern (vgl. 13.4, Seite 93). Will Samba dies nun gegenüber einem Passwort- Server machen, so muss er zunächst einen Negotiate Protocol Request zum Passwort-Server absetzen, um von diesem eine Herausforderung zu erhalten. Diese Herausforderung liefert er seinem Client direkt weiter, damit dieser sie dann mit dem Passwort verschlüsseln kann. Da es pro Verbindung vom Client zum Server nur einen Negotiate Protocol Request gibt, gilt die Herausforderung für die gesamte Verbindung. Viele Clients setzen aber mehrere Session Setups über die gleiche Verbindung ab. Damit der Samba-Server zwischen Client und Passwort-Server immer mit der gleichen Herausforderung arbeiten kann (der Client sieht nur diese eine Herausforderung), muss er zum Passwort-Server ständig eine Verbindung offen halten. Bräche diese Verbindung ab, bekäme der Samba-Server vom Passwort-Server eine neue Herausforderung mitgeteilt. Der Samba-Server hat leider keine Möglichkeit, den Client dazu zu zwingen, eine neue Herausforderung zu verlangen. Die einzige Möglichkeit ist, die Verbindung zum Client abzubrechen, um einen neuen Negotiate Protocol Request zu verlangen. Damit gibt es zwei Probleme:

13 25.5 Hintergrund: security = server 189 Pro Clientsystem muss der Samba-Server ständig eine Verbindung zum Passwort-Server offen halten. Das kann bei vielen Clients den Passwort-Server erheblich belasten. Das Netz wird außerordentlich instabil, sollte sich der Passwortserver entscheiden, diese vielen nicht besonders aktiven Verbindungen abzubrechen. Clients werden sich am Samba-Server erneut anmelden müssen. Das Domänencontroller-Protokoll löst diese beiden Probleme, indem es dem Samba-Server erlaubt, sich eine eigene Herausforderung pro Client auszudenken und diese bei der Netzwerkanmeldung dem PDC mitzuschicken. Um kein Sicherheitsproblem aufkommen zu lassen, muss diese Netzwerkanmeldung vom Samba-Server zum PDC verschlüsselt sein, daher das Computerkonto, dessen Passwort als Schlüssel für die symmetrische Verschlüsselung zwischen Samba-Server und PDC verwendet wird.