Heterogene Netzwerke mit Servern und Clients, die sowohl unter Linux als auch Windows laufen, brauchen einen zentralen Verwaltungsserver für das Benutzerverzeichnis und ein einheitliches Protokoll für Netzwerkfreigaben. Windows-Systeme favorisieren dafür natürlich das Active Directory. Dieses nutzt offene Technologien wie Kerberos und LDAP, um Nutzer und Zugriffsrechte zu sichern. Also wäre es naheliegend, den Open-Source-Directory-Server "FreeIPA" in Betracht zu ziehen. Der zielt jedoch zuerst auf Linux-Systeme und das Nutzer- und Gruppenmanagement.

Um selbst als Domaincontroller (DC) aufzutreten, fehlen FreeIPA einige Funktionen, die ein Windows-System über das SMB(CIFS)-Protokoll bereitstellt. Eine vollständige DC-Implementierung hingegen liefert der bekannte Open-Source-Fileservice Samba in Version 4.

Das Samba-Projekt existiert seit mittlerweile 30 Jahren und begann als freier Unix-Client für "DEC Pathworks", was zu Teilen auf der Technologie des IBM OS/2 Lan Server beziehungsweise Microsoft LAN Manager beruhte. In den 1990ern und frühen 2000er-Jahren fand das Open-Source-Projekt zunächst wenig Gegenliebe bei Microsoft und es kam immer wieder zu Streitereien. Doch spätestens mit Microsofts Umdenken weg von "Linux is cancer" (Steve Balmer) hin zu "Microsoft loves Linux" (Satya Nadella) änderte sich das Verhältnis des Softwareriesen zum Open-Source-Projekt. Schon seit 2011 gehören Microsoft-Mitarbeiter zum Samba-Entwicklerteam. Zudem hat Microsoft das SMB-Protokoll nun offen dokumentiert, was den Samba-Entwicklern hilft.

Seit Windows Server 2003 kann ein Samba-Server Mitglied eines bestehenden AD-Forest werden. Dazu war aber immer ein Windows-Server als Domaincontroller nötig. Seit der Version 4 kann Samba nun selbst die Rolle des Domaincontrollers übernehmen. Die Implementierung erlaubt dabei auch den gemischten Betrieb von Windows- und Linux-Servern als Domaincontroller. Natürlich werden Anwender mit einer bestehenden Windows-Server-Infrastruktur nicht ihre Systeme gegen Samba-Server tauschen. Die Lösung empfiehlt sich für Umgebungen, die auf der Clientseite Windows, macOS und Linux verwenden, ihre Server-Dienste jedoch auf Linux-Systemen betreiben. Ein Samba-Server dient in diesem Szenario als zentraler Directory-Dienst für Windows-, macOS- und Linux-Systeme sowie als Fileserver für alle.

Ein Directory-Server beherbergt eine ganze Reihe von Diensten und Protokollen wie DNS, Kerberos und LDAP. Damit diese im ADS-DC optimal zusammenarbeiten, integriert Samba alle Dienste. Andere Produkte wie FreeIPA beispielsweise setzen sich aus verschiedenen Komponenten wie "MIT Kerberos", "OpenLDAP" und "Bind9" zusammen. Die vollständige Integration der Bibliotheken in das Samba-ADS-Paket sorgt dabei jedoch für Probleme bei verschiedenen Distributionen.

Die Fedora- und EL-Distributionen setzen auf "MIT Kerberos" und liefern dessen Pakete mit. Dieser Ansatz funktioniert jedoch im ADS-Betrieb (noch) nicht richtig. Zwar hat das Samba-Projekt auch einen "TechPreview"-Build des Samba-Servers samt MIT-Kerberos veröffentlicht. Jedoch gilt dieser aktuell als noch nicht stabil. Samba präferiert für den AD-Service die "Heimdahl"-Implemetierung von Kerberos. Daher lässt sich ein Samba-ADS auf Fedora- und EL-Distributionen nur über Umwege einrichten, die entweder Drittanbieter-Repositories benötigen oder Samba aus den Quellen kompilieren.

In unserem Testsetup verwenden wir daher zwei Debian-Varianten. Einmal das aktuelle Debian 11 innerhalb einer virtuellen Maschine. Zum anderen kommt ein Arm-Einplatinencomputer Cubietruck mit Armbian 5.9 zum Einsatz, das auf Debian 10 basiert. Für kleinere Umgebungen reicht ein Einplatinenrechner dieser Klasse (ARM V7 Dual-Core, 2 GByte RAM) als ADS völlig aus. In der Vorbereitung brauchen die Rechner ein Standard-Debian-(Armbian)-Minimalsetup mit einer statischen IP-Adresse und der korrekten Konfiguration von "/etc/ hostname" und "/etc/hosts". Der erste Rechner mit ADS wird zudem die Rolle des DNS-Servers übernehmen. Sollten Sie bereits einen DHCP-Dienst im LAN laufen haben, muss dieser auf die IP-Adresse des ADS als DNS verweisen (DHCP-Option 6) und den Domain-Namen übermitteln (DHCP-Option 15).

