project/0042

Samba-AD-DC Domain Controller

1. Einleitung

Ich möchte in diesem Dokument mein Projekt Samba Active Directory Domain Controller (Samba-AD-DC/project-0042) zusammenfassen. Es handelt sich dabei nicht um eine Schritt-für-Schritt-Anleitung zur Installation oder Provisionierung eines Samba-AD-DC. Wer eine vollständige Anleitung sucht, sollte direkt in der offiziellen Samba-Dokumentation beginnen:

Setting up Samba as an Active Directory Domain Controller

- oder gegebenenfalls ChatGPT dazu befragen.

In meinem Bericht beschreibe ich mein eigenes Setup, die Herausforderungen, auf die ich beim Einrichten von Roaming-Desktops sowie beim Hinzufügen eines zweiten Domain Controllers für meine zweite AD-Site gestoßen bin, und wie ich diese erfolgreich lösen konnte.

Ein weiterer Bestandteil meines Projekts ist project-0768, ein PowerShell-Skript, das auf den UniGetUI uBundle/JSON-Dateien basiert. Damit kann ich Software auf allen meinen Rechnern weitgehend identisch installieren. Dieses Skript bildet die Grundlage für die spätere Umsetzung der Roaming-Desktops.

2. IT-Landschaft

2.1. Serverlandschaft

Meine Serverumgebung besteht aus zwei Mini-PCs/Barebone-Servern:

Geekom Mini-PC
- CPU: Intel® N100 (4 Kerne)
- RAM: 16 GB DDR5 (5600 MT/s)
- SSD: WD Red SN700, 1000 GB
Intel NUC
- CPU: 11th Gen Intel® Core™ i3-1115G4 @ 3.00 GHz (4 Kerne)
- RAM: 2×8 GB DDR4 (2400 MT/s)
- SSD: WD Red SN700, 1000 GB

2.2. Geografische Sites

Es gibt zwei Standorte (Sites):

Wohnung → Site Apartment: "Default-First-Site-Name"
Elternhaus → Site House: "schwanthalerstrasse"

Der Geekom-Server steht in meiner Wohnung (Site Apartment).
Der Intel NUC steht im Elternhaus (Site House).

2.3. Virtuelle Infrastruktur

Auf beiden Mini-Servern läuft Proxmox VE mit Debian 13 VMs:

Geekom (rm131.schrottplatz.internal)
- vm117.schrottplatz.internal → Erster Domain Controller (DC)
Intel NUC (rm013.schrottplatz.internal)
- vm011.schrottplatz.internal → Zweiter Domain Controller (DC)
- vm080.schrottplatz.internal → Webservices

2.4. Netzwerk

Die beiden Sites sind über ein WireGuard Site-to-Site VPN miteinander verbunden:

Site House → Unifi Gateway
Site Apartment → Fritz!Box

2.4.1. Intrusion Detection

Die Intrusion Detection des Unifi Gateways wurde für die Inter-Server-Kommunikation deaktiviert.

Hintergrund: Eine aktivierte Erkennung führte zu regelmäßig abreißenden bzw. blockierten SSH-Verbindungen zwischen den Servern.

3. Erster Domain-Controller

Für den Betrieb eines Samba Active Directory Domain Controllers muss das Paket samba-ad-dc installiert sein (Debian/Ubuntu).

Den ersten Domain Controller vm117.schrottplatz.internal konnte ich anhand der offiziellen Anleitung auf Setting up Samba as an Active Directory Domain Controller sehr einfach einrichten.
Wichtig: Die in der Anleitung beschriebenen Anpassungen in /etc/hosts und /etc/resolv.conf dürfen nicht vergessen werden.

Es hat sich bei mir bewährt, die bestehende smb.conf vorab in smb.conf.save umzubenennen. Anschließend habe ich den ersten DC mit folgendem Befehl im interaktiven Modus provisioniert (Meine Domain ist schrottplatz.internal):

samba-tool domain provision --use-rfc2307 --interactive

