Samba als Active Directory: Windows-Domäne ablösen

Windows Server als Domain Controller wird für kleine und mittlere Unternehmen zum spürbaren Kostenblock: Server-Lizenz, Client-Access-Lizenzen pro User oder Device, dazu die regelmäßigen Upgrades im Drei-Jahres-Rhythmus. Wer nur Datei-Freigaben, Anmeldung, Gruppenrichtlinien und DNS braucht, zahlt für Funktionen, die er nie einsetzt. Samba 4 implementiert seit Jahren das AD-Protokoll vollständig genug, um als Domain Controller in einer bestehenden Windows-Domäne zu laufen — inklusive Multi-Master-Replikation, Kerberos, LDAP und GPO-Verteilung.

Dieser Artikel beschreibt, wann Samba den Windows-DC realistisch ablöst, wo die Grenzen liegen, und wie eine Migration ohne Wochenend-Downtime funktioniert. Wir setzen die Verfahren seit Jahren bei SMB-Kunden ein, die weder Exchange noch tief integrierte Microsoft-365-Hybrid-Szenarien fahren.

Was Samba 4 als AD-DC leistet — und was nicht

Samba 4.20 (aktuelle stabile Version im Sommer 2026) läuft als vollwertiger AD-Domain-Controller. Windows-Clients ab Windows 10 melden sich an, ziehen Gruppenrichtlinien, nutzen Kerberos-SSO für Datei-Freigaben und lösen Namen über den in Samba integrierten DNS-Server oder über BIND9 auf. Für den Client ist nicht erkennbar, ob der DC auf Windows Server oder auf Debian läuft.

Wichtig ist die ehrliche Abgrenzung, wo Samba nicht vollwertig ist:

Funktion	Samba 4 AD-DC	Anmerkung
NTLM/Kerberos-Anmeldung	Voll	RFC-konforme Implementierung
LDAP-Verzeichnisdienst	Voll	Kompatibel mit Windows-Tools wie ADUC
DNS (integriert oder BIND9)	Voll	BIND9-DLZ für komplexe Zonen empfohlen
Multi-Master-Replikation	Voll	DRSUAPI, funktioniert mit Windows-DCs
Gruppenrichtlinien (GPO)	Verteilung ja, Bearbeitung nur mit RSAT	Kein grafischer Editor auf dem DC selbst
Exchange-Schema-Erweiterung	Nein	Exchange braucht Windows-Schema-Master
Azure AD Connect / Entra Cloud Sync	Eingeschränkt	Sync läuft, aber Support-Matrix bevorzugt Windows
Read-Only Domain Controller (RODC)	Nein	Nur Read-Write-DCs
PKI / Enterprise-CA	Nein	Zertifikatsdienste bleiben auf Windows

Das heißt konkret: Ein Standard-Fileserver-Szenario mit 50 Usern, 20 Netzlaufwerken, GPO-verteiltem Drucker, WLAN-Zertifikat aus einer separaten CA — das läuft auf Samba genauso stabil wie auf Windows Server. Sobald jedoch Exchange on-premise, Entra Hybrid Join im Produktivbetrieb oder eine Enterprise-CA im Spiel sind, gehören mindestens diese Rollen weiterhin auf Windows.

Die Zielarchitektur: Samba mit BIND9

Für alles außer dem allerkleinsten Setup empfehlen wir Samba nicht mit dem internen DNS-Server, sondern in Kombination mit BIND9 über das DLZ-Backend. Der Grund: BIND9 verarbeitet komplexe Split-Horizon-Zonen, DNSSEC und Forwarder deutlich robuster, und Sie können denselben Nameserver für interne AD-Zonen und für öffentliche Zonen nutzen.

Ein typischer Zwei-DC-Aufbau sieht so aus:

dc01.firma.local  (Debian 13, Samba 4.20, BIND9)  -- Standort A
dc02.firma.local  (Debian 13, Samba 4.20, BIND9)  -- Standort B
FSMO-Rollen: dc01 hält PDC-Emulator, RID-Master, Infrastructure-Master
             dc02 hält Schema-Master und Domain-Naming-Master
Replikation: alle 15 Minuten intra-site, stündlich inter-site
Backup: nightly samba-tool domain backup offline auf TrueNAS-Share

Die Samba-Provisionierung des ersten DCs ist ein einzelner Befehl. Wichtig ist, den DNS-Backend-Parameter korrekt zu setzen und die Domain-Funktionsebene auf einen Wert zu heben, der zu den vorhandenen Clients passt:

# Erst-Provisionierung eines neuen DCs (nicht für Migration)
samba-tool domain provision \
  --realm=FIRMA.LOCAL \
  --domain=FIRMA \
  --server-role=dc \
  --dns-backend=BIND9_DLZ \
  --function-level=2016 \
  --use-rfc2307 \
  --adminpass='SicheresPasswort!2026'

# BIND9 einbinden
echo 'include "/var/lib/samba/bind-dns/named.conf";' >> /etc/bind/named.conf.local
systemctl restart bind9 samba-ad-dc

Der Parameter --use-rfc2307 erweitert das Schema um POSIX-Attribute — unverzichtbar, wenn Sie später Linux-Clients per SSSD gegen das AD authentifizieren wollen, was in gemischten Umgebungen der Regelfall ist.

Migration aus einer bestehenden Windows-Domäne

Der Königsweg ist die Koexistenz: Der neue Samba-DC wird der bestehenden Windows-Domäne als zusätzlicher Domain Controller hinzugefügt, repliziert das komplette Verzeichnis über DRSUAPI und übernimmt anschließend die FSMO-Rollen. Erst wenn alles läuft, wird der alte Windows-DC entfernt. Downtime für Endanwender: null.

Der Ablauf in fünf Schritten:

1. Vorbereitung Windows-Seite: Domain- und Forest-Funktionsebene prüfen. Samba 4.20 unterstützt bis Windows Server 2016. Höhere Ebenen sind auf Windows-DCs möglich, blockieren aber den Beitritt eines Samba-DCs.
2. Samba-DC beitreten: Auf dem neuen Debian-System samba-tool domain join firma.local DC -U administrator --dns-backend=BIND9_DLZ ausführen. Der Join dauert je nach Verzeichnisgröße wenige Minuten.
3. Replikationsstatus prüfen: Mit samba-tool drs showrepl verifizieren, dass alle Namensräume erfolgreich repliziert wurden. Fehler in dieser Phase deuten fast immer auf DNS- oder Zeit-Probleme hin.
4. FSMO-Rollen übertragen: Nach 24 bis 48 Stunden stabiler Koexistenz die FSMO-Rollen mit samba-tool fsmo transfer einzeln umziehen. Der PDC-Emulator zuletzt, weil er für Zeitsynchronisation und Passwort-Änderungen zentral ist.
5. Alten DC herabstufen: Auf dem Windows-Server dcpromo beziehungsweise unter Windows Server 2025 den Server-Manager-Wizard nutzen, um die DC-Rolle sauber zu entfernen. Nicht einfach abschalten — Metadaten-Leichen im Verzeichnis sind mühsam zu bereinigen.

Für die Zeit-Synchronisation setzen wir auf dem Samba-DC chrony mit einer externen Referenz (z.B. der DFN-NTP-Pool) auf. AD ist notorisch empfindlich gegen Zeit-Drift größer fünf Minuten — Kerberos-Tickets werden dann sofort ungültig.

Gruppenrichtlinien: was tatsächlich funktioniert

