Von authdb zu fenrirds – ein Verzeichnisdienst, dem Windows beitreten kann
Aus der kleinen Benutzerdatenbank authdb ist der FenrirDirectoryServer geworden: ein Active-Directory-kompatibler Domänencontroller für FenrirOS. Ein Windows-11-Rechner tritt der Domäne bei, und Benutzer melden sich daran an.
Ein Rückblick: wie es dazu kam, was in den letzten Tagen passiert ist und was noch fehlt.
Wo es herkommt: authdb
Seit November 2024 die Benutzerdatenbank hinter den tuxist-Diensten.
authdb begann als zentrale Anmeldung für die eigenen Dienste: Benutzer, Gruppen, Clients und Dienste je Domain, eine Weboberfläche zur Verwaltung, eine JSON-API und eine Client-Bibliothek, gegen die sich zum Beispiel proxyplus anmeldet. Rechte werden über eigene Richtlinien vergeben. Mit der Zeit kamen ein Cluster-Modus dazu – die Daten liegen per Erasure Coding (libparitypp) verteilt auf mehreren Knoten – sowie eine Master/Slave-Replikation, ein Kerberos-KDC und ein LDAP-Plugin, das allerdings nur lesen konnte.
Die Entscheidung: ein echter Domänencontroller
Ende Oktober 2026 wird aus authdb der FenrirDirectoryServer.
FenrirOS hat mit adconnect und sharedd schon die Clientseite für Active Directory. Was fehlte, war ein eigener Server, dem nicht nur Linux-Rechner, sondern auch Windows beitreten können. Dafür wurde das Projekt vollständig umbenannt – Dienst fenrirds, Werkzeug fenrirdsctl, Konfigurationsschlüssel FENRIRDS; alte AUTHDB-Konfigurationen werden weiter gelesen – und um eine Verzeichnisschicht nach AD-Vorbild erweitert. Benutzer, Gruppen und Computer sind seitdem echte Verzeichnisobjekte mit objectSid, objectGUID und den üblichen Attributen. Beim ersten Start legt fenrirds eine Domäne mit allen Standardcontainern, Konten und Gruppen an.
LDAP
Lesen und Schreiben (add, modify, delete, modrdn), rootDSE, Anmeldung per Passwort, Kerberos (GSSAPI) oder NTLM (GSS-SPNEGO) samt signierter und verschlüsselter Verbindung, dazu der CLDAP-Netlogon-Ping.
Kerberos
KDC mit PAC für Windows (Logon-Info, Signaturen und die Puffer, die aktuelle Windows-Versionen verlangen), Suche nach sAMAccountName, SPN und UPN.
DNS
Eigener DNS-Server mit den SRV-Einträgen, über die Windows und Linux den Domänencontroller finden.
SMB und RPC
SMB2/3-Server für IPC$ mit den RPC-Diensten lsarpc, samr und netlogon – das braucht Windows für den Domänenbeitritt.
NTLM
Serverseitiges NTLMv2, damit sich ein Rechner, der noch kein Mitglied ist, überhaupt anmelden kann.
Weboberfläche
Benutzer, Gruppen, Computer und Richtlinien direkt auf den Verzeichnisobjekten. Ein Konto lässt sich nachträglich zum Windows-Konto machen.
Der Weg zum ersten Windows-Beitritt
Windows verzeiht nichts – jeder behobene Fehler brachte die nächste, etwas spätere Fehlermeldung.
Getestet wurde gegen einen echten Windows-11-Rechner im LAN. Einige Stationen auf dem Weg:
- Die CLDAP-Antwort, mit der Windows den Domänencontroller sucht, braucht komprimierte DNS-Namen und genau die richtigen Versionsbits – Samba ist da großzügiger als Windows.
- DNS-Antworten auf SRV-Abfragen müssen die Adresse des Servers gleich mitliefern.
- Windows beginnt die SMB-Verbindung mit einem alten SMB1-Negotiate. Der Server muss mit SMB2 antworten, sonst bricht die Verbindung ab.
- Kerberos läuft bevorzugt über UDP, nicht über TCP.
- Nach der NTLM-Anmeldung verschlüsselt Windows die LDAP-Verbindung – also musste NTLM-Signieren und -Versiegeln her.
- Ein Feld zu viel in einer RPC-Antwort verschob den Rückgabewert um vier Bytes und erzeugte wechselnde, scheinbar zufällige Fehler.
- Das Maschinenkennwort, das Windows beim Beitritt setzt, liegt an einer anderen Stelle im Paket als erwartet und ist mit einem anderen Schlüssel verschlüsselt.
Am 25. Oktober lief der Beitritt durch. Danach kam die Anmeldung eines Domänenbenutzers: Hier ging es um Feinheiten im PAC und in den Kerberos-Tickets – etwa dass Windows sich mit dem UPN anmeldet, im Ticket aber der sAMAccountName stehen muss. Seitdem erscheint der Desktop.
Eine Datenquelle statt zwei
Die alte authdb-Datenhaltung und das neue Verzeichnis sind zusammengewachsen.
Anfangs gab es die bisherigen authdb-Benutzer und daneben die neuen Verzeichnisobjekte. Inzwischen sind Benutzer und Gruppen nur noch Verzeichnisobjekte: Weboberfläche, Web-Login, Sitzungen und Kerberos arbeiten auf denselben Daten. Vorhandene Daten werden beim Import übernommen. Die eigenen fenrirds-Richtlinien bleiben bewusst getrennt von den Windows-Gruppenrichtlinien.
Für FenrirOS gibt es außerdem eine Zuordnung zwischen den UUID-Benutzerkennungen des Systems und den SIDs aus dem Verzeichnis – so stimmen Besitzer und Berechtigungen auf SMB-Freigaben über ksmbd.
Neu in den letzten Tagen
Einrichtung, Cluster und Replikation sind deutlich einfacher geworden.
🧙 Einrichtungsassistent
Fehlt die Konfigurationsdatei, startet fenrirds einen Assistenten im Browser. Danach legt man das erste Administratorkonto an.
🔒 Rechtetrennung
Der Server läuft ohne Root-Rechte. Nur ein kleiner Hilfsprozess bleibt root, schreibt geprüfte Einstellungen in die Konfiguration und startet den Server bei Bedarf neu. So lassen sich Einstellungen direkt in der Weboberfläche ändern.
📡 Knoten per mDNS finden
Ein noch nicht eingerichteter Server meldet sich im lokalen Netz. In der Weboberfläche eines laufenden Servers erscheint er in einer Liste und wird mit einem Klick als Replikations-Slave oder als weiterer Cluster-Knoten eingerichtet.
🔑 Zertifikate automatisch
Ist ein TLS-Zertifikat konfiguriert, aber nicht vorhanden, erzeugt fenrirds ein selbstsigniertes – mit libnetplus, ganz ohne openssl.
🗄️ Cluster ab drei Knoten
Ein Cluster braucht jetzt mindestens drei Knoten. Kommt einer dazu, verteilen sich die Daten automatisch neu – bisher bekamen Knoten über die Zahl der Daten- und Paritätsblöcke hinaus gar keine Daten.
🛠️ Robusteres Cluster-Netz
Ein einzelnes verlorenes Paket konnte eine Cluster-Anfrage bisher fünf Sekunden aufhalten. Das ist in libparitypp behoben, ebenso ein Speicherleck bei abgebrochenen Verbindungen.
Was noch fehlt
fenrirds ist noch kein vollständiger Ersatz für einen Windows-Server.
- Gruppenrichtlinien über SYSVOL gibt es noch nicht – die Anmeldung funktioniert trotzdem.
- Die NTLM-Durchreichung über netlogon für Mitgliedsserver ist noch nicht fertig.
- LDAP: seitenweise Suchergebnisse, LDAPS und der Global-Catalog-Port stehen noch aus.
- DNS: dynamische Updates der Clients und die Weiterleitung an andere DNS-Server fehlen.
- Kennwortänderung über kpasswd ist noch offen.
- Der Einrichtungsassistent ist ohne Anmeldung erreichbar, und beim Hinzufügen eines Knotens gehen dessen Schlüssel noch unverschlüsselt über das lokale Netz. Neue Server sollten deshalb nur in einem vertrauenswürdigen Netz eingerichtet werden.
Ausprobieren und Rückmeldung geben 🐺
Fehlerberichte und Erfahrungen – gerade mit Windows-Clients – bitte an: jan.koester@tuxist.de
Comments
No comments yet.
Leave a comment