Samba 3.0 steht vor der Tür und es gibt Grund für ausgelassene Stimmung: Die freie Implementierung des SMB-Protokolls verhilft Linux-Servern zu einer mit NT 4.0 vergleichbaren Funktionalität und tanzt beherzt auf Windows XP zu.

Zum Redaktionsschluss des Linux-Magazins ist Samba 3.0 bei der zweiten Beta-Release angelangt.[1] Das Inspizieren der Anzahl der CVS-Checkins macht klar, dass das Entwicklerteam intensiv an der endgültigen Release arbeitet. Nach dem Erscheinen dieses Hefts werden vermutlich nur wenige Wochen bis zu dem Ereignis vergehen. Schon heute sind eine Menge Beta- und Alphaversionen von Samba 3.0 im Einsatz, zum Beispiel im Bundeskartellamt. Der Grund für die Ungeduld sind neue attraktive Features, mit denen die Major-Release gegenüber der etablierten Version 2.2[2] auftrumpft.

Zwei Verbesserungen sind nach außen nicht oder kaum sichtbar: Die Unterstützung von NT-Errorcodes und die Darstellung von Dateinamen im Unicode-Format. NT-Errorcodes treten für den Benutzer überhaupt nicht in Erscheinung, sie sind aber wichtig für eine zu Windows kompatible Fehlerbehandlung. Viele Windows-Anwendungen verlassen sich darauf, dass sich ein SMB-Fileserver in allen Aspekten genau wie Windows verhält, und damit bewegt sich Samba ein gutes Stück in Richtung NT.

Die Unterstützung von Unicode-Dateinamen hat als Konsequenz, dass Umlaute und andere Nicht-Ascii-Zeichen unabhängig von der Client-Version darstellbar sind: Clients in verschiedenen Länderversionen, die gemeinsam auf einem Dateiserver arbeiten, sehen die gleichen Dateinamen. Die Samba-2-Optionen »client code page« und »character set« haben sich damit erledigt.

Mit Samba 3 ist die Option »unix charset« wesentlich. Sie beschreibt, wie Dateinamen in Unix kodiert sind, und steht per Default auf »UTF8«, der 8-Bit-Variante von Unicode. Damit sind sämtliche unter Windows vorkommenden Zeichen im Unix-Dateisystem darstellbar. Diese Voreinstellung sollte der Administrator bei Neuinstallationen nicht verändern. Beim Upgrade von Samba 2.2 nach 3.0 werden die Umlaute in Dateinamen jedoch ohne Zutun nicht überleben. Die viel verwendeten Einstellungen

client code page = 850
character set = 8859-1

muss der Admin in Samba 3 mit »unix charset = CP850« anpassen, um die vorhandenen Dateinamen zu erhalten.

Die Option »dos charset« ist ausschließlich für Clients unter DOS und Windows 3.11 wesentlich. Alle Systeme ab Windows 95 benutzen Unicode für die Dateinamen, müssen also nicht länderspezifisch eingestellt werden. »display charset« legt den Zeichensatz fest, mit dem Samba seine eigenen Meldungen auf dem Bildschirm ausgibt. Für das Funktionieren als Server ist die Option daher eher unwichtig.

Eine weitere Änderung im Dateiserver-Betrieb betrifft die VFS-Module. Mit Samba 3 ist es möglich, mehr als ein Modul gleichzeitig zu laden. Damit kann man beispielsweise einen Virenscanner und den Papierkorb parallel nutzen. Entsprechend haben die Samba-Entwickler die Option »vfs object« in »vfs objects« umbenannt. Die Änderung bedeutet leider, dass nicht unmittelbar für Samba 3.0 gelieferte Module angepasst und neu kompiliert werden müssen.

Konfigurierbare Passdb-Backends

Wer SuSEs Samba-Pakete einsetzt, darf dank der Arbeit von Lars Müller zur Laufzeit auswählen, ob Samba die Datei »smbpasswd« benutzt oder ob er Samba an den LDAP-Dienst binden will. Das funktioniert bei SuSE nur, weil Samba im Wesentlichen doppelt auf der Platte liegt – einmal mit und einmal ohne LDAP kompiliert. Die Besitzer aller anderen Distributionen müssen sich bereits beim Kompilieren entscheiden: »smbpasswd« oder LDAP. Intern heißt die Schnittstelle zum Inhalt der »smbpasswd«-Datei Passdb-Interface.

Passdb-Module dynamisch konfigurieren

Samba 3 kann im Gegensatz zu Samba 2.2 »passdb«-Module dynamisch konfigurieren oder sogar als Shared Object nachladen. Der entsprechende Parameter heißt »passdb backend«. Der Defaultwert für den Parameter ist