Die Option --use-rfc2307 ist dabei entscheidend – insbesondere, wenn später weitere Domain Controller in die Domäne aufgenommen werden sollen (Setting up RFC2307 in AD).

Hintergrund: Ohne diese Option hatte ich beim Joinen des zweiten DCs das Problem, dass für dieselben Benutzer und Gruppen unterschiedliche UIDs/GIDs vergeben wurden.

Nach dem Provisioning sollte eine /etc/samba/smb.conf vorhanden sein und darin unter [global] die Zeile:

[global]
  idmap_ldb:use rfc2307 = yes

Weiter sollte eine Datei /etc/krb5.conf mit etwa folgendem Inhalt vorhanden sein:

[libdefaults]
  default_realm = SCHROTTPLATZ.INTERNAL
  dns_lookup_realm = false
  dns_lookup_kdc = true
[realms]
  SCHROTTPLATZ.INTERNAL = {
      default_domain = schrottplatz.internal
  }
[domain_realm]
  vm117 = SCHROTTPLATZ.INTERNAL

Nicht vergessen den neuen Domain-Controller selbst als DNS-Server in /etc/resolv.conf einzutragen. /etc/resolv.conf sollte etwa so aussehen:

domain schrottplatz.internal
search schrottplatz.internal
nameserver 127.0.0.1

3.1. Firewall (UFW)

Für die Firewall gibt es zwei Möglichkeiten: Erstens, die komplette Service-Gruppesamba-ad-dc freigeben:

ufw allow samba-ad-dc

Zeitens, die benötigten Ports einzeln öffnen (siehe Samba AD DC Port Usage).

4. Zweite Site mit RSAT einrichten

4.1. RSAT-AD-LDS-Tools installieren

Ein weiteres Subnetz lässt sich am einfachsten mit den Microsoft RSAT-Tools einrichten. Voraussetzung ist ein zu der Domäne gejointes Windows 10/11 Pro/Enterprise Gerät.

In PowerShell prüfen, ob die AD/AD LDS-Tools bereits installiert sind:

Get-WindowsCapability -Name Rsat* -Online | Select-Object DisplayName, Name, State

Wenn bei RSAT: Active Directory Domain Services and Lightweight Directory Services Tools der State Installed ist, sind die Tools vorhanden.

Falls nicht installiert, per PowerShell hinzufügen:

Add-WindowsCapability -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 -Online

Die Installation kann einige Minuten dauern.

Alternativ über die GUI: Settings → System → Optional Features → View features und nach RSAT: Active Directory Domain Services and Lightweight Directory Services Tools suchen und installieren.

4.2. Subnetz und Site hinzufügen

Active Directory Sites and Services (deutsch: Active Directory-Standorte und -Dienste) als Domänen-Administrator auf einem gejointen Rechner starten.

Rechtsklick auf Sites → New Site…:
Site-Name eingeben (z. B. schwanthalerstrasse) und den Standard-Site-Link DEFAULTIPSITELINK auswählen.

Subnetz anlegen: Unter Sites → Subnets rechtsklick New Subnet…:

Prefix: z. B. 192.168.21.0/24
Site: die neu erstellte Site zuordnen

Hinweis: Die neue Site benötigt nicht zwingend einen eigenen Domain Controller.

Wichtig beim Joinen neuer Workstations im neuen Subnetz: Trage als DNS-Server den ersten DC der Domäne ein, damit der Join und die Standortzuordnung korrekt funktionieren.

5. Zeitsynchronisation mit Chrony

Um Kerberos und Roaming-Desktops zuverlässig zu unterstützen, wird die Zeitsynchronisation auf beiden Domain-Controllern auf chrony umgestellt. Der zweite Domain-Controller vm011.schrottplatz.internal ist noch nicht erstellt; die folgenden Schritte gelten für vm117 und später identisch für vm011.

Hinweis: Kerberos toleriert nur geringe Zeitabweichungen (typisch ≤ 5 Minuten, empfohlen < 1 Minute). Beide DCs sollten dieselben vertrauenswürdigen Upstream-Zeitserver nutzen.

