Kapitel 9

In diesem Kapitel befassen wir uns mit den grundlegenden Konzepten der Sicherheit in Samba. Ziel ist es, Ihren Samba-Server mit den Sicherheitsrichtlinien auszustatten, die für Ihr Netzwerk geeignet sind.

Eine der kompliziertesten Aufgaben bei Samba besteht darin, die Sicherheitsmodelle von Unix- und Windows-Systemen in Einklang zu bringen. Samba muss Benutzer identifizieren, indem es sie mit gültigen Benutzernamen und Gruppen verknüpft und sie über die Kennwörter authentifiziert. Anschließend muss es den Zugriff der Benutzer auf die Ressourcen kontrollieren, indem es ihre Zugriffsrechte mit den Berechtigungen auf den Dateien und Verzeichnissen vergleicht. Das sind für sich genommen schon komplizierte Themen. Dabei wird alles noch schwieriger durch die Tatsache, dass drei unterschiedliche Betriebssystemarten an der Angelegenheit beteiligt sind (Unix, Windows 95/98/Me und Windows NT/2000/XP) und Samba mehrere Methoden zur Benutzerauthentifizierung unterstützt.

Benutzer und Gruppen

Lassen Sie uns so simpel wie möglich beginnen und Unterstützung für einen einzigen Benutzer hinzufügen. Das Einfachste ist es, für die betreffende Person einen Unix-Benutzerzugang (und ein Home-Verzeichnis) auf dem Server einzurichten und Samba die Existenz des Benutzers mitzuteilen. Dazu können Sie eine Verzeichnisfreigabe erstellen, die in der Samba-Konfigurationsdatei auf das Home-Verzeichnis des Benutzers abgebildet wird, und den Zugriff darauf mit der Option valid users auf diesen Benutzer beschränken. Zum Beispiel:

Die Option valid users führt die Benutzer auf, die auf die Freigabe zugreifen dürfen. In diesem Fall handelt es sich dabei ausschließlich um den Benutzer dave. Manchmal ist es möglich, allen Benutzern den Zugriff auf eine Freigabe zu gewähren. Dazu verwendet man den Parameter guest ok. Da wir den Gastzugriff nicht wünschen, haben wir diese Option weggelassen. Wenn Sie sowohl authentifizierten Benutzern als auch Gastbenutzern den Zugriff auf die gleiche Freigabe erlauben, können Sie diese Dateien mit Leseberechtigungen für »andere« Benutzer ausstatten, während Sie den Zugriff auf andere Dateien auf bestimmte Benutzer oder Gruppen begrenzen.

Wenn Client-Benutzer auf eine Samba-Freigabe zugreifen, müssen sie zwei Sicherheitsstufen überwinden. Unix-Berechtigungen auf Dateien und Verzeichnisse gelten wie üblich. Außerdem werden die Konfigurationsparameter angewendet, die in der Samba-Konfigurationsdatei festgelegt wurden. Mit anderen Worten: Ein Client muss zuerst die Sicherheitsmechanismen von Samba durchlaufen (z.B. Authentifizierung mit gültigem Benutzernamen und gültigem Kennwort, Überprüfung mit den Parametern valid users und read only usw.) und dann noch die normalen Unix-Datei- und Verzeichnisberechtigungen seines Unix-seitigen Benutzers zu seinen Gunsten vorfinden, bevor er Lese- und Schreibzugriff auf eine Freigabe erhalten kann.

Vielleicht erinnern Sie sich, dass Sie das Home-Verzeichnis mit der Variablen %H abkürzen können. Zudem können Sie in diesen Optionen die Variable %u für den Unix-Benutzernamen und/oder %U für den Client-Benutzernamen verwenden, wie zum Beispiel in folgenden Zeilen:

Wenn ein einziger Benutzer auf ein Home-Verzeichnis zugreift, werden die Zugriffsberechtigungen in dem Moment beachtet, in dem das Betriebssystem den Benutzerzugang einrichtet. Das Home-Verzeichnis gehört dem Benutzer, und die Berechtigungen werden entsprechend eingestellt. Wenn Sie jedoch ein Verzeichnis für eine Gruppe von Benutzern freigeben wollen, müssen Sie einige weitere Schritte ausführen. Lassen Sie uns eine Gruppenfreigabe für die Buchhaltungsabteilung in der Datei smb.conf herausgreifen:

Der erste Unterschied besteht darin, dass wir an Stelle eines oder mehrerer einzelner Benutzernamen @account als gültigen Benutzer angegeben haben. Dabei handelt es sich um eine abgekürzte Schreibweise dafür, dass die gültigen Benutzer durch die Unix-Benutzergruppe account repräsentiert werden. Sie müssen diese Benutzer dem group-Eintrag account in der Systemgruppendatei (meist /etc/group) hinzufügen, damit sie als Teil der Gruppe angesehen werden. Dann erkennt Samba die Benutzer als gültige Benutzer für diese Freigabe.

Außerdem müssen Sie ein freigegebenes Verzeichnis erstellen, auf das die Mitglieder dieser Gruppe zugreifen dürfen. Die Option path verweist auf dieses Verzeichnis. Die folgenden Unix-Befehle erstellen das freizugebende Verzeichnis für die Buchhaltungsabteilung (unter der Voraussetzung, dass /home/samba bereits besteht):

In dieser Beispieldatei smb.conf finden Sie zwei weitere Optionen, die wir im vorigen Kapitel besprochen haben, nämlich create mode und directory mode. Diese Optionen legen die maximal möglichen Berechtigungen für neue Dateien und Verzeichnisse fest. In unserem Beispiel haben wir dem Rest der Welt den Zugriff auf den Inhalt dieser Freigabe vollständig verwehrt (dies wird, wie bereits gezeigt, durch den Befehl chmod erzwungen).

Mehrere Einzelbenutzer einrichten

Lassen Sie uns für einen Augenblick zu den Benutzerfreigaben zurückkehren. Wenn Sie für mehrere Benutzer Home-Verzeichnis-Freigaben einrichten wollen, sollten Sie die besondere Freigabe [homes] einsetzen, die wir in Kapitel 8 eingeführt haben. Mit der Freigabe [homes] müssen Sie nur noch Folgendes festlegen:

Die Freigabe [homes] ist ein spezieller Abschnitt der Samba-Konfigurationsdatei. Wenn ein Benutzer auf eine gewöhnliche Freigabe zugreifen will, die nicht in der Datei smb.conf steht (zum Beispiel über die direkte Eingabe eines UNC-Namens im Windows-Explorer), sucht Samba zunächst nach dem Abschnitt [homes]. Existiert er, wird der vom Client gewünschte Freigabename als Benutzername angesehen, und Samba sucht ihn in der Unix-Kennwortdatenbank (in der Regel /etc/passwd) des Samba-Servers. Wenn er dort erscheint, nimmt Samba an, dass ein Unix-Benutzer eine Verbindung zu seinem Home-Verzeichnis herstellen will.

Lassen Sie uns zum besseren Verständnis annehmen, dass sofia versucht, die Freigabe [sofia] auf dem Samba-Server zu verwenden, und dass eine solche Freigabe nicht in der Konfigurationsdatei existiert. Da aber dort der Abschnitt [homes] existiert und sofia in die Kennwortdatenbank eingetragen ist, geht Samba wie folgt vor:

Der Abschnitt [homes] bietet eine schnelle und problemlose Möglichkeit, Freigaben für Ihre Benutzer zu erstellen, ohne dass Sie Angaben aus der Kennwortdatei abtippen müssten. Über diesen Abschnitt erstellte Freigaben besitzen einige Besonderheiten, die wir nicht unerwähnt lassen dürfen:

Wie bereits erwähnt, müssen Sie im Abschnitt [homes] keinen Pfad angeben, wenn die Benutzer Unix-Home-Verzeichnisse besitzen, die in der Kennwortdatei /etc/passwd des Servers stehen. Vergewissern Sie sich, dass die dort aufgeführten Benutzer auch wirklich existieren, weil Samba sie nicht automatisch erstellt. Stattdessen verweigert Samba einem Benutzer den Zugriff, wenn es das Home-Verzeichnis eines Benutzers nicht findet oder nicht darauf zugreifen kann.

Zugriff auf Freigaben steuern

Sie werden aus Sicherheitsgründen häufig festlegen müssen, welche Benutzer auf eine bestimmte Freigabe zugreifen dürfen. Diese Aufgabe können Sie mit Samba ganz leicht erledigen, da die Software zahlreiche Optionen besitzt, mit denen Sie praktisch jede denkbare Sicherheitskonfiguration in die Tat umsetzen können. Betrachten wir einige verbreitete Konfigurationen, die für Sie möglicherweise in Frage kommen.

Sie haben gesehen, was geschieht, wenn Sie gültige Benutzer angeben. Sie können außerdem eine Liste mit ungültigen Benutzern erstellen - mit Benutzern, denen Samba den Zugriff auf seine Freigaben verweigern soll. Verwenden Sie dazu die Option invalid users. Wir haben schon an früherer Stelle auf eine weit verbreitete Einsatzmöglichkeit hingewiesen: den Eintrag dieser Option für diverse Systembenutzer sowie für den Superuser im Abschnitt [homes], um Missbrauch zu verhindern, wie das folgende Beispiel zeigt:

Die Option invalid users akzeptiert - genau wie valid users - Gruppennamen, denen ein at-Zeichen (@) vorangestellt ist, und Benutzernamen. Falls ein Benutzer oder eine Gruppe in beiden Listen vorkommt, hat die Option invalid users Vorrang, und dem Benutzer oder der Gruppe wird der Zugang zur Freigabe verweigert.

Am anderen Ende des Spektrums können Sie ausdrücklich Benutzer aufführen, denen Samba den Superuser-(root-)Zugriff auf eine Freigabe gestattet. Dazu verwenden Sie die Option admin users. Hier ein Beispiel:

Diese Option akzeptiert sowohl Benutzer- als auch Gruppennamen. Außerdem können Sie NIS-Netzgruppen angeben, wenn Sie ihren Namen ein @-Zeichen voranstellen. Wenn Samba die Netzgruppe nicht findet, geht es davon aus, dass Sie eine Unix-Benutzergruppe meinen.

Seien Sie vorsichtig, wenn Sie einer ganzen Gruppe administrative Berechtigungen für eine Freigabe erteilen. Das Samba-Team rät dringend davon ab, diese Option einzusetzen, da sie den angegebenen Benutzern und Gruppen den root-Zugriff gewährt.

Wenn Sie Benutzern einer Freigabe einen schreibgeschützten oder einen Schreib-/Lesezugriff gewähren wollen, können Sie dazu die Option read list bzw. write list verwenden. Diese Optionen können auf Freigabeebene dazu verwendet werden, bestimmten Benutzern den Schreibzugriff zu entziehen oder bestimmten Benutzern sowohl Schreib- als auch Lesezugriff zu gewähren, obwohl die Freigabe eigentlich schreibgeschützt ist. Ein Beispiel:

Die Option write list besitzt keinen Vorrang vor Unix-Berechtigungen. Wenn Sie die Freigabe erstellt haben, ohne dass ein Benutzer über die Schreibberechtigung des Betriebssystems verfügt, kann diesem Benutzer auch über die Option write-list keine Schreibberechtigung erteilt werden.

Gastzugriff

Wie wir bereits erwähnt haben, können Sie eine Freigabe mit guest ok = yes so konfigurieren, dass Gastbenutzern der Zugriff gestattet ist. Das funktioniert nur, wenn Sie Sicherheit auf Freigabeebene einsetzen. Auf diese Funktion werden wir später genauer eingehen. Wenn ein Benutzer sich als Gast anmeldet, ist es nicht nötig, sich mit Benutzername und Kennwort zu authentifizieren. Samba braucht dennoch eine Möglichkeit, um den angemeldeten Client mit einem Benutzer im lokalen System zu verknüpfen. Der Parameter guest account kann in der Freigabe eingesetzt werden, um den Unix-Benutzerzugang anzugeben, der Gastbenutzern zugewiesen werden soll, wenn sie sich am Samba-Server anmelden. Die Voreinstellung wird während der Kompilierung festgelegt und ist üblicherweise nobody. Bei den meisten Unix-Versionen funktioniert das ganz gut. Auf einigen Systemen ist es jedoch dem Zugang nobody nicht erlaubt, auf bestimmte Dienste (z.B. das Drucken) zuzugreifen, und Sie müssen für den Gastbenutzer ftp oder einen anderen Zugang festlegen.

