LDAP unter Samba

In der Vergangenheit gab es in den Entwicklerversionen verschiedene Ansätze, Samba an LDAP anzubinden. Seit der Release 2.2.3a existiert eine solche erstmals in der Produktionsversion. Damit lassen sich jetzt Single-Sign-On-Server unter Linux aufsetzen.

Immer mehr Programme und Dienste können für die unterschiedlichsten Zwecke das Protokoll LDAP einsetzen - mit der Anfang Februar freigegebenen Version 2.2.3a zählt auch Samba dazu. Damit gehört die Samba-LDAP-Anbindung erstmals zum Lieferumfang der Produktionsversion, was den Funktionsumfang des freien Pakets in Richtung PDC (Primary Domain Controller) für Windows-Domänen erweitert. Da die Inbetriebnahme einige Stolperfallen birgt, beschreibt dieser Artikel eine Neuinstallation der LDAP-Anbindung von Samba. Die dafür verwendeten Dateien stehen zum Download bereit.

LDAP ist eine Datenbank zum Ablegen von strukturierten Objekten. Jedes kann mit einer Menge von Attributen ausgestattet sein. Die für ein Objekt notwendigen und die darüber hinaus erlaubten Attribute legt eine Objektklasse fest. Ein Objekt kann mehreren Klassen angehören, um unterschiedliche Eigenschaften auszudrücken.

Bei jeder Anbindung von Programmen an LDAP steht am Anfang die Frage, welche Daten zur Disposition stehen. Samba legt dort die NT-Benutzerdaten ab, das heißt den Inhalt der Datei smbpasswd mit den verschlüsselten Benutzerpasswörtern. Darüber hinaus hat Samba mit der LDAP-Anbindung einen weiteren Schritt in Richtung NT-Domänencontroller getan. Ohne SAM (Security Account Manager), die Benutzerkontendatenbank von NT 4.0, im LDAP ist Samba nicht in der Lage, für jeden Benutzer individuell das Logon-Script oder den Pfad des Profils festzulegen. Man kann zwar mit Makroersetzungen, etwa über

logon script = %U.bat

individuelle Login-Scripts zuordnen, aber diese Einstellung gilt global für alle Domänenbenutzer und lässt sich nicht individuell ändern.

Die gesamte Konfiguration in diesem Artikel geht davon aus, dass der LDAP-Server und die -Clients auf einer einzigen Maschine laufen. Passwörter, insbesondere die in dieser Hinsicht kritischen SMB-Passwörter, gehen zwischen dem LDAP-Server und Samba im Klartext über die Verbindung. Das ist nicht akzeptabel, wenn ein echtes Netz dazwischen liegt. Sowohl OpenLDAP als auch Samba können LDAP-Abfragen in TLS (Transport Layer Security) einpacken, so dass niemand die Verbindung belauschen kann. Für diese Konfiguration liefert das LDAPv3-HOWTO von www.bayour.com eine hervorragende Referenz.

Programmierung und Tests erfolgten bei den Samba-Entwicklern mit OpenLDAP 2 und den entsprechenden Client-Bibliotheken. Dieser Artikel beschreibt die Installation auf einer SuSE 7.3, die OpenLDAP in der (ausreichenden) Version 2.0.12 beinhaltet, aktuell ist zum Zeitpunkt dieses Artikels Release 2.0.23. Voraussetzung für das weitere Vorgehen sind die Pakete nss_ldap, openldap2, openldap2-client, openldap2-devel und pam_ldap aus der Serie n. Via rpm -q <Paketname> lässt sich prüfen, ob sie schon vorhanden sind, fehlende muss man via YaST oder rpm aufspielen.