5.1. systemd-timesyncd deaktivieren

Falls aktiv, zuerst den einfachen Zeitsync-Dienst von systemd stoppen und deaktivieren:

sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd
# optional zusätzlich sperren:
# sudo systemctl mask systemd-timesyncd

5.1. Chrony installieren und konfigurieren

apt update
sudo apt install -y chrony

Auf beiden Maschinen (vm117 und später vm011) dieselben Zeitserver in /etc/chrony/chrony.conf eintragen (oder bestehende pool/server-Zeilen anpassen):

server time1.google.com iburst
server time2.google.com iburst

Chrony aktivieren & starten:

sudo systemctl enable --now chrony
sudo systemctl restart chrony

Funktion prüfen:

# Quellen und Status prüfen
chronyc sources -v
chronyc tracking
# Dienststatus
systemctl status chrony

Wenn Domain-Mitglieder ihre Zeit von den DCs beziehen sollen, in /etc/chrony/chrony.conf das eigene Netz zulassen und ggf. einen lokalen Stratum setzen:

allow 192.168.10.0/24
allow 192.168.21.0/24
local stratum 10

Dazu auch den entsprechenden Port freigeben: ufw allow 123/udp.

6. Zweiter Domain-Controller

Nach erfolgreichem Join kann der nameserver zusätzlich oder ersatzweise auf 127.0.0.1 gesetzt werden – so wie es bereits auf vm117 gemacht wurde.

Dieser Abschnitt beschreibt, wie der zweite Domain Controller vm011.schrottplatz.internal (192.168.21.11) zu einer bestehenden Samba-AD-Domäne schrottplatz.internal hinzugefügt wird. Eine ausführliche Referenz findest du im Samba-Wiki: Joining a Samba DC to an Existing Active Directory .

6.1. DNS-Auflösung vorbereiten (`/etc/resolv.conf`)

Bevor der zweite DC eingerichtet wird, muss zunächst die Namensauflösung korrekt auf den ersten DC zeigen (hier: vm117). Trage auf vm011 in /etc/resolv.conf Folgendes ein:

# /etc/resolv.conf
domain schrottplatz.internal
search schrottplatz.internal
nameserver 192.168.10.117

6.2. Kerberos-Konfiguration übernehmen (`/etc/krb5.conf`)

Kopiere die Kerberos-Konfiguration vom ersten DC vm117 auf vm011. Das war der entscheidende Schritt, damit der Join reibungslos funktionierte.

# Auf vm011 (als root):
cp -a /etc/krb5.conf /etc/krb5.conf.bak  # falls bereits vorhanden
# Dann krb5.conf von vm117 nach /etc/krb5.conf kopieren (z. B. per scp):
# scp root@vm117:/etc/krb5.conf /etc/krb5.conf

Hinweis: Lege auf vm011 vor dem Überschreiben eine Sicherung /etc/krb5.conf.bak an.

6.3. Vorhandene Samba-Konfiguration beiseite legen

Falls auf vm011 bereits eine /etc/samba/smb.conf existiert, benenne sie um, damit der Join saubere Einstellungen anlegen kann:

# Auf vm011
mv /etc/samba/smb.conf /etc/samba/smb.conf.save 2>/dev/null || true

6.4. Join als zusätzlicher Domain Controller

Führe nun den Join aus:

samba-tool domain join schrottplatz.internal DC \
  -U"SCHROTTPLATZ\\administrator" \
  --dns-backend=SAMBA_INTERNAL \
  --site=schwanthalerstrasse \
  --use-rfc2307 \
  --option="dns forwarder=192.168.21.1"

Wichtige Optionen erklärt

