Samba als Domain Member ist die saubere Lösung, wenn ein Linux-Fileserver in eine bestehende Windows-Active-Directory-Domäne eingebunden werden soll. Der Server selbst wird dabei nicht zum Domänencontroller, sondern verhält sich wie ein Mitglied der Domäne. Winbind übersetzt AD-Benutzer und Gruppen in lokale IDs, Kerberos übernimmt die Authentifizierung und Samba stellt die Freigaben im SMB-Protokoll bereit.

Wichtig ist die Reihenfolge. Wer zuerst an der smb.conf schraubt und DNS, Zeit oder Hostname überspringt, baut sich die Probleme nur später wieder ein. Deshalb gehen wir hier in einer festen Reihenfolge vor und prüfen nach jedem Kernschritt, ob die Grundlage wirklich stimmt.

Voraussetzungen

Bestehende Windows-AD-Domäne mit funktionierendem Domain Controller
Ein Debian- oder Ubuntu-Server als künftiger Fileserver
Sudo-Rechte oder Root-Zugang
Direkter Zugriff auf DNS, Zeitquelle und AD-Credentials

Wichtig für das Verständnis: Dieser Artikel baut stark auf den Linux-Grundlagen auf. Wenn du mit SSH, Rechten oder Logs noch unsicher bist, helfen dir diese Grundlagen zuerst: SSH-Key-Authentifizierung einrichten, Linux-Benutzer, Gruppen und Rechte verstehen und Logs lesen mit journalctl und /var/log.

Schritt 1: DNS, Hostname und Zeit vorab prüfen

Active Directory lebt von drei Dingen, die oft unterschätzt werden: DNS, Hostname und Zeit. Wenn DNS auf falsche Server zeigt, der Hostname nicht sauber auflösbar ist oder die Uhr zu weit abweicht, funktioniert Kerberos später nicht zuverlässig.

hostnamectl

host -t SRV _ldap._tcp.DEINE-DOMAENE.LOCAL
host -t SRV _kerberos._tcp.DEINE-DOMAENE.LOCAL

getent hosts $(hostname -f)

timedatectl status

Die wichtigste Faustregel: Der Server sollte den Domain Controller per DNS finden und nicht nur irgendeinen Internet-DNS. Für Kerberos sind Zeitabweichungen problematisch, deshalb sollte die Uhr synchron sein.

Verifizieren: Der Schritt ist erfolgreich, wenn die SRV-Records der Domäne gefunden werden, der Hostname sinnvoll aufgelöst wird und die Systemzeit nicht deutlich von der AD-Zeit abweicht.

Schritt 2: Pakete installieren

Für einen Samba-Domain-Member brauchst du mehrere Pakete: Samba selbst, Winbind, Kerberos-Werkzeuge und Hilfsprogramme für Tests und ACLs.

sudo apt update
sudo apt install samba winbind libpam-winbind libnss-winbind krb5-user smbclient attr acl dnsutils chrony

Die Paketgrundlagen hinter diesem Schritt erklärt unsere Anleitung Pakete verwalten mit apt und dpkg unter Debian/Ubuntu.

Verifizieren: Der Schritt ist erfolgreich, wenn alle Pakete installiert sind und die wichtigsten Werkzeuge wie wbinfo, net, smbclient und kinit verfügbar sind.

Schritt 3: Kerberos testen

Bevor du Samba in die Domäne aufnimmst, muss Kerberos grundsätzlich funktionieren. Das ist der einfachste frühe Test, ob DNS und Zeit bereits halbwegs stimmen.

sudo nano /etc/krb5.conf

Ein minimaler Startpunkt:

[libdefaults]
    default_realm = DEINE-DOMAENE.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = true

Dann ein Testticket holen:

kinit administrator@DEINE-DOMAENE.LOCAL
klist

Verifizieren: Der Schritt ist erfolgreich, wenn kinit kein Fehlerwort ausgibt und klist ein gültiges Ticket zeigt.

Schritt 4: Samba und Winbind konfigurieren

Jetzt kommt die eigentliche Samba-Konfiguration. Für die meisten KMU-Umgebungen ist idmap rid der verständlichste Startpunkt, weil die Zuordnung der IDs deterministisch bleibt.

sudo nano /etc/samba/smb.conf

Ein kompakter Grundaufbau:

[global]
    workgroup = DEINE-DOMAENE
    realm = DEINE-DOMAENE.LOCAL
    security = ADS
    kerberos method = secrets and keytab

    winbind use default domain = yes
    winbind offline logon = yes

    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config DEINE-DOMAENE : backend = rid
    idmap config DEINE-DOMAENE : range = 2000000-2999999

    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes

Die ACL-Optionen sorgen dafür, dass Windows-ähnliche Berechtigungen sauber in Extended Attributes abgelegt werden. Das ist der Teil, der später für den Fileserver-Alltag entscheidend ist.

Verifizieren: Prüfe die Konfiguration mit testparm. Wenn dort keine Syntaxfehler erscheinen, ist die Basis in Ordnung.

Schritt 5: Domain-Join durchführen

Jetzt wird der Linux-Server Mitglied der Domäne. Dazu nutzt du den klassischen Join-Befehl.

sudo net ads join -U administrator

Wenn der Join erfolgreich war, schreibt Samba die notwendigen Informationen in seine lokale Datenbank und Schlüsseldateien.

Verifizieren: Direkt danach sollte net ads testjoin ein erfolgreiches Ergebnis liefern.