In /etc/openldap/slapd.conf erfolgt die Konfiguration des OpenLDAP-Servers, Listing 1 zeigt, wie sie für das Beispiel des LDAP-Baums ‘dc=samba,dc=org’ aussieht. Das verschlüsselte Passwort in der Option rootpw erzeugt das Kommando slappasswd, es gewährt vollen Zugriff auf das gesamte LDAP-Verzeichnis für den Benutzer unter rootdn. Das Passwort liegt zwar als Hashwert vor, die Datei slapd.conf sollte aber noch besser geschützt werden als die Datei /etc/shadow, die ebenso verschlüsselte Passwörter enthält. Insbesondere wenn Samba die Benutzerpasswörter im LDAP ablegen soll, ist Vorsicht geboten, da diese Passwörter mit Klartextpasswörtern gleichwertig sind. Dies liegt daran, dass man mit einem modifizierten smbclient den Hashwert direkt zur Authentifizierung benutzen kann - ohne crack einsetzen zu müssen.

Vor dem OpenLDAP-Start via rcldap start ist die Datei samba.schema aus dem Verzeichnis examples/LDAP der Samba-Quellen nach /etc/openldap/schema zu kopieren.

Nach dem ersten Hochfahren von OpenLDAP ist das LDAP-Verzeichnis leer. Die Option ‘suffix’ teilt dem slapd mit, für welchen Teil des Verzeichnisbaums er verantwortlich ist. Objekte unterhalb dieses Teilbaums muss man manuell anlegen, insbesondere den Container, der die Wurzel des Teilbaums aufnimmt, im Beispiel für dc=samba,dc=org. Für diesen bietet sich die Objektklasse organization an, einziges zwingendes Attribut ist der Name der Organisation ‘o’. Folgende samba.ldif-Datei beschreibt die Wurzelorganisation:

dn: dc=samba,dc=org
objectclass: organization
o: samba

Der Aufruf

ldapadd -D cn=admin,dc=samba,dc=org -x -W -f\ samba.ldif

fügt samba.ldif in das Verzeichnis ein. Die Option ‘-D’ gibt den Namen an, mit dem man sich gegenüber dem LDAP-Server authentifizieren möchte. Jetzt lassen sich neue Benutzer anlegen. Damit ein Benutzer im LDAP auch Unix benutzen kann, muss er der Objektklasse ‘posixAccount’ angehören. Das dazugehörige Objekt benötigt einige Attribute:

dn: cn=admin,dc=samba,dc=org
objectclass: posixAccount
cn: admin
uid: admin
uidNumber: 1000
gidNumber: 100
homeDirectory: /home/admin
loginShell: /bin/bash

ldapadd fügt das Objekt dem Verzeichnis hinzu. Anwender können die so im LDAP abgelegten Objekte via ldapsearch abfragen. Um vernünftig mit dem Kommando arbeiten zu können, sollte man in /etc/openldap/ldap.conf folgende Werte vorgeben:

URI ldap://localhost:389/
BASE dc=samba,dc=org

Danach liefert ldapsearch -x die eingefügten Objekte aus dem Verzeichnis.

Um Samba als PDC mit LDAP-Anbindung betreiben zu können, muss Linux seine Benutzerinformationen ebenfalls aus dem LDAP-Baum beziehen. Dazu dient der nsswitch-Mechanismus der Glibc, der sämtliche Anfragen auf den Dateien /etc/passwd und /etc/group an dynamische Bibliotheken weiterleitet. Zum Paket nss_ldap gehört eine solche Bibliothek, die die Anfragen an einen LDAP-Server weiterleitet. Mit den in der /etc/openldap/ldap.conf konfigurierten Standardwerten ist auch nss_ldap fast fertig konfiguriert. Es fehlen in /etc/nsswitch.conf lediglich die Zeilen

passwd: files ldap
group: files ldap

Damit sind die in LDAP angelegten posixAccount-Objekte unter Unix als Benutzer sichtbar, wovon man sich mit dem Aufruf getent passwd überzeugen kann. Erscheinen die Benutzer aus dem LDAP nicht in der Liste, könnte die Ursache im allseits beliebten Name Service Caching Daemon nscd liegen. Mit killall nscd wird man ihn los; stellt man zusätzlich noch in /etc/rc.config die Variable START_NSCD auf ‘no’, bereitet er nie wieder Schwierigkeiten.