--use-rfc2307: Aktiviert RFC2307-Attribute (UID/GID) in AD. Das sorgt für einheitliche UID/GID-Zuordnungen auf beiden DCs. Ohne diese Option kann es zu Inkonsistenzen und Problemen kommen.
--site=schwanthalerstrasse: Ordnet den neuen DC direkt der AD-Site schwanthalerstrasse zu. Prüfe anschließend in Active Directory Sites and Services, ob der DC dort erscheint.
--dns-backend=SAMBA_INTERNAL: Verwendet den internen DNS-Server von Samba.
--option="dns forwarder=…": Setzt den DNS-Forwarder, z. B. Google 8.8.8.8 oder – wie hier – den UniFi-Gateway 192.168.21.1. Diese Option kann auch nachträglich in der smb.conf gepflegt werden.

6.5. Nach dem Join: RFC2307 in `smb.conf` sicherstellen

Prüfe, dass in /etc/samba/smb.conf (auf beiden DCs) die folgende Einstellung vorhanden ist:

[global]
  idmap_ldb:use rfc2307 = yes

Falls du Änderungen an der smb.conf vorgenommen hast, starte die Samba-Dienste neu. (Je nach Distribution z. B. systemctl restart samba-ad-dc.)

7. SSH per RSA-Key

Damit die Synchronisation des SYSVOL-Verzeichnisses sowie der Roaming-Profile zwischen den Domain Controllern funktioniert, muss ein gegenseitiger SSH-Zugang per RSA-Key zwischen vm117.schrottplatz.internal und vm011.schrottplatz.internal eingerichtet werden.

Vorgehen:

RSA-Schlüssel erstellen
Auf beiden Servern jeweils als root einen neuen RSA-Schlüssel erzeugen. Die Passphrase dabei leer lassen:
```
# Auf vm117
ssh-keygen -t rsa -b 4096 -C "root@vm117"
# Auf vm011
ssh-keygen -t rsa -b 4096 -C "root@vm011"
```

Public Keys austauschen
Den jeweils erstellten Public Key auf den anderen Server übertragen:

# Von vm117 nach vm011 (einmalig Passwort eingeben)
ssh-copy-id root@vm011
# Von vm011 nach vm117 (einmalig Passwort eingeben)
ssh-copy-id root@vm117

Verbindung testen
Nun sollte die Anmeldung ohne Passwort funktionieren:
```
# Auf vm117
ssh root@vm011
# Auf vm011
ssh root@vm117
```

8. SYSVOL mit rsync syncronisieren

Der Ordner /var/lib/samba/sysvol/ enthält u. a. die Domänenrichtlinien (Group Policies, GPOs), die im Group Policy Management unter Windows erstellt und verwaltet werden können.

Unter Windows-Servern wird dieser Ordner über das Distributed File System (DFS) repliziert. Samba als AD-Domain-Controller stellt diese Funktion jedoch nicht direkt bereit. Deshalb muss der SYSVOL-Ordner manuell zwischen den Domain Controllern synchronisiert werden.

Der SYSVOL-Ordner ist auf beiden DCs erreichbar:

\\vm011.schrottplatz.internal
\\vm117.schrottplatz.internal

bzw. unter \\schrottplatz.internal, wobei automatisch ein verfügbarer Domain Controller ausgewählt wird.

Damit beide DCs immer den gleichen SYSVOL-Inhalt haben, sollte ein automatischer rsync-Job eingerichtet werden. Am besten geschieht das auf dem zweiten DC (vm011).

Beispiel: Cronjob mit rsync

Mit Webmin oder direkt über crontab -e kann ein periodischer rsync-Job angelegt werden. Empfehlenswert ist ein Intervall von 5–15 Minuten.

rsync -XAavz --delete root@192.168.10.117:/var/lib/samba/sysvol/ /var/lib/samba/sysvol/

Erklärung der wichtigsten Parameter:

-X, --xattrs – Erhält Extended Attributes
-A, --acls – Erhält ACLs (impliziert --perms)
-a, --archive – Archivmodus (-rlptgoD)

-r – Rekursiv
-l – Symlinks als Symlinks kopieren
-p – Dateiberechtigungen erhalten
-t – Zeitstempel erhalten
-g – Gruppen erhalten
-o – Besitzer erhalten (nur Root)
-D – Geräte und Spezialdateien erhalten