passdb backend = smbpasswd

und liefert exakt die Funktionalität von Samba 2.2 ohne Zugriff auf LDAP. Alternative Module sind »tdbsam«, »ldapsam_compat« und »ldapsam«.

Die Variante mit der »smbpasswd«-Datei als Passdb-Backend kann die Passwörter für Samba speichern, aber nicht viel mehr. Für einen normalen Datei- und Druckserver reicht dies völlig aus. Soll Samba aber als Domänencontroller arbeiten, müssen über den Benutzer mehr Daten gespeichert werden, zum Beispiel der Ort des Server-gespeicherten Profils und der Name des verwendenden Login-Skripts. Samba kennt globale Parameter wie »logon path«, die zwar mit Makros wie »%U« pro Benutzer angepasst werden können, die aber auch ziemlich unflexibel sind.

Man könnte natürlich die »smbpasswd« um die benötigten Felder erweitern, was aber programmtechnisch sehr unschön wäre. Per Programm in einer Klartextdatei Felder unterschiedlicher Länge zu ändern, liefe darauf hinaus, die Datei bei jeder Änderung komplett neu zu schreiben. Die Passwortfelder haben die Eigenschaft, eine feste Länge zu haben. Die kann man auch in einer Klartextdatei sehr einfach überschreiben.

Mit Samba 3 gibt es eine sehr einfache Möglichkeit, die Einschränkungen beim PDC zu beheben. Mit dem Parameter »passdb backend = tdbsam« werden die Informationen der »smbpasswd«-Datei in der Datei »passdb.tdb« abgelegt. Sie lässt es zu, alle Felder für die Benutzer einzeln festzulegen, und zwar entweder mit dem Programm »pdbedit« oder in für Windows-Administratoren gewohnter Form im NT-Benutzermanager. Die MMC von Windows 2000 eignet sich übrigens nicht dafür, NT-Benutzer zu editieren, da sie ausschließlich mit Active Directory umzugehen versteht.

Bei den binären »tdb«-Dateien gibt es wie bei allen Datenbanken das Problem, dass sie während des Betriebs nicht konsistent gesichert werden können – fatal für die zentrale »passdb.tdb«. Daher gibt es das Programm »tdbbackup«, das jede »tdb«-Datei ausliest und in eine andere »tdb«-Datei konsistent kopiert. Diese Kopie wird danach nicht mehr benutzt und darf gesichert werden.

Samba mit LDAP

Schon Samba 2.2 konnte eine Benutzerdatenbank per LDAP implementieren[3], allerdings war die Anbindung an den LDAP-Server recht rudimentär. Zwar funktioniert sie recht ordentlich, machte aber kaum mehr, als die »smbpasswd«-Datei aus LDAP zu beziehen. Zudem kämpfte Samba 2.2 mit einem großen Performanceproblem, besonders wenn Samba- und LDAP-Server nicht auf einer Maschine liefen: Für jede noch so kleine Abfrage baut Samba 2.2 eine neue LDAP-Verbindung auf und führt beim Einsatz von TLS zwischen Smbd und LDAP-Server jedes Mal einen kompletten TLS-Handshake durch. Beides ist zeitaufwändig und bei stark frequentierten Servern unzumutbar.

Samba 3 öffnet pro Smbd eine LDAP-Verbindung und hält sie dauerhaft offen, was einzelne Anfragen erheblich schneller abarbeitet. Zudem speichert Samba 3 sehr viel mehr Daten im LDAP.

Das neue Samba ändert gegenüber 2.2 das LDAP-Schema im Grundsatz. Die Änderung hat zwei Aspekte: Einerseits legt Version 3 die Gruppenabbildungen und die ID-Mappings (siehe unten) im LDAP ab, andererseits weicht der 2.2er »sambaAccount« einem »sambaSamAccount«. Letzteres geschah wegen Konflikten in Attributnamen mit anderen Anwendungen. Im »sambaSamAccount« beginnen alle Attributnamen mit dem Vorsatz »samba«: Statt »ntPassword« heißt es nun »sambaNTPassword« und so weiter. Das neue Schema kommt zum Tragen, wenn man

passdb backend = ldapsam

verwendet. Um das Umstellen zu erleichtern, gibt es weiterhin das Modul:

passdb backend = ldapsam_compat

Damit bleiben alte Einträge mit der Objektklasse »sambaAccount« weiterhin verwendbar.

Die Konfiguration, die Samba darüber in Kenntnis setzt, welchen LDAP-Server es befragen soll, hat sich ebenfalls geändert. Dazu kennt Samba 2.2 die Optionen »ldap server«, »ldap port« und »ldap tls«. Alle drei Optionen bekommen nun das Modul »ldapsam« beziehungsweise »ldapsam_compat« als Parameter wie folgt übergeben:

passdb backend = ldapsam:ldap://Server:Port/

Oder mit TLS durch:

passdb backend = ldapsam:ldaps://Server:Port/

Alle, die sich an die »configure«-Option »–with-ldapsam« gewöhnt haben, dürfen alternativ die drei alten Optionen »ldap server« et cetera weiter benutzen.

IDMAP

Eine der wesentlichen internen Änderungen in Samba 3 ist die so genannte IDMAP, ein wichtiges Etappenziel auf dem Weg zur totalen NT-Kompatibilität. Jeder Benutzer und jede Gruppe, die Samba den Clients an irgendeiner Stelle präsentiert, wird in Form eines SID (Security Identifier) dargestellt. Samba muss an mehreren Stellen mit SIDs umgehen, unter anderem beim Anmelden an eine Domäne, aber auch bei der Anzeige eines Dateibesitzers oder eines Eintrags in einer Access Control List. Windows-Rechner erwarten hier natürlich keine Linux-User oder Gruppen, sondern die Windows-konforme Darstellung als SID.

Ausstellende Autorität plus Relative Identifier

Ein SID besteht aus zwei Teilen, der so genannten ausstellenden Autorität und einem Relative Identifier (RID). Die ausstellende Autorität ist jede Windows-Maschine ab NT oder Samba ab Version 2.0. Sie kann unterschiedliche Formen annehmen, die wichtigste ist S-1-5-21- x– y– z. X, die Platzhalter y und z sind jeweils 32-bittige Zufallszahlen, die die Eindeutigkeit der Autorität sicherstellen. Jede Installation generiert sich ihren eigenen SID-Anteil. Für einen vollständigen SID wird noch ein 32 Bit langer RID hinzugefügt, sodass sich ein SID als S-1-5-21- x– y– z– RID darstellt.

Mit der Speicherung von SIDs unter Linux hat Samba jedoch ein Prinzip-bedingtes Problem: Dateien haben nur Eigentümer und eine besitzende Gruppe im Unix-Stil und auch die Anmeldung erfolgt grundsätzlich als Linux-UID und nicht als SID. Linux behandelt Benutzer und Gruppen als getrennte Zahlenräume. Das heißt, es gibt einen Benutzer 1000 und eine Gruppe 1000 – und beide haben nichts miteinander zu tun.

Vielgestaltige SIDs

SIDs sind anders strukturiert: Ein SID ist entweder ein Benutzer oder eine Gruppe (oder eine lokale Gruppe oder …). Einem SID zunächst nicht anzusehen, was er repräsentiert. Man muss die ausstellende Autorität danach fragen. Samba 2.2 stellt sich dem Problem mit dem so genannten algorithmischen Mapping. Dabei muss eine eindeutige Abbildung in beide Richtungen sichergestellt sein. Samba 2.2 löst die Transformation zwischen den Linux-IDs und SIDs folgendermaßen:

• Benutzer-RID = UID * 2 + 1000
• Gruppen-RID = GID * 2 + 1001

Das gewährleistet, dass Benutzer grundsätzlich gerade RIDs bekommen und Gruppen ungerade. Von Samba ausgestellte SIDs sind zwischen Benutzer und Gruppe ohne Nachfrage bei der ausstellende Autorität unterscheidbar. Der Offset von 1000 ist notwendig, da Windows die RIDs unter diesem Wert für spezielle Zwecke reserviert. Beispielsweise hat die Gruppe der Domänen-Administratoren immer den RID 512, Domänenbenutzer bekommen den RID 513.

Bei Samba 2.2 verhindert dieses Schema aber, dass eine bestehende Windows-Benutzerdatenbank von einem Domänencontroller abgezogen und unbemerkt einem Samba-PDC untergeschoben werden kann. Ein NT-PDC tut einem nicht den Gefallen, Benutzern nur gerade und Gruppen nur ungerade RIDs zuzuordnen, und Linux-IDs sind leider Integer- und keine Fließkommazahlen.

Wer Samba 2.2 als PDC mit LDAP benutzt, wird im »sambaAccount«-Objekt sicher über das Attribut RID gestolpert sein. Das Attribut legt nahe, dass bereits bei Samba 2.2 mit LDAP der RID frei setzbar sei. Das ist leider nicht der Fall. Einige Stellen in Samba benutzen dieses Attribut tatsächlich, andere aber die algorithmische Umsetzung.

Der Winbind-Daemon übergibt die Benutzerverwaltung