Passwörter in LDAP
Passwörter für die Unix- und LDAP-Authentifizierung legt das System im Attribut userPassword ab. Dieses enthält gehashte Passwörter, die sich nicht von Hand setzen lassen. Für einen Benutzer ‘volker’ setzt der folgende Befehl das Passwort:

ldappasswd -D cn=admin,dc=samba,dc=org -x -W-S cn=volker,dc=samba,dc=org

Dabei bezeichnet Argument ‘-D’ den Benutzer für die Authentifizierung beim LDAP (‘admin’), das Passwort wird für den zweiten angegebenen Benutzer (‘volker’) gesetzt. Existiert das Benutzerpasswort im LDAP, können sich Anwender über das PAM-Modul für LDAP pam_ldap authentifizieren. Es erfordert keine weitere Konfiguration, es greift genau wie nss_ldap auf /etc/openldap/ldap.conf zu. Lediglich die nur für die Verwendung der LDAP-Module vorgesehenen Dienste sind entsprechend einzurichten, /usr/share/doc/packages/pam_ldap liefert Beispielkonfigurationen dazu. Listing 2 zeigt, wie dies für den sshd aussieht. Wie in Listing 3 zu sehen, können sich mit dieser Konfiguration normale Benutzer bei der LDAP-kontrollierten Maschine anmelden. Es zeigt auch die Wirkung der ACL-Einträge (Access Control Lists) in /etc/openldap/slapd.conf. Hätte sich der Benutzer volker beim LDAP mit

volker@vm:~> ldapsearch -x -D cn=volker,\dc=samba,dc=org -W uid=volker

unter seiner eigenen Identität angemeldet, hätte er zusätzlich das Attribut userPassword gesehen.

Übersetzen von Samba
Um Samba mit LDAP-Fähigkeiten auszustatten, muss man es neu übersetzen. Dies liegt zum einen daran, dass zur Zeit keine Distribution die notwendige Version 2.2.3a mit ausliefert. Zum anderen schließen sich der Zugriff auf LDAP und smbpasswd-Datei derzeit noch aus. Das wird sich erst ab Release 3.0 ändern. Da die Standardinstallation immer mit einer smbpasswd arbeitet, folgt daraus der Zwang zum Kompilieren.

cd samba-2.2.3a/source
./configure --with-ldapsam
make
make install

Ohne Änderungen installiert sich Samba2.2.3a unter /usr/local/samba. Die smb.conf findet sich dort im Unterverzeichnis lib/, die Programme sind unter bin/ zu finden. Will man dieses Samba bei der SuSE automatisch starten lassen, empfiehlt es sich, die Startdatei /etc/init.d/smb an die neuen Verzeichnisse anzupassen. Die wesentlichen Einträge finden sich am Anfang der Datei:

SMB_BIN=/usr/local/samba/sbin/smbd
NMB_BIN=/usr/local/samba/sbin/nmbd
SMB_CONF=/usr/local/samba/lib/smb.conf
SMB_PID=/usr/local/samba/var/locks/smbd.pid
NMB_PID=/usr/local/samba/var/locks/nmbd.pid

Die smb.conf muss bei einem selbst kompilierten Samba unter /usr/local/samba/lib stehen. Listing 4 zeigt, wie sie für einen LDAP-PDC aussieht. ldap server und ldap port legen den zu befragenden LDAP-Server fest, ldap suffix gibt den LDAP-Teil an, in dem Samba die User Accounts suchen soll. Die benutzte Methode legt ldap filter fest. ldap admin dn bezeichnet den Benutzernamen, mit dem sich Samba am LDAP anmelden soll - in einfachen Konfigurationen die in der slapd.conf angegebene root dn. Dies muss jedoch nicht der Fall sein. Die einzige Bedingung ist, dass der ldap admin dn sämtliche Felder des sambaAccount schreiben darf.