-v, --verbose – Mehr Ausgaben
-z, --compress – Daten während der Übertragung komprimieren
--delete – Dateien löschen, die auf der Quelle nicht mehr vorhanden sind

Beispiel-Cronjob (alle 15 Minuten):

crontab -e und folgende Zeile einfügen:

*/15 * * * * rsync -XAavz --delete root@192.168.10.117:/var/lib/samba/sysvol/ /var/lib/samba/sysvol/

9. Roaming Profiles

9.1 Samba Freigabe erstellen

Roaming Profiles benötigen eine Samba-Freigabe, in der die Benutzerprofile gespeichert werden. In diesem Beispiel wird der Ordner /srv/samba/profiles auf den Servern vm011 und vm117 verwendet. Die Freigabe wird in der Datei /etc/samba/smb.conf wie folgt definiert:


[profiles]
  path = /srv/samba/profiles
  read only = no
  browseable = yes
  create mask = 0600
  directory mask = 0700
  vfs objects = acl_xattr

Nach dem Anlegen der Freigabe muss der Samba-Domain-Controller mit folgendem Befehl neu gestartet werden:


systemctl restart samba-ad-dc

9.2 Windows Profilpfad einstellen

Im RSAT-Tool Active Directory Users and Computers wird der Profilpfad eines Benutzers wie folgt gesetzt:

Rechtsklick auf den gewünschten Benutzer → Properties
Zum Reiter Profile wechseln
Im Feld Profile path den Netzwerkpfad angeben:
%LOGONSERVER%\profiles

Beim ersten Anmelden des Benutzers wird automatisch ein Unterordner mit dem Benutzernamen (z. B. christian.V6) erstellt.

Roaming Profile Pfad

9.3 Unison Sync einstellen

Angenommen, der Benutzername lautet christian.

Der Benutzer meldet sich zunächst auf einem Rechner an, der durch den Domain Controller vm011 verwaltet wird, und loggt sich anschließend wieder aus.
Dadurch wird ein neues Profilverzeichnis auf \\vm011\profiles mit dem Namen christian.V6 erstellt (bei Windows 10/11).
Dieses Profil kann nun einmalig mit rsync von vm011 auf vm117 übertragen werden:
```
rsync -XAavz root@vm011:/srv/samba/profiles/ /srv/samba/profiles
```
Nach dem Sync sollte auf beiden Servern (vm011 und vm117) der Ordner christian.V6 mit identischem Inhalt vorhanden sein.
Danach kann Unison für die regelmäßige Synchronisation eingerichtet werden. Dazu empfiehlt sich die Version 2.53.7 von Unison, da nur diese die Windows-ACLs korrekt behandelt.

Die Konfigurationsdatei wird unter /root/.unison/profiles.prf erstellt:


auto = true   # Automatisch nicht-konfliktbehaftete Änderungen übernehmen
batch = false   # Kein Batch-Modus, Rückfragen möglich
prefer = newer   # Neuere Dateien bevorzugen
times = true   # Änderungszeitpunkte synchronisieren
perms = -1   # Alle Berechtigungen synchronisieren
fastcheck = true   # Empfohlen für Windows
log = true
logfile = /var/log/unison-profiles.log
acl = true   # ACLs synchronisieren
xattrs = true   # Erweiterte Attribute synchronisieren
owner = true   # Dateibesitzer synchronisieren
group = true   # Gruppeninformationen synchronisieren

Weitere Informationen zu den Unison-Optionen finden sich in der offiziellen Dokumentation: Unison Manual auf GitHub

Zum Abschluss wird ein CronJob erstellt, der die Profil-Synchronisation alle 5 Minuten automatisch ausführt. Dazu mit folgendem Befehl die Crontab bearbeiten:

crontab -e

Folgende Zeile einfügen:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/unison profiles -batch

Damit wird der Befehl unison profiles -batch alle 5 Minuten ausgeführt und die Profile automatisch synchronisiert.

10. rfc2307 vergessen - Abhilfe

Status: laufend