Einen Dienst mit der Aufgabe, SIDs in Linux-IDs und umgekehrt zu wandeln, enthält mit dem Winbindd bereits Samba 2.2. Mit diesem Dämon kann man die gesamte Benutzerverwaltung eines Linux-Rechners an eine Windows-Domäne übergeben. Dazu muss der Samba-Admin die Domäne wie gewohnt betreten. Die folgenden Zeilen in der »smb.conf« reichen als Voraussetzung:

[global]
workgroup = Domäne
security = domain

Das Betreten der Domäne geschieht bei Samba 3 nicht mehr mit dem Befehl »smbpasswd«, sondern mit

net rpc join -U administrator

Der »net«-Befehl sucht sich dabei nicht nur die zu betretende Domäne, sondern auch den PDC selbst.

Der Winbindd bekommt vom Domänencontroller die Liste sämtlicher Benutzer und die aller Gruppen in Form von SIDs. Daraus muss er Linux-geeignete Benutzer- und Gruppen-IDs machen. Dazu benötigt er einen Zahlenraum, in dem er sich frei austoben darf. Unter Samba 2.2 gibt es dazu die Parameter »winbind uid« und »winbind gid«, die Samba 3 in »idmap uid« und »idmap gid« umbenannt hat, die alten Parameter funktionieren jedoch weiter.

Um die Linux-Benutzerverwaltung dem Winbindd zu überlassen, muss der Admin in der Datei »/etc/nsswitch.conf« zwei Einträge vornehmen:

passwd: files winbind
group: files winbind

Damit verweist jeder Zugriff der Glibc auf »/etc/passwd«, zum Beispiel über den Aufruf »getpwnam(3)«, zusätzlich auf das Shared Object »/lib/libnss_winbind.so«, das dann via Winbindd einen Domänencontroller befragt. Damit das funktioniert, muss natürlich die korrekte »libnss_winbind.so« in »/lib« liegen. Bei fertigen Samba-3-Binärpaketen ist dies der Fall. Wer die Quellen selbst kompiliert, findet diese Datei unter »samba/ source/nsswitch/«.

Problem: Workstation-Freigaben

Die erste und zweite Beta von Samba 3.0 folgen dem Konzept, dem Winbindd eine Liste von Linux-IDs zur freien Verfügung zu übergeben, die einen normalen Samba-Server erweitern, um ein Problem zu lösen: Was soll Samba tun, wenn eine Datei auf einem Samba-Share einem Benutzer übergeben wird, der ausschließlich auf einer Workstation im Netz definiert ist? Das klingt zunächst etwas exotisch, ist aber nicht nur möglich, sondern wird tatsächlich benutzt. Der Samba-Server bekommt beim Setzen des Eigentümers einfach einen SID präsentiert, dem die Datei ab jetzt gehört. Samba muss sich für diesen SID eine für diese Datei geeignete Linux-UID aussuchen.

Windows speichert in einem solchen Fall einfach den SID als Objekt ab und gibt ihn auf Anforderung heraus. Künftige Versionen von Samba werden das genau so tun und sich wie NT verhalten. Samba 2 und 3 können den SID nur dann entgegennehmen, wenn er von einer Autorität ausgestellt wurde, zu der der Server Kontakt hat. Das sind entweder der Samba-Server selbst oder alle Domänencontroller, zu denen der Server eine Mitgliedschaft oder Vertrauensstellung unterhält.

Diese Einschränkung ergibt sich, weil Samba entscheiden muss, ob es sich bei einem SID um einen Benutzer oder eine Gruppe handelt. Wird ein Dateibesitzer auf einen SID gesetzt, könnte man noch raten, dass es sich um einen Benutzer handelt, obwohl unter NT auch Gruppen Dateien besitzen können. Einzige Lösung: Samba müsste für einen SID sowohl einen UID als auch einen GID anlegen und die Entscheidung beispielsweise beim Login treffen. Die Beta 3 weist aber unbekannte SIDs noch zurück.

Ein Problem wird immer bleiben: Samba hat keine Chance, ausgewählte Linux-IDs zu einem Namen aufzulösen, wenn sich der gemappte SID nicht zufällig in einer vertrauten Domäne befindet. Aber auch Windows löst dieses Problem nicht: NT 4.0 stellt solche SIDs als »Konto unbekannt« oder gar nicht dar, das GUI von Windows 2000 und höher zeigt den SID in numerischer Form, wenn er in den entsprechenden Dialog passt. Beispiele sind in Abbildung 1 und 2 für Windows NT 4 und 2000 zu sehen.