Die häufigste Sorge in Migrationsprojekten ist die GPO-Fähigkeit. Klarstellung: Samba verteilt Gruppenrichtlinien vollständig. Ein Windows-Client zieht sich gpupdate /force und wendet Passwort-Policies, Software-Verteilung per MSI, Netzlaufwerks-Mappings, Firewall-Regeln, Loopback-Verarbeitung und Preferences genauso an wie gegen einen Windows-DC.

Was Samba nicht mitbringt: den grafischen Editor. Sie brauchen weiterhin einen Windows-Client mit RSAT (Remote Server Administration Tools), um mit gpmc.msc neue Richtlinien anzulegen oder zu bearbeiten. In der Praxis ist das keine Einschränkung, weil ein Admin-Notebook mit RSAT ohnehin Standard ist — niemand editiert GPOs sinnvoll auf einem Server-Core.

Ein oft übersehenes Detail: PolicyDefinitions (ADMX-Templates). Diese müssen auf dem SYSVOL-Share unter \\firma.local\SYSVOL\firma.local\Policies\PolicyDefinitions\ liegen. Nach der Migration prüfen, dass die Templates vollständig repliziert sind, sonst zeigt der GPO-Editor “Additional Registry Settings” statt der lesbaren Kategorien.

Backup und Disaster Recovery

Samba bringt mit samba-tool domain backup seit Version 4.11 ein sauberes Offline-Backup mit, das das gesamte Verzeichnis inklusive Kerberos-Keytab, SYSVOL und Konfiguration in ein tar-Archiv schreibt. Wir schedulen das nightly auf einen TrueNAS-Share und ziehen mit ZFS-Snapshots eine 30-Tage-Historie. Restore-Test einmal im Quartal, in einer isolierten VM auf dem Proxmox-Cluster.

Für einen echten Site-Ausfall genügen zwei DCs an unterschiedlichen Standorten mit funktionierender Replikation. Fällt Standort A aus, arbeitet Standort B autonom weiter. Kommt Standort A zurück, resynchronisiert Samba automatisch. Voraussetzung: die USN-Rollback-Erkennung greift nur bei sauberen Backups, nie Snapshots eines laufenden DCs zurückspielen — das führt zu genau dem Rollback-Zustand, der im Verzeichnis eine Katastrophe auslöst.

Wann Samba passt — und wann nicht

Nach etlichen Migrationsprojekten kristallisiert sich ein klares Bild heraus:

• Klare Ja-Fälle: Fileserver-zentrierte Umgebungen ohne Exchange on-premise, ohne AAD-Hybrid-Zwang, mit klassischen GPO-Anforderungen. Typisch sind Handwerksbetriebe, Ingenieurbüros, Kanzleien, Schulen. Hier ersetzt Samba den Windows-DC eins zu eins, spart Lizenz- und Support-Kosten im vier- bis fünfstelligen Bereich pro Jahr.
• Grenzfälle: Umgebungen mit Enterprise-CA, komplexen Vertrauensstellungen zu externen Forests, tief integriertem SCCM/Intune. Machbar, aber der Betriebsaufwand steigt spürbar.
• Klare Nein-Fälle: Exchange on-premise als Produktivsystem, Entra Hybrid Join mit Windows-Hello-for-Business-Zertifikaten aus der AD-CS, strikte Microsoft-Support-Anforderungen im Enterprise-Umfeld.

Wichtig ist auch die Personalfrage: Samba ist Open Source und wird über die Konsole administriert. Wer ein Team hat, das nur Windows-GUIs kennt, muss zunächst in Know-how investieren — oder externen Support einbinden.

---

DATAZONE unterstützt bei der Bewertung, ob Samba für Ihre Umgebung passt, plant die Migration inklusive Koexistenz-Phase und übernimmt auf Wunsch den laufenden Betrieb der Domain Controller inklusive Backup und Monitoring. Sprechen Sie uns an — wir prüfen unverbindlich, welche Rollen sich sinnvoll auf Linux verlagern lassen und wo ein Windows-Server sinnvoll bleibt. Kontakt aufnehmen.