Wenn Sie ausschließlich Gäste auf eine Freigabe zugreifen lassen wollen, so dass alle Clients Gastberechtigungen erhalten, können Sie die Option guest only in Verbindung mit der Option guest ok verwenden, wie im folgenden Beispiel geschehen:

Achten Sie darauf, dass Sie den Wert yes sowohl für guest only als auch für guest ok festlegen, da Samba ansonsten nicht wie gewünscht den Gastzugang benutzt.

Optionen zur Zugriffssteuerung

Tabelle 9-1 fasst die Optionen zusammen, mit denen Sie den Zugriff auf Freigaben steuern können.

Tabelle 9-1

Optionen zur Zugriffssteuerung auf Freigabeebene
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
admin users	String (Liste mit Benutzernamen)	Benutzer, die Aktionen als root ausführen dürfen.	keiner	Freigabe
valid users	String (Liste mit Benutzernamen)	Benutzer, die sich an einer Freigabe anmelden dürfen.	keiner	Freigabe
invalid users	String (Liste mit Benutzernamen)	Benutzer, denen der Zugriff auf eine Freigabe verweigert wird.	keiner	Freigabe
read list	String (Liste mit Benutzernamen)	Benutzer, die nur Lesezugriff auf eine schreibbare Freigabe haben.	keiner	Freigabe
write list	String (Liste mit Benutzernamen)	Benutzer, die Lese-/Schreibzugriff auf eine schreibgeschützte Freigabe haben.	keiner	Freigabe
max connections	numerischer Wert	Maximal mögliche Anzahl von Verbindungen zu einer Freigabe zu einem bestimmten Zeitpunkt.	0	Freigabe
guest only (only guest)	Boolescher Wert	Wenn yes, wird nur Gastzugriff erlaubt.	no	Freigabe
guest account	String (Name des Benutzerzugangs)	Unix-Benutzerzugang, der für den Gastzugriff verwendet wird.	nobody	Freigabe

admin users

Mit Hilfe dieser Option können Benutzer definiert werden, die so mit Dateien und Verzeichnissen arbeiten können, als wären sie root. Das bedeutet, dass sie die Dateien anderer Benutzer verändern oder löschen können, und zwar unabhängig von den Datei- und Verzeichnisberechtigungen. Wenn Benutzer, die mit dieser Option angegeben sind, Dateien erstellen, gehören diese root sowie der vorgegebenen Gruppe des Administrators. Sie können mit der Option admin users PC-Benutzer zu Administratoren für bestimmte Freigaben machen. Sie sollten jedoch aufpassen, wenn Sie diese Option verwenden, und sicherstellen, dass es gute Kennwörter und andere Sicherheitsrichtlinien gibt.

valid users, invalid users

Mit diesen beiden Optionen nennen Sie die Benutzer und Gruppen, denen Samba den Zugriff auf eine bestimmte Freigabe erlauben oder verbieten soll. Sie können eine Liste mit Benutzer- und/oder Gruppennamen angeben. Ist einem Namen ein at-Zeichen (@) vorangestellt, wird er als Gruppenname interpretiert - dabei werden NIS-Gruppen vor Unix-Gruppen gesucht. Steht vor dem Namen ein Pluszeichen (+), wird er als Name einer Unix-Gruppe angesehen. Das NIS wird dann nicht durchsucht. Beginnt der Name mit einem Ampersand-Zeichen (&), wird er als NIS-Gruppenname und nicht als Unix-Gruppenname betrachtet. Plus- und Ampersand-Zeichen können zusammen eingesetzt werden, um festzulegen, ob NIS- oder Unix-Gruppen zuerst gesucht werden. Ein Beispiel:

Im Parameter valid users wird den Benutzern mary, ellen und sue ebenso der Zugriff auf die [database]-Freigabe gewährt wie den Mitgliedern der Unix-Gruppe marketing sowie den der NIS/Unix-Gruppe dbadmin. Der Parameter invalid users verbietet den Zugriff auf die Freigabe durch die Benutzer gavin, syd und dana und für die Mitglieder der NIS-Gruppe techies sowie der Unix/NIS-Gruppe helpdesk. Im letzten Fall wird die Liste der Unix-Gruppen zuerst nach der Gruppe helpdesk durchsucht. Ist die Gruppe dort nicht zu finden, wird in der Liste der NIS-Gruppen gesucht.

Eine wichtige Regel im Zusammenhang mit diesen Optionen ist, dass allen Namen oder Gruppen, die in der invalid users-Liste auftauchen, immer der Zugriff verwehrt wird, auch wenn sie (in welcher Form auch immer) in der valid users-Liste stehen.

read list, write list

Ebenso wie die Optionen valid users und invalid users legt dieses Optionenpaar fest, welche Benutzer nur Lesezugriff auf eine schreibbare Freigabe bzw. welche Benutzer Lese-/Schreibzugriff auf eine schreibgeschützte Freigabe erhalten. Der Wert beider Optionen ist eine Liste mit Benutzern. Der Parameter read list setzt die anderen gewährten Samba-Berechtigungen außer Kraft - ebenso wie die Unix-Dateiberechtigungen auf dem Server-System -, um den Benutzern den Schreibzugriff zu verbieten. Der Parameter write list setzt die anderen Samba-Berechtigungen außer Kraft, um Schreibzugriff zu gewähren, erlaubt allerdings keinen Schreibzugriff, wenn dem Benutzer die entsprechenden Berechtigungen für die Datei auf dem Unix-System fehlen. Sie können NIS- oder Unix-Gruppennamen festlegen, indem Sie dem Namen ein at-Zeichen voranstellen (z.B. @users). Keine dieser beiden Konfigurationsoptionen besitzt einen Standardwert.

max connections

Diese Option legt die maximale Anzahl gleichzeitig möglicher Client-Verbindungen für diese Freigabe fest. Wenn die Anzahl erreicht ist, verweigert Samba weitere Verbindungen. Der Vorgabewert ist 0, die Anzahl gleichzeitiger Verbindungen ist damit unbegrenzt. Sie können den Wert auf Freigabeebene folgendermaßen verändern:

Diese Option ist nützlich, falls Sie die Anzahl der Benutzer einschränken wollen, die gleichzeitig ein lizenziertes Programm oder eine lizenzierte Datenbank aufrufen möchten.

guest only

Diese Option (mit der alternativen Schreibweise only guest) legt fest, dass eine Verbindung zu einer Freigabe unter der Benutzerkennung ausgeführt wird, die durch die Option guest account angegeben wurde. Die Freigabe, bei der Sie diese Option verwenden, muss außerdem die Option guest ok = yes erhalten haben, damit Samba sie beachtet. Die Voreinstellung ist no.

guest account

Diese Option gibt den Namen des Zugangs an, der für Gastzugriffe auf Freigaben in Samba verwendet wird. Die Voreinstellung für diese Option ist von System zu System unterschiedlich. Häufig wird nobody benutzt. Manche Standardbenutzerzugänge haben Schwierigkeiten damit, sich als Gastbenutzer anzumelden. Falls das auf Ihrem System der Fall ist, empfiehlt das Samba-Team die Benutzung des ftp-Zugangs als Gastbenutzer.

Optionen für Benutzernamen

Tabelle 9-2 zeigt zwei weitere Optionen, die Samba verwenden kann, um Inkompatibilitäten bei den Benutzernamen zwischen Windows und Unix auszugleichen.

Tabelle 9-2

Optionen für Benutzernamen
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
username map	String (Dateiname)	Legt den Namen der Zuordnungsdatei für Benutzernamen fest.	keiner	global
username level	numerischer Wert	Gibt die Anzahl der Großbuchstaben an, die verwendet werden, wenn ein Vergleich von Benutzernamen erfolgt.	0	global

username map

Client-Benutzernamen in einem SMB-Netzwerk können relativ lang sein (bis zu 255 Zeichen), während Benutzernamen in einem Unix-Netzwerk häufig maximal acht Zeichen haben dürfen. Das führt dazu, dass Benutzer nicht nur einen Benutzernamen auf ihrem Client verwenden, sondern auch auf dem Samba-Server einen weiteren (kürzeren) Benutzernamen in Gebrauch haben. Sie können dieses Problem lösen, indem Sie eine Zuordnungsliste anlegen, in der jeder Client-Benutzername neben einem Unix-Benutzernamen steht, der aus höchstens acht Zeichen bestehen darf. Die Liste steht in einer gewöhnlichen Textdatei, deren Format wir in Kürze beschreiben. Geben Sie den Namen der Datei mit der globalen Option username map an. Stellen Sie sicher, dass Sie den Zugriff auf diese Datei einschränken; machen Sie root zum Besitzer und entziehen Sie allen anderen den Schreibzugriff (mit den oktalen Berechtigungen 744 oder 644). Ansonsten könnte ein nicht vertrauenswürdiger Benutzer auf die Datei zugreifen und seinen SMB-Benutzernamen dem root-Benutzer des Samba-Servers zuordnen.

Alle Einträge in der Benutzernamen-Zuordnungsdatei müssen so aussehen: zunächst der Unix-Benutzername, gefolgt von einem Gleichheitszeichen (=) und von einem oder mehreren SMB-Client-Benutzernamen, jeweils getrennt durch mindestens ein Leerzeichen. Solange Samba nichts anderes mitgeteilt wird (dass etwa eine Gastverbindung bestehen soll), erwartet es, dass sowohl der Client-Benutzer als auch der Server-Benutzer das gleiche Kennwort haben. Sie können auch Windows NT-Gruppen einer oder mehreren Unix-Gruppen zuordnen, indem Sie das @-Zeichen verwenden. Hier einige Beispiele