pdbedit für die Attribute
Um sich als ldap admin dn beim LDAP-Server anzumelden, beherrscht Samba momentan nur die Simple Authentication. Das Passwort für die Anmeldung legt es nicht in der smb.conf ab, die häufig für alle Benutzer im System lesbar ist, sondern in der geschützten secrets.tdb. Der Passworteintrag dort erfolgt via smbpasswd -w <password>. Mit diesen Vorbereitungen lassen sich posixAccount-Objekte analog zu smbpasswd -a user im LDAP um Samba-Attribute erweitern.

vm:/usr/local/samba/bin # ./pdbedit -a -u volker
New SMB password:
Retype new SMB password:
username: volker
user ID/Group: 1001/100
user RID/GRID: 3002/1201
Full Name: volker
Home Directory: \\\volker
HomeDir Drive:
Logon Script:
Profile Path: \\\volker\profile
vm:/usr/local/samba/bin #

Ist der Benutzer im LDAP vollständig angelegt, lassen sich mit pdbedit die anderen Eigenschaften wie das Heimatlaufwerk, den Profilpfad et cetera komfortabel festlegen.

vm:/usr/local/samba/bin # ./pdbedit -h '\\vm\volker' -d u: -p
'\\vm\volker\profile' -u volker
username: volker
user ID/Group: 1001/100
user RID/GRID: 3002/1201
Full Name: volker
Home Directory: \\vm\volker
HomeDir Drive: u:
Logon Script:
Profile Path: \\vm\volker\profile
vm:/usr/local/samba/bin #

Passwörter für die via pdbedit angelegten Benutzer lassen sich wie üblich per smbpasswd modifizieren.

Um eine Windows-2000-Workstation in die Samba/LDAP-Domäne aufzunehmen, sind die gleichen Schritte erforderlich wie bei einem Samba-PDC ohne LDAP. Für jede Workstation muss im LDAP ein Unix-Account existieren, dessen Name dem der Workstation mit einem \$ am Ende entspricht. Danach betritt man von der Workstation aus die Domäne, die dabei ihr Workstationkennwort setzt. Dazu muss im LDAP schon ein Root-Account existieren. Er benötigt kein Unix-Passwort, jedoch ein SMB-Passwort, das mit pdbedit zu setzen ist. Nach dem erfolgreichen Betreten der Domäne kann sich der oben konfigurierte Benutzer ‘volker’ an der Workstation anmelden. Die zugeordnete Konfiguration wird aktiv sein.

Dank der vorgestellten Optionen erweitert Samba deutlich seine Fähigkeiten als Primary Domain Controller. Nutzt man die Replikationsfähigkeit von OpenLDAP, lässt sich einfach ein Backup Domain Controller des Samba/LDAP-PDC aufsetzen. Dieser muss seinen eigenen OpenLDAP-Server fragen, der eine Kopie des PDC-LDAP-Servers ist. Die wesentlichen Einstellungen auf dem BDC lauten dann nur noch

domain master = no
domain logons = yes

Alle anderen Einstellungen werden vom PDC übernommen. Wenn jetzt WINS korrekt aufgesetzt ist, suchen sich die Workstations zum Anmelden einen beliebigen Domänencontroller und kontaktieren für die Passwortänderungen ausschließlich den PDC. Per slurpd kann der die neuen Daten an die Backups replizieren. Aus den oben genannten Gründen muss dies unbedingt per TLS verschlüsselt erfolgen. Vor leichtfertigem Ausprobieren in Produktivumgebungen sei allerdings gewarnt: Fehler in der PDC-Konfiguration können dazu führen, dass sich an den Windows-Systemen keine Benutzer mehr anmelden können.

Volker Lendecke