Samba in einer homogenen "nicht Windows" Umgebung¶

Dies ist der einfachste Anwendungsfall und wird benutzt, wenn einige Geräte im Netzwerk angeschlossen sind, die Kerberos und CIFS/SMB unterstützen, aber nicht NFS. Zum Beispiel ein Router oder Embedded Devices wie TV-Set-Top Boxen. In diesem Fall reicht ein Samba-Server und ein Kerberos DC (KDC).

In der Konfigurationsdatei /etc/samba/smb.conf muss folgende Anpassung im Abschnitt "[GLOBAL]" gemacht werden:

security = ADS
realm = MY.REALM.ROOT
kerberos method = system keytab
encrypt passwords = true

Zusätzlich muss man noch ein passender Kerberos-Key in der Keytab des Servers hinterlegt werden.

sudo kinit some_new_admin/admin
ktadd cifs/server.my.realm.root
addprinc -randkey cifs/server.my.realm.root 

Samba in einer heterogenen Umgebung mit Windows Clients¶

Aktuell ist die einzige Variante eines ActiveDirectory mit vollem Funktionsumfang ein Windows-Server als ActiveDirectory-Server. Der MIT- und Heimdal-Implementierungen von Kerberos können sich mit dem KDC des ActiveDirectory synchron halten und auch das LDAP-Directory kann man mit OpenLDAP spiegeln. Dies macht jedoch nur in größeren Netzwerken Sinn, da jeder der Open Source Kerberos-Clients ohne weiteres in der Lage ist, sich gegen ActiveDirectory zu authentifizieren bzw. diesen als KDC zu nutzen.

Soll in eine solche Umgebung ein Samba Datei-Server eingebracht werden, läuft alles wie im vorherigen Szenario, nur dass noch "weitere" Keys benötigt werden. Das kann man bequem über folgenden Befehl erledigen.

sudo net ads join -U Administrator%Passwort  

Samba mit Kerberos und PDC als FallBack¶

Dieses Szenario ist aktuell die einzige Möglichkeit, Windows-Rechnern einen SMB-Share zur Verfügung zu stellen, wenn kein "echter" ActiveDirectory-Server zur Verfügung steht. Dazu nutzt man den beschriebenen "Sonderfall" des Samba-Dienstes aus, dass dieser noch Anmeldungen (Logins) mit User-Credentials entgegen nimmt und gegen sein "passdb backend" authentifiziert, obwohl er nur ActiveDirectory-Benutzer zulassen sollte.

Nachteil dieser Variante ist, dass kein echtes "Single Sign On" (SSO) mehr möglich ist. Es wird immer zwei Passwörter geben, welche manuell synchron gehalten werden müssen. Das kann auch nicht gelöst werden, wenn Samba als "passdb backend" LDAP nutzt. Das Samba-Schema benutzt zwei weitere Password-Felder (sambaLMPassword und sambaNTPassword). Das Werkzeug smbpasswd setzt diese beiden und das Standart-Feld userPassword korrekt.

Kerberos kann LDAP als KeyStore benutzen oder LDAP kann mittels des SASL-Modus Kerberos zur Authentifizierung nutzen. In beiden Fällen gerät das Gespann Samba/Kerberos aus dem Tritt, sobald ein Benutzer von einem Client aus sein Password ändert. Entweder überschreibt smbpasswd den SASL-Modus oder Kerberos ändert userPassword, ohne die weiteren Felder nach zu ziehen. Auch wenn beide Authentifizierungs-Information in der gleichen Datenbank liegen, existieren de facto zwei Schlüssel-Datenbanken, von der der jeweils andere Dienst keine Kenntnis hat.

Der Vorteil der einheitlichen Benutzer-/Passwortverwaltung durch LDAP geht damit leider verloren. Wenn der Administrationsaufwand für die Synchronisation der User-ID/Group-ID über alle System geringer ist als das Einrichten und Verwalten eines LDAP-Servers, kann man auf LDAP an dieser Stelle auch verzichten.

Da die Passwörter sowohl bei Kerberos als auch bei Samba als Hashes/Keys gespeichert werden, ist eine nachträgliche Synchronisierung nicht möglich. Das Password muss vor dem Hashing auf das jeweils andere Backend gespiegelt werden. Folgende Möglichkeiten existieren:

• Kerberos Passwortänderung am Client (kpasswd): Unter Linux kann man die Änderung des Passworts mittels PAM abfangen und an Samba übergeben. Dazu gibt es das PAM-Modul smbpass (siehe SAMBA-Doku: pam_smbpass.so 🇩🇪)

• Passwortänderung von Windows-Clients (smbpasswd): Zu diesem Zweck gibt es unter Samba die Möglichkeit, auf dem Server ein Skript oder Programm aufzurufen, um die Passwortänderung weiterzuleiten (siehe SAMBA-Doku: passwd chat 🇬🇧).

Sonstige Möglichkeiten¶

Neben diesen Varianten gibt es noch die Möglichkeit, Samba in Version 4 selber zu bauen und als "echten" ActiveDirectory-Server in Betrieb zu nehmen. Dies ist derzeit jedoch für den Produktiveinsatz nicht zu empfehlen und daher auch nicht Teil dieses Artikels (Stand: Dezember 2011).

Als letzte Möglichkeit könnte man Windows-Clients so "patchen", dass sie sich direkt gegen Kerberos authentifizieren können und so kein ActiveDirectory nötig ist (siehe pGina-Authentication for Windows 🇬🇧).