Linux-Fileserver im Active Directory: Samba als Domain Member mit NTFS-ähnlichen ACLs

<p>Ein Linux-Server kann vollwertig in eine bestehende Windows-Active-Directory-Domäne eingebunden werden und SMB-Shares für AD-Benutzer bereitstellen – ohne eigenen Domänencontroller und ohne Windows-Server-Lizenz für den Fileserver selbst. Das Konzept: Samba läuft im <strong>Domain-Member-Modus</strong>, Winbind übersetzt AD-SIDs in Linux-UIDs und GIDs, und Windows-ACLs werden über Extended Attributes auf dem Dateisystem gespeichert. Für KMUs, die bereits eine AD-Infrastruktur betreiben, ist das oft die günstigste und flexibelste Lösung für zentral verwalteten Dateispeicher.</p> <aside class="tldr"><p><strong>Kurzfassung:</strong> Du bindest einen Linux-Server per <code>net ads join</code> in eine bestehende AD-Domäne ein. Winbind mit dem idmap-Backend <code>rid</code> übersetzt AD-SIDs deterministisch in Linux-UIDs – kein manueller Aufwand im AD. NTFS-ähnliche ACLs speicherst du via <code>vfs objects = acl_xattr</code> in Extended Attributes des Dateisystems; Windows-Admins verwalten sie danach über die gewohnte Sicherheitsregisterkarte. Die häufigsten Fehlerquellen sind Kerberos-Zeitabweichung (&gt;5 Minuten), falsche DNS-Konfiguration und fehlende <code>winbind</code>-Einträge in <code>/etc/nsswitch.conf</code>.</p></aside> <h2>Voraussetzungen</h2> <ul> <li>Bestehende Windows-AD-Domäne (Windows Server 2012 R2 oder neuer, oder Samba AD DC)</li> <li>Linux-Server: Ubuntu 22.04 LTS oder 24.04 LTS (oder aktuelles Debian/RHEL)</li> <li>Samba 4.x (Ubuntu 24.04 enthält Samba 4.19+)</li> <li>Netzwerkzugang zum DC: UDP/TCP 88 (Kerberos), 389 (LDAP), 445 (SMB), 3268 (Global Catalog)</li> <li><code>/etc/resolv.conf</code> zeigt auf den AD-DC als Nameserver</li> <li>AD-Konto mit Berechtigung zum Hinzufügen von Computerobjekten</li> <li>Dateisystem mit Extended-Attribute-Unterstützung (ext4 mit <code>user_xattr</code>, XFS oder Btrfs)</li> <li>Root-/sudo-Zugang auf dem Linux-Server</li> <li>Kein lokaler Benutzername darf identisch mit einem Domain-Benutzernamen sein</li> </ul> <h2>Schritt 1: Pakete installieren</h2> <p>Installiere alle benötigten Pakete auf Ubuntu/Debian. Das Paket <code>attr</code> und <code>acl</code> sind für Extended Attributes und POSIX-ACLs erforderlich, <code>chrony</code> für die NTP-Synchronisation gegen den DC.</p> <pre><code class="language-bash">sudo apt install samba winbind libpam-winbind libnss-winbind \ krb5-user krb5-config smbclient attr acl dnsutils chrony</code></pre> <p>Während der Installation fragt <code>krb5-config</code> nach dem Default-Realm – gib hier deinen AD-Domänennamen in Großbuchstaben ein, z.B. <code>DOMAIN.EXAMPLE.COM</code>.</p> <h2>Schritt 2: Kerberos konfigurieren</h2> <p>Bearbeite <code>/etc/krb5.conf</code>. Wichtig: Viele Distributionen fügen automatisch <code>includedir</code>-Zeilen ein – diese muss Samba nicht verarbeiten und sie verursachen Fehler. Entferne alle solchen Zeilen.</p> <pre><code class="language-ini">[libdefaults] default_realm = DOMAIN.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true # WICHTIG: Keine 'include' oder 'includedir'-Zeilen eintragen!</code></pre> <p>Ersetze <code>DOMAIN.EXAMPLE.COM</code> durchgehend mit deinem tatsächlichen AD-Realm (immer Großbuchstaben).</p> <h2>Schritt 3: DNS und Hostname prüfen</h2> <p>Vor dem Domain-Join musst du sicherstellen, dass DNS und Hostname-Auflösung korrekt funktionieren. Fehlende SRV-Records oder eine Auflösung auf <code>127.0.0.1</code> sind die häufigsten Join-Blocker.</p> <pre><code class="language-bash"># AD-DNS-Auflösung prüfen nslookup DOMAIN.EXAMPLE.COM host -t SRV _ldap._tcp.DOMAIN.EXAMPLE.COM host -t SRV _kerberos._tcp.DOMAIN.EXAMPLE.COM # Hostname-Rückauflösung prüfen - DARF NICHT 127.0.0.1 ergeben! getent hosts $(hostname -s)</code></pre> <p>Gibt <code>getent hosts</code> die Adresse <code>127.0.1.1</code> zurück, korrigiere <code>/etc/hosts</code>: Trage den Kurznamen des Servers mit seiner tatsächlichen LAN-IP ein.</p> <h2>Schritt 4: NTP-Synchronisation einrichten</h2> <p>Kerberos toleriert maximal <strong>5 Minuten Zeitabweichung</strong> zwischen Linux-Server und DC (RFC 4120). Konfiguriere chrony so, dass der DC als NTP-Quelle dient:</p> <pre><code class="language-ini"># /etc/chrony/chrony.conf - DC als primäre NTP-Quelle server DC1.DOMAIN.EXAMPLE.COM iburst</code></pre> <pre><code class="language-bash">sudo systemctl restart chrony # Sofortige Synchronisation erzwingen: sudo chronyc makestep # Zeitstatus prüfen: chronyc tracking timedatectl status</code></pre> <h2>Schritt 5: smb.conf für den Domain-Member-Modus konfigurieren</h2> <p>Die zentrale Konfigurationsdatei. Für einfache KMU-Szenarien mit einer einzigen AD-Domäne ist das <strong>rid-Backend</strong> die beste Wahl: UIDs werden deterministisch aus dem Windows-RID berechnet, ohne dass du Attribute im AD pflegen musst. Die Tabelle unten zeigt den Vergleich der Backends.</p> <pre><code class="language-ini">[global] workgroup = DOMAIN realm = DOMAIN.EXAMPLE.COM security = ads kerberos method = secrets and keytab # Winbind winbind separator = \ winbind use default domain = no winbind enum users = no winbind enum groups = no template homedir = /home/%D/%U template shell = /bin/bash # idmap - rid-Backend (empfohlen für Single-Domain-KMU-Setups) idmap config * : backend = tdb idmap config * : range = 10000-99999 idmap config DOMAIN : backend = rid idmap config DOMAIN : range = 2000000-2999999 # NTFS-ACLs via Extended Attributes vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes</code></pre> <table class="article-table"><thead><tr><th>idmap-Backend</th><th>Funktionsweise</th><th>AD-Aufwand</th><th>Empfehlung</th></tr></thead><tbody><tr><td><strong>rid</strong></td><td>UID = range_start + Windows-RID (deterministisch)</td><td>Keiner</td><td>KMU, Single Domain</td></tr><tr><td><strong>ad</strong></td><td>Liest uidNumber/gidNumber aus RFC2307-Attributen</td><td>Hoch (manuelle Attributpflege)</td><td>Große Umgebungen mit Unix-Anforderungen</td></tr><tr><td><strong>autorid</strong></td><td>Automatische Verwaltung mehrerer Domains</td><td>Keiner</td><td>Multi-Domain/Forest-Szenarien</td></tr></tbody></table> <p><strong>Wichtig:</strong> ID-Ranges dürfen sich niemals überschneiden. Die Standard-Range (<code>*</code>) mit tdb und die domänenspezifische Range müssen getrennte, nicht überlappende Bereiche abdecken.</p> <h2>Schritt 6: Domain-Join durchführen</h2> <p>Hole zuerst ein Kerberos-Ticket und führe dann den Join durch. Bei Samba ab Version 4.15.0 steht alternativ <code>samba-tool domain join</code> zur Verfügung.</p> <pre><code class="language-bash"># Kerberos-Ticket holen kinit administrator@DOMAIN.EXAMPLE.COM # Domain-Join sudo net ads join -U administrator # Ab Samba 4.15.0 alternativ: # sudo samba-tool domain join DOMAIN.EXAMPLE.COM MEMBER -U administrator</code></pre> <h2>Schritt 7: Dienste starten</h2> <p>Auf einem Domain Member laufen <strong>ausschließlich</strong> <code>smbd</code> und <code>winbindd</code>. Der Dienst <code>samba</code> startet den AD-DC-Modus und darf nicht gestartet werden – das ist ein klassischer Fehler.</p> <pre><code class="language-bash">sudo systemctl enable --now smbd winbind # Den samba-Dienst (DC-Modus) explizit deaktivieren: sudo systemctl disable samba 2>/dev/null || true sudo systemctl status smbd winbind</code></pre> <h2>Schritt 8: NSSwitch konfigurieren</h2> <p>Damit <code>getent</code> und alle PAM-Dienste AD-Benutzer auflösen können, muss <code>winbind</code> in <code>/etc/nsswitch.conf</code> eingetragen sein. In der Zeile <code>shadow</code> darf <code>winbind</code> <strong>nicht</strong> stehen.</p> <pre><code class="language-plaintext"># /etc/nsswitch.conf - relevante Zeilen passwd: files systemd winbind group: files systemd winbind # shadow KEIN winbind!</code></pre> <h2>Schritt 9: Join verifizieren</h2> <p>Teste den Join schrittweise. Jede Stufe prüft eine andere Schicht der Integration:</p> <pre><code class="language-bash"># 1. Winbind-DC-Verbindung prüfen wbinfo --ping-dc # 2. Domain-User und -Gruppen auflisten wbinfo -u wbinfo -g # 3. NSS-Integration testen getent passwd 'DOMAIN\\mustermann' getent group 'DOMAIN\\domain users' # 4. DC-Details anzeigen net ads info # 5. Maschinenaccount im AD verifizieren net ads testjoin</code></pre> <h2>Schritt 10: Share-Verzeichnis anlegen und Share konfigurieren</h2> <p>Lege das Verzeichnis mit korrekten Basisrechten an. Da wir <code>acl_xattr</code> nutzen, reichen POSIX-ACLs als Basis – die feingranulare Windows-ACL-Verwaltung übernehmen danach Windows-Administratoren über die gewohnte Sicherheitsregisterkarte im Explorer oder die Computerverwaltung.</p> <pre><code class="language-bash"># Verzeichnis anlegen sudo mkdir -p /srv/shares/abteilung # Besitzer und Grundrechte setzen sudo chown root:'DOMAIN\\Domain Admins' /srv/shares/abteilung sudo chmod 0770 /srv/shares/abteilung # POSIX-ACL für AD-Gruppe (Basis für acl_xattr) sudo setfacl -m g:'DOMAIN\\Buchhaltung':rwx /srv/shares/abteilung</code></pre> <p>Füge die Share-Definition in <code>/etc/samba/smb.conf</code> hinzu:</p> <pre><code class="language-ini">[Abteilung] path = /srv/shares/abteilung comment = Abteilungsfreigabe writable = yes guest ok = no valid users = @"DOMAIN\\Buchhaltung" @"DOMAIN\\Domain Admins" # Windows-ACLs danach über Windows-Computerverwaltung setzen</code></pre> <p>Konfiguration neu laden und Verbindung testen:</p> <pre><code class="language-bash">sudo smbcontrol smbd reload-config # Syntax vorab prüfen: testparm -s # Verbindungstest: smbclient //SERVER/Abteilung -U 'DOMAIN\\mustermann'</code></pre> <p>Für Dateisystemoperationen und Benutzer-/Gruppenrechte empfiehlt sich auch ein Blick auf unsere Anleitung zu <a href="https://s-edv.com/anleitungen/linux-benutzer-gruppen-rechte-chmod-chown-sudo">Linux-Benutzer, Gruppen und Rechte mit chmod, chown und sudo</a>.</p> <h2>Troubleshooting / Typische Fehler</h2> <ul> <li><strong>„Clock skew too great" / KRB5KRB_AP_ERR_SKEW:</strong> Die Zeitabweichung zwischen Linux-Server und DC ist größer als 5 Minuten. <code>kinit</code> kann noch funktionieren, während <code>net ads join</code> dann fehlschlägt. Lösung: NTP gegen den DC konfigurieren und <code>sudo chronyc makestep</code> ausführen.</li> <li><strong>Falsches idmap-Backend oder überlappende Ranges:</strong> AD-Benutzer erhalten zufällige oder inkonsistente UIDs auf verschiedenen Servern, Dateiberechtigungen funktionieren nicht. Lösung: Identische idmap-Konfiguration auf allen Member-Servern; Ranges sorgfältig planen und dokumentieren. Ranges dürfen sich nie überschneiden.</li> <li><strong><code>getent passwd</code> zeigt keine AD-Benutzer:</strong> <code>wbinfo -u</code> funktioniert (Winbind-Direktkommunikation), aber <code>getent</code> liefert nichts (NSS-Pfad). Ursache: fehlende <code>winbind</code>-Einträge in <code>/etc/nsswitch.conf</code>. Für Tests kann man temporär <code>winbind enum users = yes</code> in smb.conf setzen (nicht dauerhaft empfohlen).</li> <li><strong><code>includedir</code> in /etc/krb5.conf:</strong> Nach System-Updates treten Kerberos-Fehler mit <code>NT_STATUS_UNSUCCESSFUL</code> auf. Viele Distributionen fügen automatisch <code>includedir /etc/krb5.conf.d/</code> ein; Samba kann diese Direktive nicht verarbeiten. Lösung: <code>includedir</code>-Zeile aus <code>/etc/krb5.conf</code> entfernen.</li> <li><strong><code>systemctl start samba</code> statt <code>smbd</code>/<code>winbind</code>:</strong> Der <code>samba</code>-Dienst aktiviert den AD-DC-Modus, nicht den Member-Server-Modus. Seltsame Fehler und DC-Funktionen werden aktiviert. Lösung: Ausschließlich <code>smbd</code> und <code>winbind</code> starten; <code>samba</code>-Dienst deaktivieren.</li> <li><strong>Hostname löst auf 127.0.0.1 oder 127.0.1.1 auf:</strong> <code>net ads join</code> schlägt mit DNS-Fehler fehl. Ursache: <code>/etc/hosts</code> hat <code>127.0.1.1 HOSTNAME</code>. Lösung: <code>getent hosts $(hostname -s)</code> prüfen; <code>/etc/hosts</code> so korrigieren, dass der Kurzname auf die LAN-IP zeigt.</li> <li><strong>idmap-Backend „ad" ohne RFC2307-Attribute:</strong> <code>wbinfo -u</code> zeigt User, aber UIDs kommen als <code>-1</code> oder „no mapping". Das <code>ad</code>-Backend erwartet <code>uidNumber</code>- und <code>gidNumber</code>-Attribute im AD, die standardmäßig nicht gesetzt sind. Lösung: Attribute via ADUC oder PowerShell setzen, oder auf das <code>rid</code>-Backend wechseln.</li> <li><strong>Dateisystem ohne xattr-Unterstützung:</strong> Windows zeigt beim Setzen von ACLs „Zugriff verweigert" oder Berechtigungen gehen nach Reload verloren. Lösung: ext4 mit <code>user_xattr</code>-Mount-Option in <code>/etc/fstab</code>, oder XFS/Btrfs verwenden. Verifikation: <code>setfattr -n user.test -v 1 /srv/shares/abteilung</code>.</li> <li><strong>CVE-2025-49716 (Microsoft Security Update 2025):</strong> Nach einem Windows-Sicherheitsupdate schlägt Samba-Authentifizierung mit dem <code>idmap_ad</code>-Backend auf RHEL/Fedora fehl. Lösung: RHEL-Patch einspielen (Red Hat KB 7127997) oder temporär auf das <code>rid</code>-Backend wechseln.</li> </ul> <h2>Häufige Fragen</h2> <h3>Was ist der Unterschied zwischen dem idmap-Backend „rid" und „ad"?</h3> <p>Das <strong>rid</strong>-Backend berechnet UIDs/GIDs deterministisch aus dem Windows-RID: <code>UID = range_start + RID</code>. Kein Aufwand im AD, identische UIDs auf allen Member-Servern bei gleicher smb.conf – ideal für KMUs. Das <strong>ad</strong>-Backend liest <code>uidNumber</code> und <code>gidNumber</code> direkt aus RFC2307-Attributen im AD-Verzeichnis. Das erlaubt individuelle Werte pro Benutzer (Shell, Homedir), erfordert aber manuelle Attributpflege im AD über ADUC oder PowerShell.</p> <h3>Muss der Linux-Fileserver eine eigene Windows-Server-Lizenz haben?</h3> <p>Nein. Als Domain Member benötigt der Linux-Server selbst keine Windows-Server-Lizenz. Die AD-Benutzer benötigen weiterhin ihre Client-Zugriffslizenzen (CALs) gemäß Microsoft-Lizenzmodell – diese gelten jedoch für den Zugriff auf AD-Dienste, nicht spezifisch für den Samba-Server. DFS (Distributed File System) und bestimmte erweiterte Windows-ACL-Features wie Conditional ACEs sind in Samba nicht vollständig implementiert.</p> <h3>Kann ich Windows-ACLs über die Sicherheitsregisterkarte auf Samba-Shares setzen?</h3> <p>Ja, mit <code>vfs objects = acl_xattr</code> und <code>map acl inherit = yes</code>. Samba speichert Windows-ACLs im Extended Attribute <code>security.NTACL</code>. Das Setzen erfolgt über den Windows-Explorer (Eigenschaften → Sicherheit) oder die Computerverwaltung – genau wie bei einem Windows-Dateiserver. Voraussetzung: xattr-fähiges Dateisystem (ext4 mit <code>user_xattr</code>, XFS oder Btrfs). Ohne diese Voraussetzung gehen Berechtigungen verloren oder das Setzen schlägt fehl.</p> <h3>Warum zeigt <code>getent passwd</code> keine AD-Benutzer, obwohl <code>wbinfo -u</code> funktioniert?</h3> <p><code>wbinfo</code> kommuniziert direkt mit <code>winbindd</code> und umgeht NSS komplett. <code>getent</code> hingegen nutzt <code>/etc/nsswitch.conf</code>. Lösung: <code>winbind</code> muss in <code>/etc/nsswitch.conf</code> in den Zeilen <code>passwd</code> und <code>group</code> eingetragen sein. Für Massenabfragen kann man zusätzlich <code>winbind enum users = yes</code> und <code>winbind enum groups = yes</code> in smb.conf setzen – das ist aber nur temporär für Tests empfohlen, da es bei großen Domänen Performance-Probleme verursacht.</p> <h3>Wie unterscheidet sich ein Samba Domain Member von einem Samba AD DC?</h3> <p>Ein <strong>Domänencontroller</strong> (DC) hostet die AD-Datenbank, DNS, Kerberos-KDC und LDAP selbst – er ersetzt Windows-DCs vollständig. Ein <strong>Domain Member</strong> tritt einer bestehenden Domäne bei, nutzt deren Authentifizierungsinfrastruktur und stellt nur Dateidienste bereit. Auf dem Member laufen <code>smbd</code> und <code>winbindd</code>, nicht der <code>samba</code>-Dienst (DC-Modus). Für eine Anleitung zum vollständigen Samba AD DC siehe die <a href="https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member">offizielle Samba-Dokumentation</a>.</p> <h3>Wie teste ich, ob der Domain-Join erfolgreich war?</h3> <p>Stufenweise: (1) <code>wbinfo --ping-dc</code> prüft die Winbind-DC-Verbindung, (2) <code>wbinfo -u</code> und <code>wbinfo -g</code> listen Domain-User/-Gruppen auf, (3) <code>getent passwd 'DOMAIN\\username'</code> verifiziert die NSS-Integration, (4) <code>net ads info</code> zeigt DC-Details, (5) <code>net ads testjoin</code> verifiziert den Maschinenaccount im AD.</p> <h2>Fazit</h2> <p>Ein Samba Domain Member ist für KMUs eine praxisbewährte Lösung, um Linux-Storage in eine bestehende AD-Infrastruktur zu integrieren. Das <code>rid</code>-Backend minimiert den Konfigurationsaufwand, <code>acl_xattr</code> ermöglicht vollständige Windows-ACL-Verwaltung über bekannte Tools. Die häufigsten Stolpersteine – Kerberos-Zeitabweichung, DNS-Probleme und fehlende NSSwitch-Einträge – lassen sich mit einem systematischen Vorgehen zuverlässig vermeiden. Im Vergleich zum Windows-Dateiserver entfällt die Windows-Server-Lizenz für den Fileserver selbst; die AD-CALs der Benutzer bleiben aber erforderlich. Wer seinen Server darüber hinaus absichern möchte, findet in unserer Anleitung zum <a href="https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban">Linux-Server absichern mit UFW und fail2ban</a> einen guten nächsten Schritt. Für die Grundlagen zur Benutzerverwaltung auf Linux-Ebene empfiehlt sich außerdem die Anleitung zu <a href="https://s-edv.com/anleitungen/linux-benutzer-gruppen-rechte-chmod-chown-sudo">Linux-Benutzer, Gruppen und Rechten</a>.</p> <h2>Weiterführende Anleitungen und Quellen</h2> <ul> <li><a href="https://s-edv.com/anleitungen/active-directory-domaene-einrichten-benutzer-ou">Active Directory Domäne einrichten: Benutzer und OUs verwalten</a></li> <li><a href="https://s-edv.com/anleitungen/dateiserver-ntfs-freigabeberechtigungen-windows-server">Dateiserver: NTFS- und Freigabeberechtigungen unter Windows Server</a></li> <li><a href="https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban">Linux-Server absichern mit UFW und fail2ban</a></li> <li><a href="https://s-edv.com/anleitungen/festplatten-linux-partitionen-lvm-fstab">Festplatten unter Linux: Partitionen, LVM und fstab</a></li> </ul> <p>Quellen: <a href="https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member">SambaWiki: Setting up Samba as a Domain Member</a>, <a href="https://wiki.samba.org/index.php/Idmap_config_rid">SambaWiki: Idmap config rid</a>, <a href="https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs">SambaWiki: Setting up a Share Using Windows ACLs</a>, <a href="https://documentation.ubuntu.com/server/how-to/samba/member-server-in-an-ad-domain/">Ubuntu Server Docs: Member Server in an AD Domain</a>, <a href="https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/connecting-rhel-systems-directly-to-ad-using-samba-winbind_integrating-rhel-systems-directly-with-active-directory">Red Hat: Connecting RHEL systems directly to AD using Samba Winbind</a></p>