Samba 3 speichert solche Abbilder in der Datei »winbindd_idmap.tdb«. Sie ist binär, um den Zugriff zu beschleunigen. Linux-Administratoren begegnen Binärdateien mit einem – durchaus berechtigten – Misstrauen. Aus diesem Grund enthält Samba 3 die Werkzeuge »net idmap dump« und »net idmap restore«, die die »winbindd_idmap.tdb« lesbar ausgegeben und auch wieder herstellen. Übrigens ist die Datei Format-kompatibel mit den Dateien von Samba ab 2.2.4, sodass das »net«-Kommando auch für das Backup von modernen 2.2er Systemen verwendbar ist.

Ein bislang ungelöstes Problem bei Samba 2.2 ist der Einsatz von Winbind auf mehreren Maschinen in einem Netz. Jede Maschine wählt sich die Zuordnung von SID zu Linux-ID selbst. Die Entwicklung von IDMAP hat eine Schnittstelle geschaffen, um diese Vergabe von Linux-IDs zentral zu regeln. Es gibt bereits eine Implementation, die IDMAP im LDAP abzulegen – die Entwicklung ist aber noch lange nicht abgeschlossen. IDMAP liefert die Grundlage für drei interessante Erweiterungen von Samba: Die Übernahme von Windows-Domänen, das Gruppen-Mapping und die Unterstützung von Vertrauensstellungen.

Abbildung 1: So zeigt Windows NT 4 einen unbekannten SID.

Abbildung 2: Windows 2000 listet einen unbekannten SID in numerischer Form.

Eine Windows-Domäne übernehmen

Dank der IDMAP-Datenbank ergibt sich die Möglichkeit, bestehende SIDs einer Windows-Benutzerdatenbank bei ihrer Übernahme zu erhalten. Um von einem Windows-Domänencontroller die Daten inklusive der Passwörter zu erhalten, muss Samba die Installation eines NT-4-Backup-Domänencontrollers simulieren. Das heißt, man kann mit Samba die NT-4- und Windows-2000-Domänen im gemischten Modus übernehmen; der einheitliche Windows-2000-Modus verhindert die Installation von NT-BDCs.

Samba wird zu einem BDC der Domäne »WINDOWS« mit den Einstellungen:

[global]
workgroup = WINDOWS
domain master = no
domain logons = yes

Wenn der Admin mit diesen Einstellungen in der »smb.conf« die Domäne per »net rpc join -U Administrator« betritt, wird Samba im Servermanager nicht mehr als Mitglieds-Server oder -Workstation, sondern als Backup Domain Controller geführt. In Abbildung 3 ist der Rechner »delphin« (der Laptop des Autors) als BDC einer Windows-Domäne zu sehen.

Abbildung 3: Samba als BDC »delphin« im Servermanager.

Benutzerdatenbank vom PDC beziehen

Für das Betreten als BDC ist auf jeden Fall ein Administrator erforderlich, ein zum Aufnehmen von Computern in die Domäne berechtigter Benutzer reicht nicht. Im nächsten Schritt soll der PDC ja die Benutzerdatenbank inklusive aller Passwörter ausgeben – dafür sollte man schon Administrator sein.

»net rpc samdump« erlaubt einen Blick in die Benutzerdatenbank, »net rpc vampire« überschreibt die Samba-Benutzerdatenbank mit den Werten, die Windows übermittelt hat. Damit dies funktioniert, muss Samba die Windows-Benutzer und -Gruppen lokal unter Linux anlegen. Dazu bekommt Samba einen Satz von Shellskripten genannt, die dies erledigen. Beispielparameter dafür sind im Kasten “Skripte” zu sehen.

Sind diese Skripte richtig gesetzt, kann der Sysadmin übrigens die Linux-Benutzerdatenbank wie gewohnt mit dem NT-4-Usermanager pflegen. Unter Linux ist der Befehl »groupadd« recht strikt, was Gruppennamen angeht. Darum kommt besser das Skript »creategroup« aus »samba/source/scripts« zum Einsatz. Es erzeugt für Gruppen, die Linux nicht anlegen will, zufällige neue Namen und versucht es damit.

Die Benutzerdatenbank mit den entsprechenden Skripten nachpflegen wird unter Linux und Solaris mit Samba 3.0 möglicherweise nicht mehr notwendig sein. Beide Systeme beherrschen die oben skizzierte Möglichkeit, mit »nss _winbind« und dem Winbindd die Dateien »/etc/passwd« und »/etc/group« dynamisch von einem Domänencontroller zu beziehen.

Dieser Mechanismus ist theoretisch auch dazu geeignet, aus einer von Windows bezogenen Benutzerdatenbank die korrespondierenden Linux-Benutzer dynamisch zu generieren. Dazu muss der Winbindd in der Lage sein, direkt auf die »passdb«-Datenbank zuzugreifen, was er mit der zweiten Beta noch nicht beherrscht. Gerald Carter hat Anfang Juli jedoch angekündigt, diese Möglichkeit implementieren zu wollen.

