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 (der Samba-Dienst für die Anbindung an die Domäne) ü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 geht diese Anleitung 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 (z. B. Debian 12 oder Ubuntu 24.04 LTS, x86-64 oder ARM64). Für ein KMU mit bis zu etwa 50 Benutzern reichen 2 CPU-Kerne und 4 GB RAM, dazu Datenspeicher nach Bedarf auf einem Dateisystem mit Extended Attributes und POSIX-ACLs (ext4 oder XFS)
Feste IP-Adresse im LAN und ein DNS-Eintrag für den Server auf dem Domain Controller
Sudo-Rechte oder Root-Zugang
Direkter Zugriff auf DNS, Zeitquelle und ein AD-Konto mit dem Recht, Computer in die Domäne aufzunehmen

Als Platzhalter verwendet die Anleitung den Kerberos-Realm AD.FIRMA.DE und den kurzen Domänennamen (NetBIOS-Name) FIRMA. Ersetzen Sie beide durch die Werte Ihrer Domäne.

Wichtig für das Verständnis: Dieser Artikel baut stark auf den Linux-Grundlagen auf. Wenn Sie mit SSH, Rechten oder Logs noch unsicher sind, helfen 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.AD.FIRMA.DE
host -t SRV _kerberos._tcp.AD.FIRMA.DE

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 brauchen Sie 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 Sie Samba in die Domäne aufnehmen, muss Kerberos (das Anmeldeprotokoll des Active Directory) 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 = AD.FIRMA.DE
    dns_lookup_realm = false
    dns_lookup_kdc = true

Das Samba-Wiki empfiehlt, in /etc/krb5.conf keine weiteren Parameter zu setzen. Eine vorhandene include-Zeile müssen Sie entfernen, sonst funktioniert die Konfiguration nicht.

Dann ein Testticket holen:

kinit administrator@AD.FIRMA.DE
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 = FIRMA
    realm = AD.FIRMA.DE
    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 FIRMA : backend = rid
    idmap config FIRMA : 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üfen Sie 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 nutzen Sie 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, brauchen Sie Winbind und passende Einträge in der NSSwitch-Konfiguration (sie legt fest, woher das System Benutzer und Gruppen bezieht).

sudo systemctl enable --now smbd winbind
sudo systemctl restart smbd winbind

Den Dienst nmbd brauchen Sie laut Samba-Wiki nur, wenn Sie die Netzwerkumgebung (NetBIOS-Browsing) benötigen. Auf einem reinen Fileserver können Sie ihn mit sudo systemctl disable --now nmbd abschalten.

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 testen Sie, 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 'FIRMA\mustermann'
getent group 'FIRMA\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 legen Sie das eigentliche Share-Verzeichnis an und vergeben Berechtigungen. Hier zeigt sich, warum ACL-Unterstützung wichtig ist: Nur so lassen sich 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:'FIRMA\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 = @"FIRMA\Buchhaltung" @"FIRMA\Domain Admins"

In einfachen Anführungszeichen steht in der Shell wie in der smb.conf genau ein Backslash zwischen Domäne und Name. Da winbind use default domain = yes gesetzt ist, funktionieren Benutzer- und Gruppennamen zusätzlich auch ohne Domänenpräfix. Nach dem Speichern laden Sie die Konfiguration mit sudo smbcontrol smbd reload-config neu. Die feineren Rechte setzen Sie anschließend bequem von Windows aus über Eigenschaften → Sicherheit. Das dürfen laut Samba-Wiki standardmäßig die Mitglieder von Domain Admins. Andere Konten benötigen das Recht SeDiskOperatorPrivilege.

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

Verifizieren: Testen Sie 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. Prüfen Sie zuerst lokal auf dem Server:

smbclient -L localhost -U 'FIRMA\mustermann'

smbclient //localhost/Abteilung -U 'FIRMA\mustermann'

Öffnen Sie danach auf einem Windows-Client, der Mitglied der Domäne ist, im Explorer \\fileserver\Abteilung (Hostname Ihres Servers). Als Domänenbenutzer sollten Sie ohne erneute Passwortabfrage hineinkommen. Wenn der Zugriff von Windows aus scheitert, helfen 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 Sie die Freigabe mit smbclient auflisten und vom Windows-Client aus mit einem AD-Benutzer der Gruppe Buchhaltung Dateien anlegen können, während ein Benutzer außerhalb der Gruppe abgewiesen wird.

Troubleshooting

Kinit schlägt fehl: DNS, Realm oder Zeit stimmen noch nicht.
net ads join scheitert: Prüfen Sie Kerberos, die 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.
wbinfo meldet Fehler, obwohl der Join geklappt hat: Prüfen Sie, ob winbind versehentlich in der Zeile shadow der /etc/nsswitch.conf steht. Laut Samba-Wiki führt das zu Fehlern.

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 berechnet die Linux-IDs aus dem RID-Anteil der AD-Kennungen. Die Zuordnung ist dadurch deterministisch, ohne dass Sie jede UID manuell pflegen müssen. Nutzen Sie auf mehreren Fileservern denselben [global]-Abschnitt, erhalten Benutzer überall dieselben IDs.

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, erhalten Sie einen Fileserver, der sich für AD-Benutzer so anfühlt, als gehöre er selbstverständlich zur bestehenden Domäne.

Wie die Domäne selbst aufgesetzt wird, zeigt die Anleitung Active Directory: Domäne einrichten und erste Benutzer/OUs anlegen. 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: Setting up Samba as a Domain Member, Samba Wiki: Setting up a Share Using Windows ACLs, Ubuntu Server Documentation: Member server in an AD domain.