Während der Installation muss der primäre ADS-Knoten natürlich auf einen bestehenden DNS-Server zugreifen können. Das DNS-Setup ändern Sie nach dem initialen Setup. Wie bei allen anderen Diensten, die Verschlüsselung verwenden, ist eine korrekte Systemzeit nötig. In einem ADS-Netzwerk fungiert der Domaincontroller auch als Zeitquelle für seine Clients. Sie müssen daher vor der Installation sicherstellen, dass die Systemzeit und Zeitzone des Servers passen und ein Dienst wie ntp oder chrony für den automatischen Zeitabgleich mit dem Internet sorgt. Das ist in unserem Setup mit einem ARM-Einplatinen-Computer besonders wichtig, denn Systeme wie ein Raspberry Pi oder Cubietruck verfügen über keine Hardware-Uhr.

Soll der Samba-Server erweiterte Zugriffsrechte verwalten können (Access Control Lists, ACL), muss das Dateisystem des Servers erweiterte Attribute erlauben. Die sind bei modernen Linux-Installationen mit XFS oder BTRFS eigentlich immer aktiviert. Auch bei EXT4-Dateisystemen ist das mittlerweile der Standard. Falls Sie EXT4 nutzen, können Sie vor der Installation zur Sicherheit in "/boot/config-<Aktueller Kernel>" nachsehen, ob die nötigen Einstellungen aktiv sind:

Richten Sie nun die benötigten Pakete auf Ihrem Debian-Server ein mit

Die Samba-Basisinstallation bringt eine Konfigurationsdatei als Vorlage mit. Das ADS-Setup erzeugt jedoch eine neue, weswegen Sie vor dem Setup die alte entfernen müssen durch rm /etc/samba/smb.conf. Durch das eigentliche AD-Setup führt dann das Samba-Tool mittels samba-tool domain-provision --interactive. Ohne weitere Parameter wird das Samba-Tool für alle nötigen Dienste (DNS, Kerberos) auf die Samba-eigenen Services zurückgreifen. Geben Sie auf Anfrage die Informationen zum Domain- und Realm-Namen ein. Hier ist es auch wichtig, dass Sie Ihren bestehenden DNS-Server als Forwarder angeben. Zum Schluss erstellt das Setup die passenden Konfigurationsdateien und eine Registry. Die Datei "smb.conf" legt das Set-up gleich im korrekten Verzeichnis an. Die Kerberos-Konfiguration hingegen müssen sie händisch in das richtige Verzeichnis kopieren mit cp /var/lib/samba/ private/ krb5.conf /etc/. Samba liefert für den AD-Betrieb ein gesondertes Binary mit. Daher müssen Sie verhindern, dass die regulären Samba-Dienste laufen oder versehentlich gestartet werden:

Stattdessen nutzen Sie den AD-Server-Service, welcher alle Dienste integriert:

Sobald der Samba-AD-Server läuft, übernimmt er die DNS-Rolle für das Netzwerk. Auf dem DC-System selbst müssen Sie nun die lokale DNS-Auflösung anpassen. Das Samba-Tool hat Ihren bestehenden DNS-Server in die Konfiguration auf "/etc/samba/smb.conf" eingefügt:

Der lokale DNS-Resolver muss daher auch auf das lokale System verweisen. Moderne Distributionen nutzen den Dienst "systemd-resolved". Dieser erkennt Netzwerkänderungen und passt die DNS-Konfiguration dynamisch an, indem er die Datei "/etc/resolv.conf" bei Bedarf überschreibt. Das brauchen Anwender auf Clients, die öfter das LAN wechseln oder VPN-Verbindungen aufbauen. Unser Domaincontroller hingegen fordert eine statische DNS-Konfiguration. Dazu schalten Sie den systemd-resolved-Dienst aus und lösen den Link der "resolv.conf"-Datei auf:

Erstellen Sie mit einem Editor Ihrer Wahl eine neue "/etc/resolv.conf" mit lediglich zwei Einträgen:

Prüfen Sie im Anschluss, ob sowohl eine lokale als auch die weitergeleitete DNS-Anfrage funktionieren. Der Befehl host -t SRV _ldap._tcp.<Domain Name> muss mit "has SRV record 0 0 389 <FQDN des DC>" antworten, während eine reguläre DNS-Anfrage an das Internet über den Forwarder beantwortet wird:

Fehler im DNS-Setup gehören zu den häufigsten Ursachen von Problemen bei Directory-Setups. Also muss dieser Dienst in Ihrer Umgebung auf jeden Fall korrekt funktionieren.

Das zuvor genutzte Samba-Tool kann natürlich mehr, als nur interaktiv durch das AD-Setup zu führen. Es dient ebenso als CLI für das AD-Management. Nutzer und Gruppenzugehörigkeiten lassen sich damit sehr leicht verwalten. Bevor Sie mit dem Samba-Tool arbeiten können, müssen Sie sich erst einmal als Administrator anmelden mit kinit Administrator. Dann können Sie das Verzeichnis managen:

Das Praktische an der CLI-Methode ist dabei, dass sich Standard-Aufgaben per Skript abwickeln lassen. Ein simples Bash-Skript könnte dabei die DNS-Konfiguration einer bestehenden "/etc/hosts"-Datei auslesen und diese Hosts via samba-tool dns add in den AD-integrierten DNS übertragen.

Bevor Sie einen Client dem AD hinzufügen, müssen Sie natürlich prüfen, ob dessen DNS-Konfiguration auf den DC-Server zeigt. In unserem Beispiel setzen wir ein Windows 10 Enterprise und Windows Server 2022 ein. In der Windows-10-Enterprise-Version 21H2 gibt es keinen "Join-Domain"-Button, den frühere Win­dows-Versionen in der Systemeinstellung zeigten. Wir gehen daher auf der englischen Windows-Version durch folgende Menüs: "Start / Settings / System / About / Rename this PC (advanced)". Im "System Properties"-Dialog klicken Sie nun auf "Change" und tragen im Feld "Member of" unter "Domain" den Namen Ihrer Domain ein. Jetzt fragt Windows nach einem User mit der Berechtigung "Join Domain". Geben Sie einfach "Administrator" mit dem passenden Passwort ein und das System wird Teil der Domain. Nach einem Neustart können Sie sich am Win­dows-Client mit einem der zuvor angelegten Benutzer anmelden.

Möchten Sie auf diesem Windows-Client die GUI-Tools zur AD-Verwaltung nutzen, können Sie diese von der Microsoft-Seite unter [1] herunterladen. Win­dows Server 2022 liefert die passenden Tools mit. Ähnlich simpel funktioniert das DS-Clientsetup auch auf Linux-Systemen. Bei Clients gibt es keine Kompatibilitätsprobleme mit verschiedenen Kerberos-Versionen, solange diese das AD zur Login-Verifikation nutzen und keinen lokalen Samba-Dienst betreiben. EL- und Fedora-Systeme können der Domain genauso beitreten wie Debian-Systeme. Wir verwenden eine Fedora-36-Workstation. Installieren Sie zuerst die nötigen Pakete:

Bei Bedarf passen Sie die DNS-Konfiguration von "systemd-resolved" wie zuvor beschrieben an. Prüfen Sie, ob die Konfiguration stimmt und der Fedora-Client den DC kontaktieren kann: realm discover <Domain-Name>. Wenn es an dieser keine Fehlermeldung gibt, fügen Sie den Linux-Client der Domäne hinzu: realm join <Domain-Name> -v. Der Schalter "-v" gibt alle Details des Vorgangs auf der CLI aus. Am Ende des Prozesses bestätigt "Successfully enrolled machine in realm" den Beitritt zur Domäne. Jetzt können Sie sich an der Linux-GUI oder CLI mit einem Domain-User anmelden.

Natürlich sollte ein DC nicht alleine ein Netzwerk verwalten, also fügen Sie mindestens einen weiteren DC hinzu. Als Best Practice gilt auch, dass Domaincontroller keine Dateifreigaben bereitstellen, sondern sich nur ihren Aufgaben als DC widmen. Reguläre "Domain Member"-Server ohne DC-Funktionen beherbergen dann die Dateisystem-Freigaben, dazu später mehr. Das Setup weiterer AD-Server erfolgt nach dem gleichen Schema wie das AD-Setup: Pakete einrichten, "smb.conf" löschen, DNS-Konfiguration prüfen und anpassen, falls nötig. Auf einem weiteren DC-Server führen Sie das Samba-Tool wie folgt aus:

Das Tool wird dann nach dem Passwort des Administrators fragen und das AD-Setup durchführen. Im Anschluss deaktivieren und maskieren Sie die regulären Samba-Dienste wie auf dem ersten DC, aktivieren dafür den "samba-ad-dc"-Service und übernehmen die Kerberos-Konfiguration.