Die Tatsache, dass Samba die Windows-Domäne als BDC betritt, bedeutet leider auch mit Samba 3.0 nicht, dass es einen BDC komplett zu ersetzen vermag. Samba kann sehr wohl die komplette Benutzerdatenbank en bloc herunterladen, aber die regelmäßigen, Delta genannten Änderungen bekommt Samba leider nicht mit. Auch wird es nicht möglich sein, einen Windows-BDC in einer Samba-Domäne zu benutzen. Dazu implementiert Samba viel zu wenig von dem, was ein Windows-BDC in der Benutzerdatenbank erwartet.

Ein Beispiel sind die Benutzerprivilegien, die Samba (noch) überhaupt nicht benutzt. Denn ist Samba BDC, kann es alles, was nicht interessiert, ignorieren. Aber ein von Samba versorgter Windows-PDC erwartet noch etwas mehr. Ist Samba jedoch sowohl auf dem PDC als auch auf dem BDC installiert, schafft es sehr einfach das, was man mit Windows auch erreicht: Ausfallsicherheit und Lastverteilung. Um das zu erreichen, muss der Admin aber dafür sorgen, dass die Benutzerdatenbank inklusive Domänen-SID auf dem PDC und dem BDC gleich sind.

Das ist am einfachsten mit dem »ldapsam«-Backend machbar – OpenLDAP bringt die notwendigen Replikationsmechanismen bereits mit. Den BDC unterscheidet vom PDC nur die Option »domain master = no«. Das Aufsetzen der korrekten Replikation mit OpenLDAP ist ein recht komplexer Vorgang, der auch einen geübten Admin schnell zwei Stunden Arbeit kostet und darum hier nicht beschrieben wird.

01 [global]
02 add user script = /usr/sbin/useradd "%u"
03 add group script = /usr/local/bin/creategroup "%g"
04 add user to group script = /usr/sbin/gpasswd -a "%u" "%g"
05 delete user from group script = /usr/sbin/gpasswd -d "%u" "%g"
06 set primary group script = /usr/sbin/usermod -g "%g" "%u"
07 delete user script = /usr/sbin/userdel "%u"
08 delete group script = /usr/sbin/groupdel "%g"

Gruppen-Mapping

Eine wesentliche Eigenschaft eines PDC fehlt Samba 2.2: Die Möglichkeit, Gruppenmitgliedschaften von Domänenbenutzern an Mitgliedsmaschinen weiterzugeben. Das ist wichtig, weil Zugriffsrechte auf Domänenrechnern typischerweise nicht pro Benutzer, sondern pro Domänengruppe vergeben werden.

Beispiel: Es existiert eine Domänengruppe »edv«, die als einzige Schreibrecht auf die Freigabe »SERVERProg« bekommen soll. Unter Samba wird das durch die Option

valid users = @edv

gesteuert, ein Mitgliedsserver unter Windows regelt dies im ACL-Editor für Freigaberechte. Um auf Mitgliedsservern Domänengruppen zur Zugriffskontrolle verwenden zu können, muss der Domänencontroller bei Anmeldung des Benutzers die Gruppenmitgliedschaften feststellen und dem Mitgliedsserver mitteilen. Genau dies tut Samba 2.2 nicht, erst Samba 3.0 ist entsprechend erweitert.

Um eine Gruppenzugehörigkeit unter Linux und Samba 3 an Windows weiterzugeben, definiert der Admin eine Abbildung zwischen der Linux- und der Windows-Gruppe. Dazu benutzt er das Programm »net groupmap« und dessen Unterprogramme. »net groupmap list« listet die existierenden Abbildungen auf. Dabei wird der Admin feststellen, dass, obwohl er selbst noch nichts definiert hat, bereits einige Abbildungen existieren. Das hat technische Gründe: Für einige Funktionen setzen Windows-Clients einfach die Existenz dieser Gruppen und ihrer Eigenschaften voraus. Beispielsweise muss es die Gruppe der Domänen-Administratoren immer geben.

Eine typische Anwendung für die Abbildung von Linux- zu NT-Gruppen ist eben jene Gruppe der Domänen-Administratoren. Alle Linux-Benutzer, die als Beispiel Mitglied der Gruppe »adm« sind, sollen auf ihren lokalen Workstations Administrationsrechte bekommen. Dies erreicht das Kommando

net groupmap update rid=512 unixgroup=adm

