Rhythmuswechsel

Im ersten Teil des Tutorials stand der Einsatz von Samba als Stand-alone-Server im Mittelpunkt. Wesentlich daran ist, dass Samba die Benutzer und Passwörter selbst kennt und verwaltet. In den meisten Firmen existiert heute jedoch schon eine zentrale Benutzerverwaltung, entweder noch in Form einer NT4-kompatiblen Domäne oder eines Active Directory. Samba ist selbstverständlich in der Lage, die dort verwalteten Benutzer und Gruppen zu verwenden. Wie das funktioniert, beschreibt dieser zweite Teil.

Wesentlich für die Authentifizierung von Benutzern ist der Parameter security, der fünf Einstellungen kennt:

[share] ist veraltet und sollte nicht mehr zum Einsatz kommen. Mit dieser Einstellung lassen sich einzelne Benutzer nicht unterscheiden, jede Freigabe bekommt ein Passwort.

[user] ist die Standardeinstellung, mit der Samba Benutzer und Passwörter selbst verwaltet. Dies gilt für Stand-alone-Server ebenso wie für Domänencontroller (DC), die im dritten Teil des Tutorials Thema sein werden.

[server] ist ebenfalls veraltet und man sollte darauf verzichten. Wurde durch security=domain ersetzt.

[domain] bewegt Samba dazu, mit NT-konformen Mitteln die Authentifizierung an einen DC zu delegieren. Aus Sicht des Samba-Clients ist dies gleichwertig mit security=user, der Unterschied liegt ausschließlich darin, wie Samba die Passwörter überprüft.

[ads] ist in vielerlei Hinsicht äquivalent zu security=domain, nur dass Samba dem Client zusätzlich Kerberos als Authentifizierungsmethode anbietet.

Damit Samba die Benutzerauthentifizierung einer Domäne verwenden kann, muss der Server als Erstes die Domäne betreten. Mit diesem Schritt erstellt der Administrator ein Maschinenkonto in der Domäne mit einem zufällig gewählten Passwort für dieses Konto. Existiert schon ein Konto für die Maschine, so wird nur das Passwort auf einen neuen, zufälligen Wert gesetzt.

Beitritt zu einer Windows-Domäne

Das Maschinenkonto ist eine Voraussetzung, um zwischen dem Mitgliedsserver und der Domäne eine Vertrauensstellung herzustellen. Diese ist nicht so sehr notwendig, damit der DC feststellen kann, dass der Samba-Server Berechtigungen in der Domäne hat, sondern die umgekehrte Authentifizierung ist wichtig: Der Samba-Server muss sich überzeugen können, dass der DC – der letztlich die Passwortüberprüfung durchführt – wirklich vertrauenswürdig ist. Ohne diese Überprüfung stünden Windows-Domänen vor dem gleichen Problem wie NIS oder ein nicht sicher eingerichtetes nss ldap/pam ldap: Jeder, der die IP-Adresse des Servers mit der Benutzerdatenbank fälscht, kann sämtliche Mitgliedsrechner übernehmen.

Zum Betreten einer Domäne muss man in der smb.conf bei workgroup den Domänennamen angegeben und den Parameter security = domain setzen:

[global]
workgroup = w2k3ad
security = domain

Jetzt kann der Administrator den Befehl net rpc join absetzen:

server:/root # net rpc join -U Administrator
Enter Administrator's password:
Joined domain W2K3AD.
server:/home/vlendec #

Mit diesem Schritt erzeugt der net-Aufruf das Maschinenkonto in der Domäne. Er hat zudem das Passwort auf einen zufälligen Wert gesetzt. Der Name des Maschinenkontos ist der Wert des Parameters netbios name, der standardmäßig mit dem Hostnamen der Maschine vorbelegt ist. Mit den obigen Einstellungen erzeugt der Aufruf also das Maschinenkonto unter dem Namen server.

net rpc join speichert das Maschinenpasswort des Servers in der Datei secrets.tdb, die typischerweise in /etc/samba/ liegt. Via tdbdump secrets.tdb kann man es sich ansehen. Geht die Datei secrets.tdb aus irgendwelchen Gründen verloren, ist die Domänenmitgliedschaft des Samba-Servers zerstört, ein erneutes net rpc join erstellt sie neu.

Im Beispiel diente zum Betreten der Benutzer „Administrator“. Es ist klar, dass spezielle Privilegien in der Domäne zum Betreten notwendig sind, der Vorgang legt ja ein neues Benutzerkonto an. Windows kann dieses Recht an Nicht-Administratoren delegieren, Samba genügt zum Betreten der Domäne ein entsprechend privilegierter Account.

Wenn Samba der Domäne erfolgreich beigetreten ist, muss man den smbd neu starten. Verbindet sich jetzt ein Benutzer, fragt der smbd bei einem DC nach, ob das Passwort richtig ist.

Der nächste Fall: Active Directory

Benutzt man den Modus security=domain, verbindet sich Samba mit NT4-kompatiblen Methoden mit den Domänencontrollern. Dies ist zur Authentifizierung das NTLM-Verfahren (NT LAN-Manager) in seinen unterschiedlichen Ausprägungen bis hin zu NTLMv2, das Samba auch unterstützt, die Benutzerverwaltung erfolgt über sogenannte RPC-Methoden. Mit Windows 2000 hat Microsoft Active Directory eingeführt, das zur Authentifizierung bevorzugt Kerberos einsetzt und zur Benutzerverwaltung ein LDAP-Verzeichnis anbietet. Die Frage, ob man Samba besser im Modus security=domain oder security=ads betreiben soll, lässt sich nicht einfach beantworten. Als Entscheidungshilfe folgen ein paar Argumente für und gegen security=ads.

Jedes Active Directory kann Samba-Server im Modus security=domain als Mitglied aufnehmen. Es ist ein häufig anzutreffendes Missverständnis, dass dies nur für Domänen im sogenannten „Mixed Mode“ gilt. Selbst Domänen im Windows-2003-Infrastruktur-Modus sind in der Lage, NT-kompatible Mitglieder aufzunehmen. Das einzige, was nur Mixed-Mode-Domänen tun, ist die Aufnahme von NT4-Backup-Domänencontrollern (BDC). Da Samba aber ohnehin kein solcher BDC werden kann, ist dieser Aspekt irrelevant.

Wie man einem Active Directory beitritt und welche Role Kerberos dabei spielt lesen Sie in der Printausgabe der iX (ab 20. März am Kiosk).

Mehr Infos

iX-TRACT

• Samba kann über den Parameter „security=…“ die Passwortüberprüfung an externe Systeme delegieren.
  
• In Windows-Umgebungen lassen sich für die Authentifizierung NT-Domänen oder ein Active Directory verwenden.
  
• Winbind bindet die Kerberos-gesicherte AD-Benutzerverwaltung in Unix-Systeme ein.

Mehr Infos

Tutorialinhalt

Teil I: Stand-alone-Samba-Server (iX 3/2008, S. 142)
Teil II: Mitgliedsserver in einer Windows-Domäne (iX 4/2008, S. 146)
Teil III: Ein Samba-Server als PDC (iX 5/2008, S. 140)

(avr)