Schritt 6: Dienste und NSSwitch aktivieren

Damit der Server AD-Benutzer und Gruppen auch im System sichtbar macht, brauchst du Winbind und passende NSSwitch-Einträge.

sudo systemctl enable --now smbd nmbd winbind

In /etc/nsswitch.conf sollten diese Zeilen Winbind enthalten:

passwd: files systemd winbind
group: files systemd winbind
shadow: files systemd

Wichtig: Winbind gehört in passwd und group, aber nicht in shadow.

Verifizieren: systemctl status smbd winbind sollte aktive Dienste zeigen, und die NSSwitch-Datei muss die Einträge sauber enthalten.

Schritt 7: AD-Benutzer und Gruppen prüfen

Jetzt testest du, ob Winbind die Domäne wirklich sieht und ob Benutzer und Gruppen in lokale IDs übersetzt werden.

wbinfo --ping-dc
wbinfo -u
wbinfo -g
getent passwd 'DEINE-DOMAENE\\mustermann'
getent group 'DEINE-DOMAENE\\Buchhaltung'

Wenn diese Abfragen funktionieren, ist der Domain Member wirklich im Alltag angekommen. Genau an dieser Stelle lohnt sich auch ein Blick in die Logs, falls etwas noch nicht stimmt.

Verifizieren: Der Schritt ist erfolgreich, wenn wbinfo den Domain Controller erreicht und getent AD-Benutzer oder -Gruppen zurückgibt.

Jetzt erst legst du das eigentliche Share-Verzeichnis an und vergibst Berechtigungen. Hier zeigt sich, warum ACL-Unterstützung wichtig ist: Nur so kannst du Windows-Gruppen granular steuern.

sudo mkdir -p /srv/shares/abteilung
sudo chown root:root /srv/shares/abteilung
sudo chmod 0770 /srv/shares/abteilung
sudo setfacl -m g:'DEINE-DOMAENE\\Buchhaltung':rwx /srv/shares/abteilung

Die Freigabe in smb.conf könnte so aussehen:

[Abteilung]
    path = /srv/shares/abteilung
    read only = no
    browseable = yes
    valid users = @"DEINE-DOMAENE\\Buchhaltung" @"DEINE-DOMAENE\\Domain Admins"

Wenn du bei Berechtigungen noch unsicher bist, hilft dir unsere Anleitung Linux-Benutzer, Gruppen und Rechte verstehen beim Grundverständnis von Besitz und Rechten.

Verifizieren: Teste die ACL mit getfacl /srv/shares/abteilung und prüfe, dass die gewünschten Gruppen wirklich die erwarteten Rechte haben.

Schritt 9: Zugriff vom Windows-Client testen

Der wichtigste Praxistest kommt zuletzt: Ein Windows-Client muss die Freigabe sehen und darauf zugreifen können. Nur dann ist der Fileserver wirklich alltagstauglich.

smbclient -L localhost -U 'DEINE-DOMAENE\\mustermann'

smbclient //localhost/Abteilung -U 'DEINE-DOMAENE\\mustermann'

Wenn der Zugriff von Windows aus scheitert, helfen dir die Samba- und Systemlogs. Für die Log-Analyse passt wieder unser Grundlagenartikel zu Logs lesen mit journalctl und /var/log.

Verifizieren: Der Schritt ist erfolgreich, wenn du die Freigabe auflisten und mit einem AD-Benutzer darauf zugreifen kannst.

Troubleshooting

Kinit schlägt fehl: DNS, Realm oder Zeit stimmen noch nicht.
net ads join scheitert: Prüfe Kerberos, Samba-Konfiguration und den AD-Benutzernamen.
getent liefert keine AD-Benutzer: Winbind fehlt in /etc/nsswitch.conf oder der Dienst läuft nicht.
ACLs greifen nicht: Das Dateisystem oder die Freigabeoptionen unterstützen die nötigen Extended Attributes noch nicht sauber.

Häufige Fragen

Warum ist DNS so wichtig?

Weil AD stark über DNS arbeitet. Ohne korrekte SRV-Records und passenden Hostname ist Kerberos oft nicht zuverlässig.

Weil ein Domain Member sich sauber in eine bestehende AD-Struktur einfügt und Benutzer sowie Gruppen direkt aus der Domäne nutzen kann.

Wofür ist idmap rid gut?

Es erzeugt eine deterministische Zuordnung von AD-IDs zu Linux-IDs, ohne dass du jede UID manuell pflegen musst.

Fazit

Ein Samba-Domain-Member ist kein Bastelprojekt, sondern ein sauberer Integrationsbaustein für Windows- und Linux-Umgebungen. Wenn DNS, Zeit, Kerberos, Winbind und ACLs in der richtigen Reihenfolge aufgebaut werden, bekommst du einen Fileserver, der sich für AD-Benutzer so anfühlt, als gehöre er selbstverständlich zur bestehenden Domäne.

Als direkte Ergänzung passen unsere Grundlagenartikel zu Pakete verwalten mit apt und dpkg unter Debian/Ubuntu, Logs lesen mit journalctl und /var/log und SSH-Key-Authentifizierung einrichten.

Weiterführende Anleitungen und Quellen

Quellen: Samba Wiki zur Domain-Member-Konfiguration, Ubuntu Server Documentation zu Samba Member Server, Red Hat Samba/Winbind Dokumentation.