Zeilen in der Datei, die mit einem Hash-Zeichen (#) oder einem Semikolon (;) beginnen, werden als Kommentare betrachtet.

Beachten Sie, dass Sie diese Datei auch verwenden können, um einen Unix-Benutzer einem anderen Benutzer zuzuordnen. Seien Sie damit aber vorsichtig, denn weder Samba noch der Client benachrichtigt den Benutzer über die vorgenommene Zuordnung, und Samba erwartet möglicherweise ein anderes Kennwort.

username level

SMB-Clients (wie Windows) senden Benutzernamen in SMB-Verbindungsanfragen häufig in Großbuchstaben. Mit anderen Worten, bei Client-Benutzernamen wird die Groß-/ Kleinschreibung nicht notwendigerweise beachtet. Hingegen ist die Groß-/Kleinschreibung von Benutzernamen auf Unix-Systemen durchaus von Bedeutung: Der Benutzer ANDY unterscheidet sich vom Benutzer andy. Standardmäßig versucht Samba, dieses Problem folgendermaßen zu lösen:

Wenn Sie wollen, dass Samba weitere Kombinationen aus Groß- und Kleinbuchstaben durchspielt, können Sie ihm das über die globale Option username level mitteilen. Diese Option gibt an, wie viele Buchstaben im Benutzernamen mit Großbuchstaben probiert werden sollen, wenn ein Client eine Verbindung zum Samba-Server herstellen will. Verwenden Sie diese Option wie folgt:

In diesem Fall probiert Samba alle Variationen von Benutzernamen, die drei Großbuchstaben enthalten. Je größer die Zahl ist, desto mehr Versuche unternimmt Samba und desto länger dauert die Authentifizierung.

Authentifizierung von Clients

An dieser Stelle sollten wir uns damit befassen, wie Samba Benutzer authentifiziert. Jeder Benutzer, der eine Freigabe ohne aktivierten Gastzugriff verwenden will, muss dem Samba-Server einen Benutzernamen und ein Kennwort liefern, um die gewünschte Verbindung erfolgreich herzustellen. Was Samba mit dem Kennwort macht und wie Samba dementsprechend die Echtheit des Benutzers überprüft, hängt von der Konfigurationsoption security ab. Momentan unterstützt Samba vier Sicherheitsstufen in seinem Netzwerk: share, user, server und domain.

Samba wird zum Mitglied einer Windows NT-Domäne und greift auf einen der Domänen-Controller der Domäne - entweder auf den PDC oder einen BDC - zu, um die Authentifizierung durchzuführen. Nach der Authentifizierung erhält der Benutzer ein besonderes Token, das ihm erlaubt, auf beliebige Freigaben mit den entsprechenden Zugriffsrechten zuzugreifen. Dank dieses Tokens muss der Domänen-Controller nicht jedes Mal erneut das Kennwort des Benutzers überprüfen, wenn dieser versucht, auf eine andere Freigabe in der Domäne zuzugreifen. Bei dem Domänen-Controller kann es sich um einen Windows NT/2000-PDC oder -BDC oder um Samba handeln, das als Windows NT-PDC agiert.

Jedes Sicherheitsverfahren kann mit der globalen Option security umgesetzt werden, wie in Tabelle 9-3 gezeigt wird.

Tabelle 9-3

Sicherheitsoption
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
security	domain, server, share oder user	Gibt die Art der Sicherheit an, die der Samba-Server umsetzt.	user	global

Sicherheit auf Freigabeebene

Bei der Sicherheit auf Freigabeebene besitzt jede Freigabe mindestens ein Kennwort, der Client wird beim ersten Anmelden an der Freigabe authentifiziert. Der Unterschied zu den anderen Methoden besteht darin, dass es keine Einschränkung dazu gibt, wer die Freigabe verwendet - solange der betreffenden Person eines der Kennwörter bekannt ist. Freigaben besitzen oft mehrere Kennwörter. So kann beispielsweise eines der Kennwörter den schreibgeschützten Zugriff erlauben, während ein anderes den Schreib-/Lesezugriff gewährt. Die Sicherheit ist gewährleistet, solange kein unbefugter Benutzer das Kennwort für eine Freigabe herausfindet, auf die er nicht zugreifen sollte.

Sowohl OS/2 als auch Windows 95/98/Me unterstützen Sicherheit auf Freigabeebene auf ihren Ressourcen. Sie können diesen Sicherheitsmechanismus unter Windows 95/98/Me aktivieren, indem Sie in der Systemsteuerung unter Netzwerk die Registerkarte Zugriffssteuerung aufrufen. Wählen Sie dort den Radio-Button Zugriffssteuerung auf Freigabeebene (wodurch der Radio-Button Zugriffssteuerung auf Benutzerebene deaktiviert wird), wie in Abbildung 9-1 demonstriert wird. Klicken Sie anschließend auf OK und starten Sie den Rechner neu, wenn das gefordert wird.

Abbildung 9-1

Aktivierung der Sicherheit auf Freigabeebene unter Windows 95/98/Me

Klicken Sie nun mit der rechten Maustaste auf eine Ressource (also ein Verzeichnis einer Festplatte oder eines CD-Laufwerks) und wählen Sie aus dem erscheinenden Kontextmenü den Punkt Eigenschaften aus. Wählen Sie im sich öffnenden Dialog die Registerkarte Freigabe und aktivieren Sie die Ressource als Freigegeben als. An dieser Stelle können Sie den Freigabenamen wählen und einstellen, ob die Freigabe abhängig vom Kennwort, das der Client liefert, schreibgeschützt ist oder ob der Schreib-/Lesezugriff erlaubt sein soll.

Vielleicht denken Sie, dass dieses Sicherheitsmodell nicht gut zu Samba passt - da haben Sie recht. Selbst wenn Sie die globale Option security = share in der Samba-Konfigurationsdatei angeben, verwendet Samba Kombinationen aus Benutzernamen und Kennwort in den Systemkennwortdateien, um den Zugriff festzulegen. Genauer gesagt, geht Samba folgendermaßen vor, wenn ein Client eine Verbindung zur einer Freigabe herstellen will und die Sicherheit auf Freigabeebene aktiv ist:

3. Bei anderen Freigaben hängt Samba den Benutzernamen an eine Liste mit Benutzern an, denen der Zugriff auf die Freigabe gestattet ist. Anschließend versucht es, das Kennwort im Zusammenhang mit diesem Benutzernamen auf seine Gültigkeit zu prüfen. Ist das erfolgreich, erlaubt Samba dem Benutzer den Zugriff auf die Ressource mit den Rechten, die diesem Benutzer zugewiesen sind. Der Benutzer muss sich nicht noch einmal authentifizieren, es sei denn, in der Freigabe wurde die Option revalidate = yes angegeben.

4. Verläuft die Authentifizierung erfolglos, versucht Samba, das Kennwort anhand einer Liste von Benutzern zu überprüfen, die sich bereits einmal angemeldet hatten, sowie anhand solcher Benutzer, die unter dieser Freigabe in der Konfigurationsdatei angegeben sind. Passt das Kennwort zu einem dieser Benutzernamen (wie in der Systemkennwortdatei, üblicherweise /etc/passwd , festgelegt), wird dem Benutzer der Zugriff auf die Freigabe unter diesem Benutzernamen gestattet.

Sie können in der Konfigurationsdatei festlegen, welche Benutzer Samba anfänglich auf die Benutzerliste für Sicherheit auf Freigabeebene setzen soll. Dazu verwenden Sie die Option username, wie hier gezeigt:

Wenn in diesem Fall ein Benutzer auf die Freigabe zugreifen will, überprüft Samba, ob das gelieferte Kennwort zu einem der Benutzer gehört, die in einer internen Liste stehen, oder zu einem der Benutzer davecb, pkelly und andyo. Wenn das Kennwort einem der Benutzer gehört, überprüft Samba die Verbindung und gewährt dem Benutzer den Zugriff. Ansonsten schlägt der Versuch eines Verbindungsaufbaus fehl.

Optionen für Sicherheit auf Freigabeebene

Tabelle 9-4 zeigt die Optionen, die üblicherweise im Zusammenhang mit Sicherheit auf Freigabeebene auftauchen.

Tabelle 9-4

Optionen für Sicherheit auf Freigabeebene
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
only user	Boolescher Wert	Wenn yes, werden nur solche Benutzernamen erlaubt, die durch username angegeben wurden.	no	Freigabe
username (user oder users)	String (Liste mit Benutzernamen)	Benutzer, mit denen das Kennwort eines Clients überprüft wird.	keiner	Freigabe

only user

Wenn diese Boolesche Option eingeschaltet ist, prüft Samba bei eingehenden Verbindungen zu einer Freigabe mit einer Sicherheit auf Freigabeebene lediglich, ob das vom Client gelieferte Kennwort zu einem der Benutzer gehört, die Sie im Wert der Option username angegeben haben. Die Prüfung, ob das Kennwort zu einem Benutzer aus der internen Liste der Benutzer gehört, entfällt. Der Vorgabewert dieser Option ist no. Sie können den Wert folgendermaßen ändern:

username

Diese Option gibt eine Liste mit Benutzernamen und/oder Gruppennamen an, die für die Prüfung des vom Client gelieferten Kennworts herangezogen werden. Diese Option wird häufig bei Clients eingesetzt, die Sicherheit auf Freigabeebene verwenden, damit erfolgreiche Verbindungen zu einem bestimmten Dienst ausschließlich vom Kennwort abhängen - in diesem Fall einem Kennwort, das einem bestimmten Benutzer gehört:

Sie können eine Liste mit Benutzernamen und/oder Gruppennamen eingeben. Ist einem Namen ein at-Zeichen (@) vorangestellt, wird er als Gruppenname interpretiert, wobei NIS-Gruppen vor Unix-Gruppen durchsucht werden. Steht vor dem Namen ein Pluszeichen (+), wird er als Name einer Unix-Gruppe angesehen; das NIS wird nicht durchsucht. Ist dem Namen ein Ampersand-Zeichen (&) vorangestellt, wird er als NIS-Gruppenname und nicht als Unix-Gruppenname betrachtet. Plus- und Ampersand-Zeichen können zusammen eingesetzt werden, um festzulegen, ob NIS- oder Unix-Gruppen zuerst durchsucht werden sollen. Wenn Samba in dieser Option einen Gruppennamen entdeckt, versucht es, alle Benutzer in der Gruppe zu authentifizieren, bis es bei einem Benutzer erfolgreich ist. Bedenken Sie, dass dies allerdings sehr ineffizient sein kann.

Wir empfehlen Ihnen, diese Option nicht zu verwenden, es sei denn, Sie implementieren einen Samba-Server mit Sicherheit auf Freigabeebene.

Sicherheit auf Benutzerebene

Die bevorzugte Methode der Sicherheit bei Samba ist die Sicherheit auf Benutzerebene. Bei diesem Verfahren geben Sie für jede Freigabe an, welche Benutzer diese verwenden dürfen. Wenn ein Benutzer auf eine Freigabe zugreifen will, prüft Samba, ob der vom Client gelieferte Benutzername auf dem System existiert und ob sein Kennwort stimmt. Dazu verwendet Samba seine eigene Kennwortdatenbank. Wie wir bereits an früherer Stelle in diesem Kapitel erwähnt haben, können Sie mit der Option valid users angeben, welche Benutzer auf eine bestimmte Freigabe zugreifen dürfen:

Jeder der aufgeführten Benutzer kann sich mit der Freigabe verbinden, sofern der Client das korrekte Kennwort liefert, so wie es in der Systemkennwortdatei des Servers steht. Wenn Samba die Echtheit des Benutzers auf diese Weise einmal bestätigt hat, muss der Benutzer sein Kennwort nicht erneut eingeben, solange Sie nicht die Option revalidate = yes eingetragen haben.

Clients können Kennwörter unverschlüsselt oder verschlüsselt an den Samba-Server senden. Wenn Sie beide Arten von Clients in Ihrem Netzwerk besitzen, sollten Sie sich vergewissern, dass die Kennwörter der Benutzer sowohl in der traditionellen Unix-Zugangsdatenbank als auch in der verschlüsselten Samba-Datenbank stehen. Auf diese Weise können Benutzer von jedem Client-Typ aus auf ihre Freigaben zugreifen.¹ Allerdings empfehlen wir Ihnen, ausschließlich verschlüsselte Kennwörter zu verwenden und unverschlüsselte abzulehnen, wenn Ihnen die Sicherheit am Herzen liegt. Mehr über dieses Thema erfahren Sie im Abschnitt »Kennwörter« in diesem Kapitel.

Sicherheit auf Server-Ebene

Sicherheit auf Server-Ebene ähnelt derjenigen auf Benutzerebene. Auf der Server-Ebene greift Samba für die Authentifizierung auf einen anderen SMB-Kennwort-Server zurück. Typischerweise handelt es sich dabei um einen anderen Samba-Server oder einen Windows NT/2000-Server, der als PDC im Netzwerk fungiert. Beachten Sie, dass Samba auch bei dieser Konfiguration eine Liste der Freigaben einschließlich ihrer jeweiligen Einstellungen in der Datei smb.conf benötigt. Wenn ein Client sich mit einer bestimmten Freigabe verbinden will, überprüft Samba zunächst, ob der Benutzer überhaupt auf diese Freigabe zugreifen darf. Ist das der Fall, überprüft der Samba-Server das Kennwort, indem es dem SMB-Kennwort-Server den Benutzernamen und das vom Client gelieferte Kennwort sendet. Ist das Kennwort akzeptiert worden, wird mit dem Client eine Verbindung aufgebaut. Eine Veranschaulichung dieses Vorgangs finden Sie in Abbildung 9-2.

Abbildung 9-2

Ein typisches System, das Sicherheit auf Server-Ebene einsetzt

Sie können Samba so konfigurieren, dass es einen separaten Kennwort-Server mit Sicherheit auf Server-Ebene verwendet. Dazu benutzen Sie die globale Option password server:

Beachten Sie, dass Sie im Wert der Option password server mehr als einen Computer angeben können; Samba greift dann auf den jeweils nächsten Server zurück, falls einer nicht erreichbar sein sollte. Geben Sie in der Option password server die NetBIOS-Namen der Computer, nicht ihre DNS-Namen oder äquivalenten IP-Adressen an. Weist einer der Server ein angegebenes Kennwort ab, schlägt die Verbindung automatisch fehl - Samba fragt keinen weiteren Server.

Eine Warnung: Wenn Sie diese Option verwenden, benötigen Sie einen Benutzerzugang, der den Benutzer des regulären Samba-Servers darstellt. Das liegt daran, dass das Unix einen Benutzernamen benötigt, um diverse Ein-/Ausgabevorgänge durchzuführen. Die bevorzugte Methode zur Lösung dieses Problems besteht darin, dem Benutzer einen Zugang auf dem Samba-Server zu geben und diesen zu sperren, indem man sein Kennwort in der Kennwortdatei (zum Beispiel /etc/passwd ) durch ein Sternchen (*) ersetzt.

Sicherheit auf Domänen-Ebene

Bei Sicherheit auf Domänen-Ebene agiert der Samba-Server als Mitglied einer Windows-Domäne. Erinnern Sie sich an Kapitel 1: Wir hatten gesagt, dass jede Domäne einen primären Domänen-Controller besitzt, bei dem es sich um einen Windows NT/2000- oder Samba-Server handeln kann, der eine Kennwort-Authentifizierung anbietet. Der Domänen-Controller überwacht die Benutzer und Kennwörter in seiner eigenen Datenbank und authentifiziert jeden Benutzer, wenn er sich anmeldet und auf die Freigaben einer anderen Maschine zugreifen will.

Wie bereits weiter oben in diesem Kapitel erwähnt, besitzt Samba eine ähnliche Fähigkeit, die Sicherheit auf Benutzerebene anbietet. Allerdings ist diese Option Unix-zentriert und geht davon aus, dass die Authentifizierung über Unix-Kennwortdateien erfolgt. Ist die Unix-Maschine Teil einer NIS- oder NIS+-Domain, authentifiziert Samba die Benutzer in typischer Unix-Manier transparent über eine gemeinsam genutzte Kennwortdatei. Samba stellt dann den Zugriff auf die NIS- oder NIS+-Domain von Windows aus bereit. Es gibt natürlich keinen Zusammenhang zwischen dem NIS-Konzept einer Domain und einer Windows NT-Domäne.

Das Konfigurieren von Samba für Sicherheit auf Domänen-Ebene wird in Kapitel 4 im Abschnitt »Samba als Domänen-Member-Server« besprochen.

Kennwörter

Kennwörter sind ein Sorgenkind von Samba. Sie sind fast immer das erste große Problem, auf das Benutzer stoßen, wenn sie Samba installieren. Daher wollen wir uns jetzt um dieses Thema kümmern und herausfinden, was im Netzwerk geschieht.

Clients können Kennwörter unverschlüsselt oder verschlüsselt senden. Verschlüsselte Kennwörter sind natürlich sicherer. Ein Klartext-Kennwort kann von einem Paketschnüffler gelesen werden, wie von dem für Samba veränderten tcpdump-Programm, das wir in Kapitel 1 verwendet haben. Ob Kennwörter standardmäßig verschlüsselt werden, hängt vom Betriebssystem ab, das der Client benutzt, um sich am Samba-Server anzumelden. In Tabelle 9-5 steht, welche Windows-Betriebssysteme ihre Kennwörter standardmäßig verschlüsseln und welche sie im Klartext über das Netzwerk schicken.

Tabelle 9-5

Windows-Betriebssysteme mit verschlüsselten Kennwörtern
Betriebssystem	Verschlüsselt oder Klartext
Windows for Workgroups	Klartext
Windows 95	Klartext
Windows 95 mit SMB-Update	Verschlüsselt
Windows 98	Verschlüsselt
Windows Me	Verschlüsselt
Windows NT 3.x	Klartext
Windows NT 4.0 vor SP 3	Klartext
Windows NT 4.0 nach SP 3	Verschlüsselt
Windows 2000	Verschlüsselt
Windows XP	Verschlüsselt

Es werden drei unterschiedliche Verschlüsselungsmethoden verwendet. Windows 95/98/Me-Clients benutzen eine Methode, die Microsofts LAN Manager-Netzwerk-Software übernimmt. Windows NT/2000/XP-Systeme setzen ein neueres System namens NT LAN Manager oder NTLM ein. Eine aktuellere Version dieser Methode (namens NT LAN Manager Version 2 oder NTLMv2) verwendet eine andere Methode für die Ermittlung von Kennwort-Hash-Werten.

Wenn verschlüsselte Kennwörter unterstützt werden, speichert Samba die verschlüsselten Kennwörter in einer Datei mit dem Namen smbpasswd. Standardmäßig befindet sich diese Datei im Verzeichnis private der Samba-Distribution (üblicherweise /usr/local/samba/ private). Gleichzeitig speichert der Client eine verschlüsselte Version des Kennworts eines Benutzers auf seinem eigenen System. Das Klartext-Kennwort wird niemals gespeichert, weder auf einem Server noch auf dem Client. Jedes System verschlüsselt das Kennwort automatisch mit einem Standard-Algorithmus, wenn es gesetzt oder verändert wird.

Möchte ein Client eine Verbindung zu einem SMB-Server aufbauen, der verschlüsselte Kennwörter unterstützt (wie Samba oder Windows NT/2000/XP), führen die beiden Computer folgende Verhandlungen durch:

Beachten Sie, dass die unverschlüsselten Kennwörter dabei nicht über das Netzwerk gesendet werden. Dennoch sollten Sie sehr vorsichtig mit den verschlüsselten Kennwörtern in der Datei smbpasswd umgehen, damit sie unbefugten Benutzern nicht zugänglich sind. Falls ein Benutzer an die verschlüsselten Kennwörter herankommen sollte, kann er in das System einbrechen, indem er die Schritte des eben beschriebenen Algorithmus reproduziert. Die verschlüsselten Kennwörter sind genauso sensibel wie die unverschlüsselten - in der Welt der Kryptographie spricht man von Klartext-äquivalenten Daten. Natürlich sollten Sie auch sicherstellen, dass die Clients ihre Klartext-Kennwörter sichern.

Sie können nun Samba für die Verwendung verschlüsselter Kennwörter konfigurieren, indem Sie dem globalen Abschnitt der Datei smb.conf folgende Zeilen hinzufügen. Beachten Sie, dass wir den Namen der Samba-Kennwortdatei ausdrücklich angeben:

Samba akzeptiert jedoch Benutzer erst, wenn die Datei smbpasswd erzeugt und die Benutzer mit dem Befehl smbpasswd hinzugefügt wurden, wie wir Ihnen in Kapitel 2 gezeigt haben.

Verschlüsselte Kennwörter auf dem Client deaktivieren

Die Unix-Authentifizierung ist seit Jahrzehnten üblich - einschließlich der Verwendung von telnet und rlogin über das Internet -, obwohl sie allgemein bekannte Sicherheitsrisiken birgt. Klartext-Kennwörter werden über das Internet verschickt und können von böswilligen Schnüffelprogrammen aus den TCP-Paketen herausgefiltert werden. Falls Sie Ihr Netzwerk aber für sicher halten und die Standard-Authentifizierung über die Unix-Datei /etc/passwd wünschen, müssen Sie unverschlüsselte Kennwörter auf denjenigen Windows-Systemen aktivieren, die normalerweise nur verschlüsselte Kennwörter senden.

Dazu müssen Sie auf allen Client-Systemen die Windows-Registry modifizieren. Die Samba-Distribution enthält die dafür benötigten .reg-Dateien; diese befinden sich im Verzeichnis /docs/Registry der Quelldistribution. Je nach verwendeter Plattform benutzen Sie eine der folgenden Dateien:

(Für Windows XP nehmen Sie die .reg-Datei für Windows 2000.) Sie können die Installation ausführen, indem Sie die entsprechende .reg-Datei auf eine DOS-Diskette kopieren, diese Diskette in das Diskettenlaufwerk des Clients einlegen und über den Befehl Ausführen aus dem Start-Menü die .reg-Datei aufrufen. (Sie können auch einfach auf das Symbol der Datei doppelklicken.)

Nach dem Neustart des Rechners verschlüsselt der Client seine Kennwörter nicht mehr, bevor er sie an den Server sendet. Das bedeutet, dass die Klartext-Kennwörter in den TCP-Paketen zu sehen sind, die über das Netzwerk verschickt werden. Auch hier empfehlen wir Ihnen, dies nicht zu tun, wenn Sie sich nicht völlig darauf verlassen können, dass Ihr Netzwerk sicher ist.

Wenn die Kennwörter nicht verschlüsselt werden sollen, verwenden Sie diese beiden Zeilen in Ihrer Samba-Konfigurationsdatei:

Die smbpasswd-Datei

Samba speichert verschlüsselte Kennwörter in einer Datei mit dem Namen smbpasswd, die sich standardmäßig im Verzeichnis /usr/local/samba/private befindet. Sie sollten die Datei smbpasswd genauso gut bewachen wie die Datei mit den Kennwörtern des Unix-Systems (entweder /etc/passwd oder /etc/shadow). Nur der root-Benutzer darf Lese-/Schreibzugriff auf das Verzeichnis private haben; alle anderen Benutzer sollten überhaupt keinen Zugriff auf dieses Verzeichnis erhalten. Auch der Zugriff auf die Datei smbpasswd sollte allen Benutzern bis auf root verwehrt sein. Ist alles für eine gute Sicherheit eingerichtet, sollten die Listings des Verzeichnisses private und der Datei smbpasswd folgendermaßen aussehen:

Bevor Sie verschlüsselte Kennwörter einsetzen können, müssen Sie für jeden Unix-Benutzer einen Eintrag in der Datei smbpasswd anlegen. Die Struktur der Datei ist dabei ähnlich der einer Unix-passwd-Datei; sie enthält allerdings andere Felder. Abbildung 9-3 verdeutlicht den Aufbau der Datei smbpasswd; der gezeigte Eintrag steht eigentlich in der Datei auf einer einzigen Zeile.

Abbildung 9-3

Struktur des Eintrags in der Datei smbpasswd (eine Zeile)

Normalerweise werden die Einträge in der Datei smbpasswd automatisch vom Befehl smbpasswd erzeugt. Dennoch wollen Sie vielleicht wissen, wie die Daten in smbpasswd zu interpretieren sind, falls Sie wissen wollen, welche Zugänge darin gespeichert sind oder wie Sie die Datei möglicherweise sogar manuell ändern können. Hier eine Zusammenfassung der einzelnen Felder:

Dabei handelt es sich um eine 32 Bit lange hexadezimale Folge, die das Kennwort repräsentiert, das Windows 95/98/Me-Clients verwenden. Es wird ermittelt, indem das Kennwort in zwei Strings von 7 Zeichen Länge aufgeteilt wird. Dabei werden Kleinbuchstaben in Großbuchstaben umgewandelt. Hat das Kennwort weniger als 14 Zeichen, werden die Strings mit Nullen aufgefüllt. Dann wird jeder 7-Zeichen-String in einen 56-Bit-DES-Schlüssel umgewandelt und verwendet, um den feststehenden String KGS!@#$% zu verschlüsseln. Die beiden 64-Bit-Ergebnisse werden verkettet und als Kennwort-Hash gespeichert.

Kennwort-Synchronisierung

Wenn ein Benutzer ein normales Kennwort (entweder in /etc/passwd oder in /etc/shadow) und eine verschlüsselte Version desselben Kennworts (in der Datei smbpasswd) besitzt, kann es zu Problemen kommen, falls er beide ändern muss. Glücklicherweise besitzt Samba eine (wenn auch eingeschränkte) Möglichkeit, die beiden Kennwörter synchron zu halten. Mit einigen Konfigurationsoptionen können Sie festlegen, dass Samba das Unix-Kennwort automatisch ändern soll, wenn das verschlüsselte Kennwort auf dem System geändert wird. Verwenden Sie dazu die globale Option unix password sync:

Ist diese Option aktiviert, versucht Samba (als root), auch das gewöhnliche Kennwort des Benutzers zu ändern, wenn das verschlüsselte Kennwort mit smbpasswd geändert wird. Damit dies funktioniert, müssen Sie aber zwei weitere Optionen entsprechend festlegen.

Die einfachere von beiden ist passwd program. Diese Option gibt einfach den Unix-Befehl an, der zum Ändern des Standard-Systemkennworts eines Benutzers eingesetzt wird. Standardmäßig lautet dieser Befehl /bin/passwd %u. Bei einigen Unix-Systemen ist dies ausreichend. Andere, wie Red Hat Linux, verwenden stattdessen /usr/bin/passwd. Außerdem wollen Sie vielleicht später einmal ein anderes Programm oder Skript benutzen. Nehmen wir zum Beispiel an, dass Sie ein Skript mit dem Namen changepass verwenden wollen, um das Kennwort eines Benutzers zu verändern. Bedenken Sie dabei, dass Sie die Samba-Variable %u für den Unix-Benutzernamen verwenden können. Unser Beispiel ändert sich daher folgendermaßen:

Beachten Sie, dass dieses Programm vom root-Benutzer aufgerufen wird, wenn Sie die Option unix password sync auf yes setzen. Das ist erforderlich, weil Samba nicht unbedingt das alte Klartext-Kennwort des Benutzers kennt.

Die kompliziertere Option ist passwd chat. Sie funktioniert wie ein Chat-Skript unter Unix. Sie enthält eine Folge von Strings, die an das Programm gesendet werden, und Antworten, die vom Programm zu erwarten sind. Diese Strings werden durch passwd program festgelegt. Die Vorgabe für passwd chat sieht beispielsweise folgendermaßen aus (die Trennzeichen zwischen den einzelnen Zeichengruppen sind Leerzeichen):

Die erste Zeichengruppe stellt eine Frage dar, die vom externen Programm zur Kennwortänderung erwartet wird. Beachten Sie, dass sie Platzhalter (*) enthalten kann, mit denen Sie die erwartete Frage verallgemeinern können, so dass das Chat-Skript mit mehreren, ähnlichen Anfragen zurechtkommt. In diesem Beispiel bedeutet *old*password*, dass Samba vom Programm eine Zeile erwartet, in der das Wort old und danach das Wort password vorkommt, unabhängig davon, was vor, zwischen und nach diesen Wörtern steht. Findet Samba die erwartete Zeile nicht, schlägt die Kennwortänderung fehl.

Die zweite Gruppe gibt an, was Samba an das Programm senden soll, sobald es die erste erwartete Zeile gelesen hat. In diesem Fall handelt es sich um %o\n. Die Samba-Variable %o steht für das alte Kennwort, während \n einen Zeilenvorschub repräsentiert. Samba »gibt« also das alte Kennwort »ein«, und zwar über die Standardeingabe des Programms zur Kennwortänderung, und »drückt« dann die Enter-Taste.

Anschließend sehen Sie eine weitere Antwortgruppe, gefolgt von den Daten, die an das Programm zur Kennwortänderung zurückgeschickt werden. (Dieses Abfrage-Antwort-Muster kann in einem normalen Unix-chat-Skript unendlich fortgesetzt werden.) Das Skript läuft weiter, bis das letzte Muster erkannt wurde.

Sie können die in Tabelle 9-6 aufgeführten Zeichen verwenden, um die Chance einer Übereinstimmung des Musters mit der gelieferten Zeile des externen Programms zu erhöhen. Außerdem können Sie die in Tabelle 9-7 aufgelisteten Zeichen benutzen, um Ihre Antwort zu formulieren.

Tabelle 9-6

In einem Kennwort-Chat gelieferte Zeichen
Zeichen	Definition
*	Null oder mehr beliebige Zeichen.
" "	Erlaubt Ihnen, Strings aufzunehmen, die Leerzeichen enthalten. Sternchen werden auch innerhalb von Anführungszeichen als Platzhalter betrachtet. Sie können einen leeren String durch leere Anführungszeichen repräsentieren lassen.

Tabelle 9-7

Zeichen zum Senden in einem Kennwort-Chat
Zeichen	Definition
%o	das alte Kennwort des Benutzers
%n	das neue Kennwort des Benutzers
\n	das Zeilenvorschub-Zeichen
\r	das Wagenrücklauf-Zeichen
\t	das Tabulator-Zeichen
\s	ein Leerzeichen

Beispielsweise könnten Sie an Stelle des Vorgabewerts dieser Option auch die folgende Zeile verwenden. Sie funktioniert in Umgebungen, in denen Sie das alte Kennwort nicht eingeben müssen. Außerdem kommt es damit zurecht, wenn das externe Programm als letzte Zeile all tokens updated successfully sendet, so wie bei Red Hat Linux:

Wir möchten erneut darauf hinweisen, dass der Vorgabewert auf den meisten Unix-Systemen funktioniert. Falls dies nicht auf Ihr Unix-System zutrifft, können Sie die globale Option passwd chat debug verwenden, um ein neues Chat-Skript für das Programm zur Kennwortänderung anzulegen. Die Option passwd chat debug protokolliert während eines Kennwort-Chat-Vorgangs alles. Sie besitzt einen Booleschen Wert:

Wenn Sie diese Option aktivieren, protokolliert Samba alle Ein-/Ausgaben während des Datenaustauschs in der Samba-Protokolldatei log.smbd, und zwar mit der Protokollierungsstufe 100. Deshalb haben wir auch die neue Option log level angegeben. Da diese Vorgehensweise zahlreiche Einträge in der Protokolldatei erzeugen kann, ist es möglicherweise effektiver, statt /bin/passwd ein eigenes Skript zu benutzen - indem die Option passwd program gesetzt wird -, um aufzuzeichnen, was während des Austauschs geschieht. Seien Sie vorsichtig, die Protokolldateien enthalten nämlich die Kennwörter im Klartext. Das kann (oder besser muss) gegen die lokalen Sicherheitsrichtlinien in Ihrer Einrichtung verstoßen und könnte rechtliche Schritte nach sich ziehen. Stellen Sie sicher, dass Sie Ihre Protokolldateien mit strengen Dateiberechtigungen schützen und sie sofort löschen, nachdem Sie die benötigten Informationen erhalten haben. Falls möglich, verwenden Sie die Option passwd chat debug nur, während Ihr eigenes Kennwort geändert wird.

Das Betriebssystem, auf dem Sie Samba ausführen, kann strenge Regeln für die Gültigkeit von Kennwörtern besitzen, damit sie schwieriger zu erraten sind und nicht durch Wörterbuch-Angriffe herausgefunden werden können. Die Benutzer in Ihrem Netzwerk müssen derartige Regeln kennen, wenn sie ihre Kennwörter ändern.

Wir haben bereits erwähnt, dass die Kennwort-Synchronisierung Einschränkungen unterliegt. Diese bestehen darin, dass eine Synchronisierung in einer anderen als der eben beschriebenen Richtung nicht möglich ist. Wenn das Standardkennwort in der Datei passwd geändert wird, bekommt Samba davon nichts mit und kann dementsprechend das neue Kennwort nicht in die Datei smbpasswd eintragen. Es gibt mehrere Ansätze, dieses Problem anzugehen, einschließlich NIS und den frei verfügbaren Implementierungen des Pluggable Authentication Modules-(PAM-)Standards, aber keiner dieser Versuche löst dieses Problem wirklich.

Weitere Informationen über Kennwörter finden Sie in der Datei der Samba-Quelldistribution docs/htmldocs/ENCRYPTION.html.

Optionen zur Kennwort-Konfiguration

Die in Tabelle 9-8 aufgeführten Optionen helfen Ihnen beim Arbeiten mit Kennwörtern in Samba.

Tabelle 9-8

Optionen zur Kennwort-Konfiguration
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
encrypt passwords	Boolescher Wert	Wenn yes, werden verschlüsselte Kennwörter aktiviert.	no	global
unix password sync	Boolescher Wert	Wenn yes, wird die Standard-Unix-Kennwortdatenbank aktualisiert, sobald ein Benutzer sein verschlüsseltes Kennwort ändert.	no	global
passwd chat	String (chat-Befehle)	Folge von Befehlen, die an das Kennwortprogramm gesandt werden.	siehe den früheren Abschnitt über diese Option	global
passwd chat debug	Boolescher Wert	Wenn yes, werden Fehlerprotokolle des Vorgangs zur Kennwortänderung mit einer Protokollierungsstufe von 100 an die Protokolldateien gesandt.	no	global
passwd program	String (Unix-Befehl)	Programm, das zum Ändern von Kennwörtern verwendet werden soll.	/bin/passwd %u	global
password level	numerischer Wert	Anzahl der Kombinationen aus Großbuchstaben, die beim Ermitteln des Kennworts eines Clients verwendet werden sollen.	keiner	global
update encrypted	Boolescher Wert	Wenn yes, wird die Datei mit den verschlüsselten Kennwörtern aktualisiert, sobald sich ein Client mit einem Klartext-Kennwort an einer Freigabe anmeldet.	no	global
null passwords	Boolescher Wert	Wenn yes, wird der Zugriff für Benutzer ohne Kennwörter gestattet.	no	global
smb passwd file	String (Dateiname)	Name der verschlüsselten Kennwortdatei.	/usr/local/ samba/private/ smbpasswd	global
hosts equiv	String (Dateiname)	Name einer Datei, die Hosts und Benutzer enthält, die sich ohne Kennwort anmelden dürfen.	keiner	global
use rhosts	String (Dateiname)	Name einer .rhosts-Datei, die es Benutzern erlaubt, sich ohne Kennwort anzumelden.	keiner	global

encrypt passwords

Die globale Option encrypt passwords veranlasst Samba, für die Authentifizierung an Stelle von Klartext-Kennwörtern verschlüsselte Kennwörter zu benutzen. Verschlüsselte Kennwörter werden von den Clients erwartet, wenn diese Option yes ist:

In den 2.2.x-Versionen von Samba sowie in früheren Versionen sind verschlüsselte Kennwörter standardmäßig deaktiviert. Dies wurde in Samba 3.0 geändert - dort sind verschlüsselte Kennwörter standardmäßig aktiviert.

Wenn Sie verschlüsselte Kennwörter verwenden, müssen Sie eine gültige smbpasswd-Datei haben, in der Benutzernamen stehen, die sich mit verschlüsselten Kennwörtern anmelden. (Beachten Sie dazu den Abschnitt »Die smbpasswd-Datei« weiter oben in diesem Kapitel.) Darüber hinaus muss Samba wissen, wo die Datei smbpasswd abgelegt ist; befindet sie sich nicht an der vorgegebenen Stelle (üblicherweise /usr/local/samba/private/ smbpasswd ), können Sie den Ablageort in der Option smb passwd file explizit angeben.

Sie können auch update encrypted einsetzen, um Samba zum Aktualisieren der Datei smbpasswd zu zwingen, sobald ein Client sich mit einem unverschlüsselten Kennwort anmeldet.

Wenn Sie in Ihrem Netzwerk eine Mischung aus Clients haben, von denen einige verschlüsselte Kennwörter benutzen und andere Klartext-Kennwörter, sorgen Sie mit der Option include dafür, dass Samba alle Clients entsprechend behandelt. Dazu erzeugen Sie individuelle Konfigurationsdateien auf der Grundlage des Client-Namens (%m). Diese Host-spezifischen Konfigurationsdateien können die Option encrypted passwords = yes enthalten, die nur aktiv wird, wenn solche Clients eine Verbindung zum Server aufnehmen.

unix password sync

Die globale Option unix password sync erlaubt es Samba, die normale Unix-Kennwortdatei zu aktualisieren, wenn ein Benutzer sein verschlüsseltes Kennwort ändert. Das verschlüsselte Kennwort ist auf einem Samba-Server in der Datei smbpasswd gespeichert, die sich standardmäßig in /usr/local/samba/private befindet. Aktivieren Sie die Funktion folgendermaßen:

Ist diese Option eingeschaltet, ändert Samba das verschlüsselte Kennwort und versucht zusätzlich, das Standard-Unix-Kennwort zu ändern, indem der Benutzername und das neue Kennwort an das Programm übergeben werden, das durch die Option passwd program festgelegt wurde (wie bereits beschrieben). Beachten Sie, dass Samba nicht unbedingt Zugriff auf ein Klartext-Kennwort für diesen Benutzer hat. Deshalb muss das Programm, das das Kennwort ändert, als root aufgerufen werden.² Ist die Änderung des Unix-Kennworts - aus welchen Gründen auch immer - nicht erfolgreich, wird das SMB-Kennwort ebenfalls nicht geändert.

passwd chat

Diese Option gibt eine Reihe von Sende/Antwort-Strings an - ähnlich einem Unix-Chat-Skript -, die an das Programm zur Kennwortänderung auf dem Samba-Server geschickt werden. Im Abschnitt »Kennwort-Synchronisierung« weiter oben in diesem Kapitel wird diese Option genauer behandelt.

passwd chat debug

Auf yes gesetzt, zeichnet die globale Option passwd chat debug alles auf, was während einer Kennwortänderung durch Samba geschickt oder von Samba empfangen wurde. Alle Ein- und Ausgaben von Samba während der Kennwortänderung werden mit einer Protokollierungsstufe von 100 an die Samba-Protokolle geschickt. Sie müssen log level = 100 angeben, damit die Informationen aufgezeichnet werden. Im Abschnitt »Kennwort-Synchronisierung« weiter oben in diesem Kapitel wird diese Option genauer behandelt. Wenn Sie die Option aktivieren, müssen Sie bedenken, dass Klartext-Kennwörter in den Fehlerprotokollen auftauchen, die eine immense Bedrohung für die Sicherheit darstellen, wenn sie nicht richtig geschützt werden. In manchen Organisationen widerspricht es den Sicherheitsrichtlinien, dass Systemadministratoren Zugang zu den Kennwörtern der Benutzer haben.

passwd program

Die Option passwd program legt das Programm fest, das der Samba-Server aufruft, um das Unix-Kennwort für einen Benutzer zu ändern, wenn das verschlüsselte Kennwort geändert wird. Vorgabewert dieser Option ist das Programm passwd, das sich üblicherweise im Verzeichnis /bin befindet. Die Samba-Variable %u wird hier häufig dazu herangezogen, den Benutzer anzugeben, der das Programm aufruft. Wie der Datenaustausch zwischen Samba und dem Programm im Einzelnen vonstatten geht, bestimmt die Option passwd chat. Detaillierte Angaben darüber finden Sie in diesem Kapitel im Abschnitt »Kennwort-Synchronisierung«.

password level

Bei SMB werden unverschlüsselte (oder Klartext-)Kennwörter, genau wie die bereits erwähnten Benutzernamen, in Großbuchstaben verschickt. Viele Unix-Benutzer wählen aber Kennwörter, die sowohl Groß- als auch Kleinbuchstaben enthalten. Samba probiert das Kennwort standardmäßig nur mit Kleinbuchstaben aus und versucht nicht, den ersten Buchstaben großzuschreiben.

Ähnlich der Option username level gibt es eine Option password level, mit der Sie festlegen können, wie viele Variationen des Kennworts mit Großbuchstaben Samba ausprobiert. Diese Option benötigt einen ganzzahligen Wert, der bestimmt, wie viele Zeichen Samba in Großbuchstaben setzen soll, wenn es prüft, ob Benutzername und Kennwort übereinstimmen. Verwenden Sie diese Option folgendermaßen:

In diesem Fall probiert Samba alle möglichen Variationen des Kennworts mit ein bis drei Großbuchstaben aus. Je größer die Zahl ist, desto mehr Versuche unternimmt Samba und desto länger kann es dauern, bis die Verbindung zur Freigabe hergestellt ist.

update encrypted

Für Netzwerke, die bisher unverschlüsselte Kennwörter verwendet haben und nun zu verschlüsselten Kennwörtern wechseln wollen, bietet Samba die Option update encrypted an, die einen fließenden Übergang ermöglicht.

Dadurch erzeugt Samba für jeden Benutzer aus dem Unix-Kennwort das verschlüsselte Kennwort in der Datei smbpasswd, sobald der betreffende Benutzer auf eine Freigabe zugreift. Sie müssen allerdings den Wert der Option encrypt passwords auf no festlegen, so dass der Client dem Samba-Server auf jeden Fall das Kennwort im Klartext liefert. Wenn sich jeder Benutzer mindestens einmal angemeldet hat, können Sie encrypted passwords = yes eintragen, so dass der Samba-Server von den Clients ausschließlich verschlüsselte Kennwörter anfordert. Damit dies funktioniert, muss der betreffende Benutzer bereits einen Eintrag in der Datei smbpasswd besitzen.

null passwords

Diese globale Option teilt Samba mit, ob Benutzern mit leerem Kennwort (verschlüsselt oder unverschlüsselt) der Zugriff gewährt werden soll. Die Vorgabe ist no. Sie können den Wert wie folgt ändern:

Wir raten dringend davon ab, dies zu tun, wenn Sie nicht genau wissen, was Sie tun und welche Sicherheitsrisiken diese Option birgt. Das schließt den ungewollten Zugriff auf Systembenutzer (wie bin), die in der Systemkennwortdatei kein Kennwort besitzen, mit ein.

smb passwd file

Diese globale Option gibt an, wo sich die Datei mit den verschlüsselten Kennwörtern befindet. Die Voreinstellung ist /usr/local/samba/private/smbpasswd. Verwenden Sie diese Option folgendermaßen:

Dieser Wert ist beispielsweise in vielen Red Hat-Distributionen üblich, in denen Samba mit einem RPM-Paket installiert wurde.

hosts equiv

Diese globale Option teilt Samba den Namen der Unix-Datei hosts.equiv mit. Diese Datei ermöglicht den Zugriff von bestimmten Clients oder Benutzern ohne Kennwort. Verwenden Sie diese Option wie folgt:

Die Option besitzt keinen Vorgabewert, das heißt, es wird keine hosts.equiv-Datei festgelegt. Da der Einsatz einer hosts.equiv-Datei ein großes Sicherheitsrisiko darstellt, raten wir dringend vom Gebrauch dieser Option ab.

use rhosts

Diese globale Konfigurationsoption gibt den Namen der Unix-Datei .rhosts an, die Clients den Zugriff auf Freigaben ohne Angabe eines Kennworts erlaubt. Sie können den Ablageort einer solchen Datei folgendermaßen festlegen:

Diese Option besitzt keinen Vorgabewert, d.h., es wird keine .rhosts-Datei festgelegt. Ebenso wie bei der gerade vorgestellten Option hosts equiv stellt die Benutzung einer solchen Option ein Sicherheitsrisiko dar. Wir raten davon ab, diese Option zu verwenden, es sei denn, Sie vertrauen der Sicherheit Ihres Netzwerks.

Authentifizierung mit winbind

In Kapitel 3 haben wir Ihnen gezeigt, wie Sie Windows-Clients in ein Netzwerk integrieren, in dem die Benutzerzugänge auf dem Samba-Server verwaltet werden. Wir legten auf dem Windows-Client einen Benutzerzugang mit dem gleichen Benutzernamen und Kennwort wie bei einem Zugang auf dem Unix-System an. Diese Methode funktioniert in vielen Rechnerumgebungen ganz gut. Wenn allerdings ein Samba-Server in ein Windows-Netzwerk aufgenommen wird, in dem es bereits einen primären Domänen-Controller mit Windows NT/2000 gibt, besitzt der PDC die bereits existierende Datenbank mit den Benutzerzugängen und Gruppeninformationen, die für die Authentifizierung verwendet wird. Es kann eine Menge Arbeit machen, diese Datenbank zuerst manuell auf den Unix-Server zu übertragen und später die Unix- und Windows-Datenbanken zu verwalten und zu synchronisieren.

In Kapitel 4 zeigten wir Ihnen dann, wie Sie einen Samba-Server als Domänen-Member-Server in ein Netzwerk aufnehmen, das einen Windows NT/2000-PDC besitzt. Wir setzten security = domain in der Samba-Konfigurationsdatei, so dass der Samba-Server die Authentifizierung dem Windows-PDC überließ. Bei dieser Methode werden die Kennwörter nur auf dem PDC vorgehalten. Allerdings ist es immer noch erforderlich, die Benutzerzugänge auf der Unix-Seite einzurichten, um sicherzustellen, dass jeder Client eine gültige Unix-Benutzer-ID (UID) sowie eine Gruppen-ID (GID) hat. Das ist notwendig, um die Dateieigentümerschaften und -berechtigungen des Unix-Sicherheitsmodells durchzusetzen. Immer wenn Samba im Namen des Windows-Clients eine Operation auf dem Unix-Dateisystem durchführt, muss der Benutzer sowohl eine gültige UID als auch eine gültige GID auf dem lokalen Unix-System haben.

Eine kürzlich in Samba aufgenommene Funktion namens winbind erlaubt es dem Windows-PDC nicht nur, die Authentifizierung vorzunehmen, sondern auch die Benutzer- und Gruppeninformationen zu verwalten. winbind erweitert die Unix-Benutzer- und -Gruppendatenbanken über die normalen /etc/passwd- und /etc/group-Dateien hinaus, so dass Benutzer und Gruppen auf dem Windows-PDC auch als gültige Benutzer und Gruppen auf dem Unix-System existieren. Die Erweiterung gilt für das gesamte Unix-System und erlaubt es Benutzern, die Mitglieder einer Windows-Domäne sind, alle Aktionen auf dem Unix-System auszuführen, die auch ein lokaler Benutzer ausführen kann. Dies schließt die Anmeldung über telnet am Unix-System oder sogar am lokalen System ein. Dazu verwenden sie ihre Domänen-Benutzernamen und -Kennwörter.

Wenn winbind verwendet wird, kann die Administration der Benutzerzugänge auf dem Windows-PDC erledigt werden. Es ist nicht nötig, die Aufgaben auf der Unix-Seite zu wiederholen. Dazu gehört der Verfall der Kennwörter und die Möglichkeit für die Benutzer, ihre Kennwörter zu ändern, was ansonsten nicht praktikabel wäre. Neben der Tatsache, dass es die Domänen-Administration vereinfacht und eine Menge Zeit spart, erlaubt winbind den Einsatz von Samba in Rechenumgebungen, in denen es sonst nicht erlaubt wäre.

Da sich dieses Kapitel um die Sicherheit dreht, wollen wir darauf hinweisen, dass einige Belange dazu führen, dass ein Windows-System Benutzer authentifizieren darf, die auf ein Unix-System zugreifen! Was immer Sie auch über die jeweiligen Vorteile der Sicherheitsmodelle von Unix und Windows denken (und wichtiger noch: deren Implementierungen), eines ist gewiss: Wenn Sie Ihren Samba-Server um winbind-Unterstützung erweitern, verkomplizieren Sie die Authentifizierung als Gesamtvorgang deutlich - und bieten vermutlich Angreifern mehr Möglichkeiten.

winbind installieren

Das Installieren und Konfigurieren von winbind ist relativ kompliziert und erfordert die folgenden Schritte:

Zum Zeitpunkt der Drucklegung dieses Buches gab es nur in Linux Unterstützung für winbind; alle folgenden Anweisungen gelten also nur für dieses System. Später werden möglicherweise auch andere Unix-Varianten unterstützt. Außerdem gehen wir davon aus, dass Sie in Ihrem Netzwerk einen Windows NT/2000-PDC betreiben.

Zuerst müssen Sie Samba mit der Konfigurationsoption --with-winbind kompilieren und konfigurieren. Anweisungen dafür finden Sie in Kapitel 2 im Abschnitt »Samba konfigurieren«. Rufen Sie wie üblich make install auf, um die Samba-Binärdateien zu konfigurieren.

nsswitch konfigurieren

Wenn Samba nach dem Konfigurieren mit der Option --with-winbind kompiliert wurde, erzeugt der Kompilierungsprozess eine Bibliothek namens libnss_winbind.so im Verzeichnis source/nsswitch. Diese Bibliothek muss in das Verzeichnis /lib kopiert werden:

Außerdem muss für winbind ein symbolischer Link angelegt werden, damit es richtig funktioniert:

Als Nächstes passen Sie die Datei /etc/nsswitch.conf so an, dass die Zeilen für passwd und group so aussehen:

Anschließend aktivieren Sie diese Änderungen, indem Sie den folgenden Befehl aufrufen:

Damit haben Sie gerade den Linux Name Service Switch konfiguriert, der es Ihnen erlaubt, den Namensdienst und andere Aufgaben mittels der traditionellen Methode (Dateien im Verzeichnis /etc) zu konfigurieren oder eine Erweiterung zu nutzen, die in einer Bibliothek wie etwa der libnss_winbind.so-Bibliothek kodiert ist, die Sie gerade installiert haben. In der Konfiguration wurde angegeben, dass Samba nach den Benutzer- und Gruppeninformationen zuerst in den Dateien /etc/passwd und /etc/group sucht. Sind sie dort nicht zu finden, sucht es im winbind-Dienst.

Die smb.conf anpassen

Um winbind benutzen zu können, müssen Sie den Samba-Server als Domänen-Member-Server in die Windows NT-Domäne einfügen (wie in Kapitel 4 beschrieben) und einige Parameter in die Samba-Konfigurationsdatei aufnehmen, um winbind zu konfigurieren. Zusätzlich zu den Optionen, die erforderlich sind, um Samba als Domänen-Member-Server zu konfigurieren, wird Folgendes benötigt:

Die Optionen winbind uid und winbind gid teilen winbind mit, wie die Windows-RIDs (Relative Identifiers) auf die Unix-UIDs und -GIDs abgebildet werden. Windows verwendet RIDs, um Benutzer und Gruppen innerhalb der Domäne zu identifizieren. Um zu funktionieren, muss das Unix-System mit jeder Benutzer- und Gruppen-RID, die vom Windows-PDC empfangen wird, eine UID und eine GID verknüpft haben. Die Parameter winbind uid und winbind gid liefern winbind einfach einen Bereich von UIDs bzw. GIDs, die vom Systemadministrator für Windows NT-Domänen-Benutzer und -Gruppen freigehalten wurden. Sie können für diesen Zweck einen beliebigen Bereich verwenden; stellen Sie einfach nur sicher, dass die niedrigste Zahl in dem Bereich nicht mit den Einträgen in den Dateien /etc/passwd oder /etc/group kollidiert - und zwar weder jetzt noch in Zukunft. An dieser Stelle müssen Sie unbedingt vorsichtig sein. Wenn winbind erst einmal eine RID- auf UID/GID-Abbildung in seine Datenbank aufgenommen hat, ist es nicht einfach, diese zu ändern.

Seien Sie vorsichtig, wenn Sie lokale Benutzer anlegen, nachdem die Domänen-Benutzer damit begonnen haben, auf den Samba-Server zuzugreifen. Die Domänen-Benutzer haben speziell für sie von winbind erzeugte Einträge in /etc/passwd, wobei ihre UIDs in dem von Ihnen festgelegten Bereich liegen. Wenn Sie beim Anlegen neuer Zugänge eine Methode wählen, die automatisch UIDs zuweist, geschieht die Wahl der UIDs möglicherweise in der Form, dass zur bisher höchsten zugewiesenen UID 1 addiert wird. Dabei wird es sich um die neueste von winbind angelegte UID handeln. (Das ist beispielsweise unter Red Hat Linux mit dem useradd-Skript der Fall.) Die UID für den neuen lokalen Benutzer befindet sich dann in dem Bereich, der für winbind reserviert ist, wodurch sich unvorhersehbare Auswirkungen ergeben können. Achten Sie darauf, dass sich die zugewiesenen UIDs beim Anlegen neuer Benutzer im richtigen Bereich bewegen. Sie könnten zum Beispiel die Option -u des useradd-Skripts verwenden, um dem neuen Benutzer eine UID zuzuweisen.

Starten Sie die Samba-Daemons neu, um die Änderungen an der Konfigurationsdatei zu aktivieren. Falls Sie das noch nicht erledigt haben, als Sie Ihren Samba-Server zum Domänen-Member-Server beförderten, müssen Sie diesen Befehl ausführen:

wie wir in Kapitel 4 beschrieben haben. Jetzt können Sie den winbindd-Daemon starten:

Möglicherweise wollen Sie einen ps ax-Befehl ausführen, um nachzuschauen, ob der winbindd-Daemon wirklich läuft. Um nun sicherzustellen, dass alle bisherigen Einstellungen funktionieren, können Sie den Samba-Befehl wbinfo verwenden:

Die Option -u fragt den Domänen-Controller nach einer Liste der Domänen-Benutzer. Die Option -g fordert die Liste der Gruppen an. Die Ausgabe zeigt, dass das Samba-Host-System den Windows-PDC über winbind abfragen kann.

Darüber hinaus sollte nun die Liste der Benutzer und Gruppen geprüft werden. Dazu verwenden Sie den Befehl getent:

Dies zeigt, dass das Linux-System die Domänen-Benutzer und -Gruppen über winbind findet, und das zusätzlich zu denen in den Dateien /etc/passwd und /etc/group. Funktioniert dieser Teil nicht so, wie zuvor gezeigt, das heißt, sind die Domänen-Benutzer und -Gruppen nicht nach den lokalen Benutzern und Gruppen aufgeführt, prüfen Sie, ob Sie den symbolischen Link auf libnss_winbind.so im Verzeichnis /lib richtig angelegt haben.

Nun können Sie versuchen, von einem Windows-System aus mit einem Domänen-Zugang eine Verbindung zu einer Samba-Freigabe herzustellen. Sie können sich entweder von einer Windows NT/2000/XP-Workstation aus an einer Domäne anmelden oder smbclient mit der Option -U verwenden, um einen Benutzernamen anzugeben.

Falls Sie Fehlermeldungen erhalten, während Sie versuchen, sich an der Domäne anzumelden, liegt das vermutlich daran, dass Sie das Client-System zuvor mit einem Computerzugang auf einem anderen Domänen-Controller konfiguriert hatten. Üblicherweise erscheint ein Dialog, der sagt: »Die Domäne NAME ist nicht verfügbar.« Auf einem Windows 2000-System müssen Sie sich dann als administrativer Benutzer am System anmelden und die Systemsteuerung öffnen. Doppelklicken Sie auf das Symbol System, klicken Sie die Registerkarte Netzwerkidentifikation an und wählen Sie dann den Button Eigenschaften. In dem sich öffnenden Dialog klicken Sie auf den Radio-Button Arbeitsgruppe: und setzen den Namen der Arbeitsgruppe ein (dieser darf mit dem Namen der Domäne identisch sein). Klicken Sie auf die OK-Buttons in den Dialogen und starten Sie auf Anforderung den Rechner neu.

Dies löscht den Computerzugang vom primären Domänen-Controller. Melden Sie sich jetzt erneut als administrativer Benutzer an und wiederholen Sie die vorangegangenen Schritte; ändern Sie nun jedoch die Arbeitsgruppe zurück auf die Domäne. Dadurch wird ein neuer Computerzugang angelegt, der die Workstation an den neuen primären Domänen-Controller »anpasst«. Verfügt Ihr Netzwerk über Backup-Domänen-Controller, kann es bis zu 15 Minuten dauern, bis der neue Zugang den BDCs bekannt gemacht worden ist.

Nachdem Sie sich als Domänen-Benutzer angemeldet haben, versuchen Sie einmal, eine oder zwei Dateien in einer Samba-Freigabe zu erzeugen. (Möglicherweise müssen Sie die Berechtigungen auf dem freigegebenen Verzeichnis - auf, sagen wir einmal, 777 - ändern, um diesen Zugriff zu erlauben. Dieser Wert ist sehr großzügig. Wenn Sie mit dem Lesen dieses Abschnitts fertig sind, werden Sie allerdings verstanden haben, wie Sie die Eigentümerschaft und die Berechtigungen auf dem Verzeichnis so anpassen, dass der Zugriff nur noch ausgewählten Domänen-Benutzern erlaubt ist.) Wenn Sie dann über einen oder mehrere Domänen-Benutzer Dateien erzeugt haben, werfen Sie von einer Linux-Shell aus einmal einen Blick auf den Inhalt des Verzeichnisses. Sie werden Folgendes sehen:

Sie können sogar die Domänen-Benutzernamen und -Gruppen von der Linux-Shell aus sehen:

Beachten Sie, wie der Benutzer und die Gruppe als Domänen-Benutzer und Domänen-Gruppe erkennbar sind. Leider zeigt der GNU-Befehl ls nicht die vollständigen Namen der Domänen-Benutzer und -Gruppen, wir können uns aber mit dem -ln-Listing die UIDs und GIDs anzeigen und dies dann mit dem Befehl wbinfo übersetzen lassen:

(Das ist ein bisschen kompliziert, aber es funktioniert und zeigt außerdem, dass das winbind-System korrekt arbeitet!) An dieser Stelle könnten Sie Ihr /etc/rc.d/init.d/smb-Skript ändern, um den winbindd-Daemon automatisch zusammen mit den smbd- und nmbd-Daemons starten und stoppen zu lassen. Beginnend mit dem Skript, das wir Ihnen in Kapitel 2 gezeigt haben, fügen Sie zuerst diesen Code in die start( )-Funktion ein:

Der eben gezeigte Code sollte hinter dem Code stehen, der nmbd startet, sowie vor der return-Anweisung.

Auch dieser Code sollte hinter dem Code, der nmbd stoppt, und vor der return-Anweisung stehen.

PAM konfigurieren

Die meisten populären Linux-Distributionen verwenden Pluggable Authentication Modules (PAM), eine Sammlung von Shared Libraries, die eine zentrale Authentifizierungsquelle für Anwendungen darstellen, die auf dem Unix-System laufen. PAM kann für jede Anwendung (oder jeden Dienst), die es einsetzt, anders konfiguriert werden, ohne dass die Anwendung neu kompiliert werden muss. Hier ein hypothetisches Beispiel: Wenn die Sicherheitsrichtlinien einer Organisation die Verwendung von Kennwörtern verlangen würden, die genau zehn Zeichen lang sind, könnte ein PAM-Modul geschrieben werden, das die Länge der Kennwörter überprüft, die die Benutzer eingeben, und alle Versuche abweist, ein längeres oder kürzeres Kennwort einzugeben. PAM würde dann neu konfiguriert werden, um Dienste wie ftp, Konsolenanmeldungen und Anmeldungen über die grafische Oberfläche zu verarbeiten, die PAM aufrufen, um Benutzer zu authentifizieren.

Falls Sie mit PAM noch nicht vertraut sind, empfehlen wir Ihnen, die Dokumentation zu lesen, die mit dem Linux-PAM-Paket geliefert wird, bevor Sie hier weitermachen. Auf den meisten Linux-Systemen befindet es sich in der Verzeichnishierarchie /usr/share/doc. Eine weitere Ressource ist der Linux-PAM System Administrator's Guide, den Sie im Internet unter http://www.kernel.org/pub/linux/libs/pam finden können.

Der Rest dieses Abschnitts handelt von der Benutzung des PAM-Moduls, das in der Samba-Distribution enthalten ist und Benutzer von Windows-Domänen in die Lage versetzen soll, sich an dem Linux-System zu authentifizieren, auf dem Samba läuft. Je nachdem, welche Dienste Sie konfigurieren wollen, erlaubt dies Windows-Domänen-Benutzern, sich an einer lokalen Konsole (oder über telnet) anzumelden, sich über den grafischen Desktop am Linux-System anzumelden, sich an einem FTP-Server zu authentifizieren, der auf dem Linux-System läuft, oder andere Dienste zu benutzen, die normalerweise Benutzern vorbehalten sind, die einen Zugang auf dem Linux-System besitzen. Das PAM-Modul authentifiziert Windows-Domänen-Benutzer, indem es winbind abfragt, das die Authentifizierung an einen Windows NT-Domänen-Controller übergibt.

Als Beispiel wollen wir Ihnen zeigen, wie Sie es Windows-Domänen-Benutzern erlauben, sich an einer Textkonsole auf dem Linux-System anzumelden und die Kommando-Shell sowie ein Home-Verzeichnis zu erhalten. Die in unserem Beispiel angewandten Methoden können (mit Variationen) auf andere Dienste übertragen werden.

Alle Benutzer, die sich am Linux-System anmelden können, benötigen eine Shell und ein Home-Verzeichnis. Unix und Linux bewahren die Benutzerinformationen in der Kennwortdatei (/etc/passwd ) auf, dort stehen jedoch keine Informationen über Windows-Benutzer. Stattdessen fügen wir in die Samba-Konfigurationsdatei die folgenden Zeilen ein, um winbind davon in Kenntnis zu setzen, welches die Shell und das Home-Verzeichnis für die Benutzer der Windows-Domäne sein sollen:

Die erste Zeile legt den Parameter template shell fest, der winbind mitteilt, welche Shell für Domänen-Benutzer verwendet werden soll, die sich an dem Unix-Host anmelden. Der Parameter template homedir gibt die Lage der Home-Verzeichnisse der Benutzer an. Die Variable %D wird durch den Namen der Domäne ersetzt, in der sich der Zugang des Benutzers befindet. %U wird durch den Benutzernamen des Benutzers in dieser Domäne ersetzt.

Bevor sich die Domänen-Benutzer erfolgreich anmelden können, müssen ihre Home-Verzeichnisse manuell angelegt werden. Um einen Zugang für linda in der Domäne METRAN hinzuzufügen, müssten Sie diese Befehle einsetzen:

Als Nächstes müssen Sie das PAM-Modul in der Samba-Distribution kompilieren und installieren. Rufen Sie im Quellverzeichnis der Samba-Distribution die folgenden Befehle auf:

Unter Red Hat Linux befinden sich die PAM-Konfigurationsdateien im Verzeichnis /etc/pam.d. Bevor Sie irgendetwas verändern, sollten Sie auf jeden Fall eine Sicherungskopie dieses Verzeichnisses anlegen:

Der Grund dafür ist, dass wir die Methode des Linux-Systems zum Authentifizieren von Logins verändern werden. Schlägt die Konfiguration fehl, werden alle Benutzer (einschließlich root) aus dem System ausgesperrt. Falls der schlimmste Fall eintritt, müssten wir das System im Einbenutzermodus neu starten (durch Eingabe von linux single am LILO:-Prompt) oder von einer Notfalldiskette booten und dann diese beiden Befehle ausführen:

Achten Sie sorgfältig darauf, dass Sie alle Fehler, die Sie möglicherweise machen, wieder beheben können, da PAM den Zugriff verweigert, wenn es Konfigurationsinformationen entdeckt, die es nicht versteht. Das bedeutet, dass Sie alles richtig eingeben müssen! Vermutlich sollten Sie während der Arbeit an Ihrer PAM-Konfiguration auf einem eigenen Terminal als root angemeldet bleiben, um eine Möglichkeit zu haben, leicht alles wieder rückgängig zu machen.

Im Verzeichnis /etc/pam.d finden Sie eine Datei für alle Dienste, die PAM verwenden. Uns interessiert nur die Datei, die dem Login-Dienst entspricht und die die Bezeichnung login trägt. Sie enthält die folgenden Zeilen:

Die Zeilen, die mit auth beginnen, haben mit der Funktion der Authentifizierung zu tun - das heißt dem Ausgeben eines Kennwort-Prompts, Akzeptieren des Kennworts, Überprüfen, dass es korrekt ist, und Zuordnen einer gültigen Benutzer- und Gruppen-ID zu dem Benutzer. Die Zeile, die mit account beginnt, dient der Zugangsverwaltung und erlaubt es, den Zugriff durch weitere Faktoren zu steuern, beispielsweise über die Tageszeiten, zu denen dem Benutzer der Zugriff erlaubt ist. Wir befassen uns nicht mit den Zeilen, die mit password oder session beginnen, da winbind keiner dieser Funktionen etwas hinzufügt.

Die dritte Spalte listet das PAM-Modul auf - eventuell mit Argumenten -, das für diese Aufgabe aufgerufen wird. Das Modul pam_stack.so wurde von Red Hat hinzugefügt, um als eine Art Makro oder Subroutine zu agieren. Es ruft die Datei im Verzeichnis pam.d auf, die durch das Dienstargument genannt wird. In diesem Fall enthält die Datei /etc/pam.d/system-auth eine Reihe von Zeilen, die als gemeinsamer Standardwert für viele Dienste verwendet werden. Da wir den Login-Dienst für winbind anpassen wollen, ersetzen Sie zuerst die pam_stack.so-Zeilen für auth und account durch die auth- und account-Zeilen aus /etc/pam.d/system-auth. Dies ergibt:

Um winbind-Unterstützung hinzuzufügen, müssen Sie in die Abschnitte auth und account eine Zeile aufnehmen, die das Modul pam_winbind.so aufruft:

Die Schlüsselwörter required und sufficient in der zweiten Spalte sind entscheidend. Das Schlüsselwort required legt fest, dass das Ergebnis, das vom Modul zurückgeliefert wird (die Authentifizierung entweder durchzuführen oder fehlschlagen zu lassen), beachtet werden muss, während das Schlüsselwort sufficient angibt, dass keine weiteren Zeilen verarbeitet werden müssen, falls das Modul den Benutzer erfolgreich authentifiziert. Indem wir sufficient für das Modul pam_winbind.so angeben, erlauben wir es winbind, die Benutzer zu authentifizieren. Gelingt dies, kehrt das PAM-System zur Anwendung zurück. Findet das Modul pam_winbind.so den Benutzer nicht oder stimmt das Kennwort nicht überein, fährt das PAM-System mit der nächsten Zeile fort, in der die Authentifizierung entsprechend der üblichen Linux-Benutzerauthentifizierung durchgeführt wird. Auf diese Weise können sich sowohl Domänen-Benutzer als auch lokale Benutzer anmelden.

Beachten Sie, dass wir im Abschnitt auth auch das Argument use_first_pass in das pam_unix.so-Modul aufgenommen haben. Standardmäßig geben sowohl pam_winbind.so als auch pam_unix.so einen Kennwort-Prompt aus und akzeptieren ein Kennwort. In solchen Fällen, in denen sich Benutzer am Linux-System über ihre lokalen Zugänge anmelden wollen, müssten sie ihr Kennwort zweimal eingeben. Das Argument user_first_pass weist das Modul pam_unix.so an, das Kennwort noch einmal zu verwenden, das an das Modul pam_winbind.so übergeben wurde. Die Benutzer müssen also ihr Kennwort nur einmal eintippen.

Nach dem Verändern der Konfigurationsdatei login schalten Sie auf eine freie virtuelle Konsole um und testen, ob Sie sich immer noch mit einem normalen Linux-Zugang anmelden können. Falls nicht, prüfen Sie Ihre Modifikationen sorgfältig und versuchen es erneut, bis es klappt. Melden Sie sich dann mit einem Domänen-Benutzerzugang aus der Windows-PDC-Datenbank an, um zu testen, ob die winbind-Authentifizierung funktioniert. Sie müssen den Benutzernamen im Format DOMÄNE\benutzer angeben:

Weitere Informationen über die Konfiguration von winbind finden Sie in der Datei der Samba-Quelldistribution docs/htmldocs/winbind.html sowie auf der winbindd-Manpage. Falls Sie mehr über das Konfigurieren von PAM erfahren wollen, empfehlen wir Ihnen die Webseite http://www.kernel.org/pub/linux/libs/pam/ als Ausgangspunkt. Einige der Dokumentationen für Linux PAM, einschließlich der Erweiterungen von Red Hat, finden Sie auch bei Red Hat Linux in /usr/share/doc/pam-version.

winbind-Konfigurationsoptionen

Tabelle 9-9 fasst einige der häufiger verwendeten Optionen zusammen, die Sie zum Konfigurieren von winbind einsetzen können.

Tabelle 9-9

winbind-Optionen
Option	Parameter	Funktion	Vorgabewert	Geltungsbereich
winbind separator	String (einzelnes Zeichen)	Zeichen, das in Domänen-Benutzernamen und -Gruppennamen als Trennzeichen verwendet wird.	Backslash (\)	global
winbind uid	String (Zahlenbereich)	Bereich der UIDs für die RID-auf-UID-Zuordnung.	keiner	global
winbind gid	String (Zahlenbereich)	Bereich der GIDs für die RID-auf-GID-Zuordnung.	keiner	global
winbind cache time	numerischer Wert	Anzahl der Sekunden, die der winbindd-Daemon Benutzer- und Gruppendaten zwischenspeichert.	15	global
template homedir	String (Verzeichnisname)	Verzeichnis, das als Home-Verzeichnis des angemeldeten Domänen-Benutzers verwendet wird.	/home/%D/%U	global
template shell	String (Befehlsname)	Das Programm, das als Shell des angemeldeten Domänen-Benutzers verwendet wird.	/bin/false	global

winbind separator

Auf Windows-Systemen wird der Backslash (\) üblicherweise als Trennzeichen in Dateinamen, UNCs und den Namen der Domänen-Benutzer und -Gruppen verwendet. Beispielsweise würde ein Zugang in der Domäne METRAN mit dem Benutzernamen linda als METRAN\linda geschrieben werden. Auf Unix-Systemen wird der Backslash üblicherweise als Metazeichen zum Schützen (Quoting) anderer Zeichen benutzt. Der Zugang müsste daher als METRAN\\linda oder 'METRAN\linda' angegeben werden. Der Parameter winbind separator erlaubt es, statt des Backslash-Zeichens ein anderes Zeichen zu verwenden, wodurch sich das Eingeben von Domänen-Benutzer- und -Gruppennamen vereinfacht. Mit

könnte der gerade gezeigte Zugang auf dem Unix-Host als METRAN+linda geschrieben werden, wodurch die zusätzlichen Backslashes oder einfachen Anführungszeichen unnötig werden würden. winbind verwendet dann das gleiche Format zum Ausgeben von Domänen-Benutzer- und -Gruppennamen.

winbind uid

Als Teil seiner Aufgabe, die Benutzer einer Windows NT-Domäne als lokale Benutzer auf dem Unix-Host funktionieren zu lassen, liefert winbindd eine Unix-UID, die mit der Windows-RID des Domänen-Benutzers verknüpft ist. Der Parameter winbind uid erlaubt es dem Administrator des Unix-Systems, für diesen Zweck einen Bereich von UIDs zu reservieren. Es ist äußerst wichtig, dass dieser Bereich sich nicht mit anderen UIDs überschneidet, die für andere Aufgaben auf dem Unix-System eingesetzt werden. Wir empfehlen Ihnen daher, diesen Bereich bei einer sehr hohen Zahl beginnen zu lassen, die viel größer ist als die Anzahl der lokalen und NIS-Benutzer, die jemals in Ihrem Netz existieren werden. winbind uid könnte beispielsweise auf einem System, das nie mehr als 9.999 lokale und NIS-Benutzer haben wird, als:

angegeben werden. Da dieses Beispiel 5.000 UIDs für winbindd reserviert, wird davon ausgegangen, dass niemals mehr als 5.000 Domänen-Benutzer auf den Samba-Host zugreifen.

Falls bei Ihnen beim Anlegen neuer lokaler Benutzer die UIDs automatisch zugewiesen werden, müssen Sie sicherstellen, dass diese nicht innerhalb des Bereichs des UIDs liegen, die für winbind reserviert sind. Dies könnte geschehen, wenn der verwendete Algorithmus zur bisher höchsten zugewiesenen UID einfach 1 hinzuzählt.

Es gibt für winbind uid keinen Standardwert, Sie müssen also in Ihrer Samba-Konfigurationsdatei einen Wert angeben, damit winbind funktioniert.

winbind gid

Diese Option funktioniert genau wie winbind uid, allerdings dient sie zum Reservieren eines Bereichs von GIDs für die Benutzung mit winbindd. Sie müssen vermutlich nicht so viele GIDs reservieren wie UIDs, da Sie wahrscheinlich relativ wenige Domänen-Gruppen haben, die entsprechende GIDs benötigen. (In vielen Fällen sind die Benutzer alle Mitglied in der Gruppe Domain Users, wodurch nur eine GID gebraucht wird.) Gehen Sie aber lieber auf Nummer sicher und reservieren Sie mehr GIDs, als Sie vermutlich benötigen werden.

Wie bei winbind uid gilt es aufzupassen, dass die zum Zuweisen der GIDs verwendete Methode nicht mit winbind kollidiert, falls beim Anlegen neuer lokaler Benutzer auf Ihrem Unix-Host die GIDs automatisch zugewiesen werden. Setzen Sie ansonsten die GIDs manuell.

Es gibt für winbind gid keinen Standardwert, Sie müssen also in Ihrer Samba-Konfigurationsdatei einen Wert angeben, damit winbind funktioniert.

winbind cache time

Der winbindd-Daemon verwaltet einen Cache mit den Benutzer- und Gruppendaten, die er vom Windows-PDC bezogen hat, um die Netzwerkanfragen zu reduzieren und die Leistung zu verbessern. Der Parameter winbind cache time ermöglicht es, die Zeitspanne einzustellen (in Sekunden), die winbindd die gespeicherten Daten verwenden kann, bevor es den PDC wieder nach den aktuellen Daten fragen muss. Dieses Intervall ist standardmäßig auf 15 Sekunden gesetzt. Wenn also ein Teil eines Benutzer- oder Gruppenzugangs auf dem PDC verändert wurde, kann es bis zu 15 Sekunden dauern, bis winbindd seine eigene Datenbank aktualisiert hat.

template homedir

Wenn das lokale Unix-System so konfiguriert ist, dass es Domänen-Benutzern die Anmeldung erlaubt, muss der Benutzer für viele Programme, einschließlich Kommando-Shells, ein Home-Verzeichnis angeboten bekommen, damit diese richtig funktionieren. Die Option template homedir wird verwendet, um den Namen des Home-Verzeichnisses einzustellen. Im Namen des Verzeichnisses wird %D durch den Namen der Windows NT-Domäne ersetzt, in der der Benutzer sich befindet. Die Variable %U wird durch seinen Benutzernamen ersetzt. Standardmäßig ist template homedir auf /home/%D/%U gesetzt, was für ein Netzwerk ganz gut funktioniert, in dem es mehr als eine Windows NT-Domäne gibt. Es ist dann für unterschiedliche Menschen in unterschiedlichen Domänen möglich, den gleichen Benutzernamen zu tragen. Wenn Sie sicher sind, dass Sie nie mehr als eine Windows NT-Domäne in Ihrem Netzwerk haben werden oder dass Sie zwar mehr als eine Domäne haben, aber wissen, dass ein Benutzer in mehreren Domänen den gleichen Benutzernamen trägt, könnten Sie template homedir so einstellen:

template shell

Diese Option gibt das Programm an, das als Shell für Domänen-Benutzer eingesetzt wird, die am Unix-Host angemeldet sind. Standardmäßig ist sie auf /bin/false gesetzt, wodurch Domänen-Benutzern die Anmeldung verwehrt wird. Falls Sie Anmeldungen von Domänen-Benutzern zulassen wollen, stellen Sie für template shell eine gültige Kommando-Shell (oder ein anderes Programm) ein, die als Textschnittstelle für Domänen-Benutzer dienen soll, sobald diese sich angemeldet haben. Eine verbreitete Einstellung unter Linux wäre:

Samba, 2. Auflage