Der Parameter »rid=512« legt die NT-Gruppe fest, auf die die Linux-Gruppe »adm« abzubilden ist. Um diese spezielle Gruppe zu mappen, ist das »net groupmap update« nötig, da die Abbildung bereits existiert. Wer dagegen eine eigene NT-Gruppe erstellen will, muss zunächst die zugehörige Linux-Gruppe (hier »edv«) zum System hinzufügen:

net groupmap add rid=1000 unixgroup=edv

Dass man selbst einen noch freien RID wählen muss, ist der aktuelle Stand von Samba 3.0 Beta 2. Hier werden die Entwickler vermutlich noch eine Automatik hinzufügen, die einen freien RID für die neue Abbildung aussucht.

Abbildung 4: Vertrauensstellungen unter NT einrichten, wenn Samba auf dem PDC mit Winbindd läuft.

Vertrauensstellungen von Windows

Eine Vertrauensstellung unter Windows ist ein Weg, um reguläre Benutzer der Domäne A in Domäne B genau so zu behandeln, als wären sie aus Domäne B. Vertrauensstellungen setzt Windows zu unterschiedlichen Zwecken ein:

• Delegation der Administration: Der Administrator einer Windows-Domäne hat alle Möglichkeiten, Änderungen in ihr vorzunehmen. Eine vorhandene Abteilungsstruktur kann nun möglicherweise erzwingen, dass die Administrationsrechte nicht für die gesamte Struktur, sondern nur für einen Teil gelten. Mit einer Vertrauensstellung ist jeder Administrator für seine Domäne verantwortlich, die Benutzer können sich jedoch frei über Domänengrenzen hinweg anmelden und Rechte wahrnehmen, sofern sie ihnen zugewiesen wurden.
• Reduzierung der Benutzerzahl auf Domänencontrollern: Der Benutzermanager für Domänen wird ab einer größeren Menge von Benutzern sehr unhandlich. Microsoft spricht davon, dass NT-4-Domänen mit mehr als 40000 Benutzern nicht mehr unterstützt werden. Auch wenn nicht viele Unternehmen von dieser Einschränkung betroffen sind, kann die Benutzerdatenbank einen Domänencontroller belasten. Ein guter Weg, die Belastung zu reduzieren, ist die Aufteilung in unterschiedliche Domänen mit Vertrauensstellungen.

Technisch ist eine Vertrauensstellung zwischen Domänen einer Domänenmitgliedschaft sehr ähnlich. Damit die Domäne A der Domäne B vertrauen kann, müssen die Domänencontroller der Domäne A einen Trust-Account (siehe unten) in Domäne B bekommen. Dieser Trust-Account ist mit einem Workstation-Konto vergleichbar.

Ein Beispiel: Es gibt die beiden Domänen »WINDOWS« und »SAMBA«. In »WINDOWS« sind sämtliche Benutzer angelegt, die Domäne »SAMBA« enthält die Maschinenkonten der Workstations. Die Workstation »USERWKS« sei Mitglied der Domäne »SAMBA«. Was passiert, wenn sich Benutzer »volker« der Domäne »WINDOWS« an der Workstation »USERWKS« anmeldet? Der Weg der Workstation ist es, ihren PDC »SAMBAPDC« zu fragen, ob User »volker« sein Passwort korrekt eingegeben hat. »SAMBAPDC« weiß aber von »WINDOWSvolker« nichts, sondern muss seinerseits den »WINDOWSPDC« fragen.

Die Anfrage des »SAMBAPDC« an den »WINDOWSPDC« läuft über eine gesicherte Verbindung zu dem Net-Logon-Dienst, auf demselben Weg wie die Frage von »USERWKS« an den »SAMBAPDC«. Das Sichern der Verbindung »USERWKS« -> »SAMBAPDC« erfolgt über einen gemeinsamen Schlüssel, der sich anhand des Workstationkontos von »USERWKS« auf dem »SAMBAPDC« errechnet. Um diesen Mechanismus zwischen »SAMBAPDC« und »WINDOWSPDC« einzusetzen, ist ein Workstationkonto für den »SAMBAPDC« auf dem »WINDOWSPDC« nötig, beide müssen sich über das Passwort einig sein.

Nun gibt es für die »SAMBA«-Domäne möglicherweise mehr als einen Domänencontroller. Natürlich will niemand für jeden der Domänencontroller ein eigenes Konto in der »WINDOWS«-Domäne einrichten. Daher teilen sich die »SAMBA«-Domänencontroller ein Konto, den so genannten Trust-Account. Es wird in Windows auf dem »WINDOWSPDC« im Benutzermanager unter »Richtlinien« eingerichtet. Beim Hinzufügen einer Domäne, die »Berechtigt ist, dieser Domäne zu vertrauen«, entsteht letztlich ein Trust-Account auf dem PDC.