Wenn Sie samba-tool domain join <Domain Name> MEMBER anstatt "DC" angeben, tritt das System nur als Mitglied und nicht als Domänencontroller bei. Das funktioniert aber nicht immer fehlerfrei und auch nicht bei allen Distributionen. Der etwas aufwendigere Weg, der dann aber auch bei anderen Distributionen wie Fedora oder EL funktioniert, nutzt eine manuelle Konfiguration.

Das Setup eines Member-Servers unterscheidet sich dabei vom bereits beschriebenen Clientsetup. Für den Client genügt der sssd-Dienst mit Kerberos. Der Member auf der anderen Seite klinkt sich über den Winbind-Dienst von Samba in die Domäne, ohne sssd zu benötigen. Auf einem EL8-System, das als Domain-Member dienen soll, richten Sie zunächst die nötigen Dienste ein:

Als "EL8" bezeichnen wir übrigens alle Linux-Distribtionen, die Klone von Red Hat Enterprise Linux 8 sind. Dazu gehören beispielsweise Alma- oder Rocky-Linux und Centos Streams 8. Passen Sie nun die Konfiguration der "smb.conf" für den Member-Server an:

Damit legen Sie fest, dass Winbind via ADS die Nutzer abfragt. Damit auch das lokale System Windbind verwendet, um Benutzer und deren IDs zu ermitteln, müssen Sie zudem die Datei "/etc/nsswitch.conf" ändern. Die Einträge für "passwd" und "group" sollten anschließend in etwa so aussehen:

Das Linux-System wird dann zuerst die lokalen passwd- und group-Dateien nach Nutzern beziehungsweise Gruppen und deren IDs durchsuchen. Wenn es dort nichts findet, fragt es via Winbind die Informationen von der Domäne ab. Bei einem AD-Clientsetup steht hier statt "winbind" dann beispielsweise "sssd". Jetzt können Sie den Member-Server via net ads join -U Administrator als Member in der Domain registrieren und die Dienste "winbind" und "smb" starten. Dabei kann es zu einer Fehlermeldung kommen, dass die DNS-Registrierung nicht funktioniert hat. Das ist nicht weiter tragisch, tragen Sie den Server einfach händisch im ADS-integrierten DNS ein. Danach können Sie auf dem Member-Server Ordner freigeben und als Shares im ADS-Verband zur Verfügung stellen.

Üblicherweise speichert ein Samba-Server seine Konfiguration in der Textdatei "/etc/samba/smb.conf". Das erschwert einem Windows-Administratror die Konfiguration der Samba-Dienste. Alternativ kann der Dienst seine Konfiguration ganz oder teilweise in einer Registry sichern. Diese Funktion kommt gerne in Samba-Clustern zum Einsatz. In dem hier beschriebenen Domain-Setup erlaubt das beispielsweise, dass ein Administrator von einer Windows-Workstation aus die Samba-Konfiguration eines Linux-Servers mithilfe des Registry-Editors anpassen kann. Um die komplette Konfiguration eines Samba-Servers in die Registry zu packen, braucht es eine "/etc/samba/smb. conf" mit genau zwei Zeilen:

In diesem Fall ignoriert Samba den kompletten Inhalt der Datei "smb.conf" und liest die Informationen ausschließlich aus der Registry. Das ist in vielen Fällen dann doch zu strikt. Daher gibt es zwei andere Optionen: "include = registry" wertet die komplette "smb.conf"-Datei zuzüglich der Registry-Einträge aus. Die Option "registry shares = yes" liest nur Informationen zu Freigaben aus der Registry. Der Administrator kann dann aber auch nur die Freigaben, nicht aber die grundlegende Serverkonfiguration in der Registry ändern. Dabei wertet Samba beim Start nicht die kompletten Share-Informationen aus. Erst wenn ein Client auf eine Freigabe zugreifen möchte, sucht Samba nach den zugehörigen Informationen in der Regsitry. Alle Schlüssel sichert Samba in "HKLM/Software/Samba/smbconf". Die Registry lässt sich mit den ausreichenden Rechten mittels regedit via LAN bearbeiten oder mit dem Linux-CLI-Tool "samba-regedit" im klassichen GTK-Design. Wer mit einer Registry arbeiten möchte, kann via net conf import eine bestehende "smb.conf " in die Registry übertragen.

In kleinen und mittleren Netzwerken mit heterogenen Systemen leistet ein Samba-Domaincontroller gute Dienste und sorgt für einen reibungslosen Dateienaustausch zwischen den verschiedenen Client-Systemen. In diesem Artikel haben wir versucht, möglichst viele Lösungswege für verschiedene Distributionen vorzustellen. Das Ganze funktioniert neben Windows und Linux dann natürlich ebenfalls auf einem Mac, auch wenn wir hier nicht auf die Details zur AD-Anbindung eines macOS-Clients eingehen konnten.