Im zweiten Schritt muss der vertrauenden Domäne das Passwort des Trust-Accounts mitgeteilt werden. Dies geschieht auf dem »SAMBAPDC« im selben Menüpunkt. In dem Moment, in dem eine vertraute Domäne hinzugefügt wird, wird das Passwort überprüft und nach einer gewissen Zeit geändert.

Samba-Konfiguration

Ein PDC mit Samba versteht sich auf beide Funktionen: Windows kann einer Samba-Domäne vertrauen, umgekehrt geht es auch, ist aber etwas komplizierter. Für den ersten Teil, Samba als Server, dem eine andere Domäne vertraut, muss der Admin auf dem PDC nur einen Interdomain Trust-Account auf dem bekannten Wege erstellen:

sambapdc:~# useradd windows$
sambapdc:~# smbpasswd -a -i U  windows$
New SMB password:
Retype new SMB password:
Added user windows$.
sambapdc:~#

Danach darf der Admin auf dem »WINDOWSPDC« die Domäne »SAMBA« als »Vertraute Domäne« aufnehmen. Beim Hinzufügen der Vertrauensstellung wird nach einem Passwort gefragt: Es muss genau jenes sein, das er beim Kommando oben verwendet hat.

Die umgekehrte Richtung, nämlich dass Samba als PDC einer anderen Domäne vertraut, ist deutlich komplizierter. »nss_winbind« muss korrekt konfiguriert sein. Einer anderen Domäne vertrauen heißt, dass die Benutzer und Gruppen der fremden Domäne als lokal gelten. Genau dafür ist der Winbindd gemacht. Anfangs nur für einen einzigen Mitgliedsserver vorgesehen, kann der Winbind heute auch auf einem PDC laufen und die Benutzer der vertrauten Domänen auch der lokalen Maschine zur Verfügung stellen.

Samba vertraut Windows

Läuft Samba auf dem PDC mit Winbindd, muss man auf der vertrauten Domäne einen Interdomain Trust-Account einrichten. Den entsprechenden Dialog zeigt Abbildung 4. Auf dem Samba-PDC, der einer anderen Domäne vertraut, richtet folgendes Kommando das Kennwort für die Domäne ein:

sambapdc:~# net rpc trustdom establish windows
Password:
sambapdc:~#

Damit sind alle Benutzer der Domäne »WINDOWS« auch für die Rechner in der Domäne »SAMBA« verfügbar. Von den Fehlermeldungen, die beim Erzeugen der Vertrauensstellung auftauchen, sollte man sich nicht verwirren lassen. Sie sind (hoffentlich) bis zur endgültigen Release der 3.0 behoben.

Abbildung 5 zeigt den Login-Dialog einer NT-4.0-Workstation »NT4WKS«, die Mitglied der Domäne »SAMBA« ist. Die Domäne vertraut den beiden Domänen »WINDOWS« und »NT4DOM«. Man kann aus insgesamt vier Benutzerdatenbanken auswählen.

Abbildung 5: NT-Login-Dialog einer Workstation »NT4WKS«, die Mitglied der Domäne »SAMBA« ist, mit Vertrauensstellungen.

Fazit und Blick nach vorn

In vielen Bereichen reicht Samba 2 nicht an die Domänenfunktionen von Windows NT 4 heran. Mit Version 3 kommt es aber sehr wichtige Schritte nach vorn – dieser Beitrag beschreibt die meisten. Das Entwicklerteam hat es mit Samba 3.0 geschafft, die Funktionen von NT 4 im Wesentlichen zu implementieren. Hinzu kommen einige wichtige Eigenschaften von Windows 2000. Über die Activ-Directory-Mitgliedschaft hinaus kann man zum Beispiel auch Windows-2000- und XP-Druckertreiber bei einem Samba-Server hinterlegen, was mit NT 4 nicht möglich ist.

Eine sehr häufig gewünschte Eigenschaft bleibt auch Samba 3.0 schuldig: Es kann nicht als Active-Directory-Domänencontroller fungieren. Am Code wären dazu zwar kaum Änderungen notwendig, doch aus strukturellen Gründen kann Samba allein dieses Ziel nie erreichen. Die wesentlichen Entwicklungen dafür müsste das OpenLDAP-Team[4] beisteuern – hier wäre vieles zu erweitern. Als Beispiel sei nur die Unterstützung von ACLs im Windows-Stil für LDAP-Objekte genannt. Wer am Fortschritt in dieser Richtung interessiert ist, der möge sich an der OpenLDAP-Entwicklung beteiligen. (jk)