Mit der Version 4.4-4 von Univention Corporate Server (UCS) ist das Synchronisieren von Passwort-Hashes zwischen einer Microsoft Active Directory Domäne und einer UCS-Domäne deutlich sicherer und vor allem weniger fehleranfällig geworden. Während frühere Versionen des AD Connector lediglich NTLM-Hashes abgleichen konnten, liest der AD Connector von UCS 4.4-4 nun auch neuere Hashes aus, die so genannten Kerberos Hashes (auch Kerberos Keys genannt), mit denen ein Single-Sign-on an unterschiedlichen Anwendungen möglich ist.
Ich bin Auszubildende bei Univention (Fachinformatiker*in für Anwendungsentwicklung) im zweiten Lehrjahr. Ich war an der Entwicklung des neuen Features beteiligt und habe dazu an drei Baustellen gearbeitet: Neben dem AD Connector habe ich auch das OpenLDAP-Overlay-Modul und den S4 Connector (Samba) angepasst, um das neue Feature zu ermöglichen. In diesem Blogartikel möchte ich Ihnen erklären, was Kerberos Hashes sind, einen Einblick in die Entwicklung des neuen Features geben und erklären, an welchen UCS-Stellschrauben ich dafür gedreht habe.
Was macht der AD Connector von UCS
Die App AD Connector führt ein bestehendes Microsoft Active Directory und eine mit UCS verwaltete Domäne zusammen. So vermeiden Administratoren Mehraufwand durch doppelte Administration und richten einen automatischen Abgleich zwischen MS Active Directory und dem OpenLDAP-Verzeichnisdienst von Univention Corporate Server ein. Außer Benutzer-, Gruppen- und Rechner-Objekten synchronisiert der AD Connector auch verschlüsselte Passwörter.
Frühere Versionen der App konnten ausschließlich NTLM-Hashes abgleichen (NTLM = NT LAN Manager, Sammlung von Microsoft-Protokollen), was inzwischen als nicht mehr sicher und technisch veraltet gilt. Der neue AD Connector liest nun auch Kerberos Hashes aus. Die Implementierung des neuen Features hat mich und meine Kollegen vor einige Herausforderungen gestellt, denn UCS speichert durch die neue Synchronisation unterschiedlich gestaltete Kennwörter.
Was sind Kerberos Hashes?
Kerberos ist ein netzwerkbasiertes SSO-Protokoll (Single Sign-on), das anders als NTLM zum Übermitteln der Authentifizierungsdaten temporäre Tickets nutzt. Wenn Benutzer*innen beispielsweise Zugriff auf einen Dienst in der Domäne benötigen, lassen sie sich zunächst vom Authentifizierungsserver (AS, Authentication Service) des Key Distribution Center (KDC) ein Ticket Granting Ticket (TGT) ausstellen. Das TGT enthält in verschlüsselter Form unter anderem die IP-Adresse des anfragenden Clients, die Gültigkeitsdauer und einen zuvor erzeugten Sitzungsschlüssel (Session Key). Anschließend können Anwender*innen ein Service-Ticket beim Ticket Granting Server der Domäne für angeschlossene Dienste ausstellen lassen. Vereinfacht gesagt: Alle beteiligten Systeme prüfen die Gültigkeit der Ticketinformationen mit dieser Instanz.
Die Kennwörter der Benutzer*innen werden mit mehreren Hashing-Algorithmen gehasht und in der Kerberos-Datenbank abgelegt. Wenn jemand versucht, sich zu authentifizieren, werden die dort hinterlegten Hashes zum Vergleich herangezogen. Damit die Kompatibilität zwischen verschiedenen Services gewährleistet ist, gibt es eine Liste von unterschiedlichen Hashes. Manche Dienste kommen nur mit älteren Hashes (z. B. DES) zurecht, andere unterstützen auch neuere Algorithmen (etwa AES).
Wird ein neuer Account in der UCS-Domäne angelegt, dann werden aus dem Passwort insgesamt fünf Hashes berechnet:
DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC_MD5
AES128_HMAC_SHA1
AES256_HMAC_SHA1
In einer Umgebung mit einer Microsoft AD Domäne und einer UCS-Domäne gibt es zwei verschiedene Kerberos-Dienste (einen pro Domäne). Zwischen diesen beiden Diensten synchronisiert der AD Connector nun die Kerberos Hashes.
Hash und Salt
Vorgängerversionen des AD Connector glichen bei einer Passwortänderung in der AD-Domäne immer nur einen der Hashes ab: den NTLM-Hash (RC4_HMAC_MD5
bei Kerberos). Alle anderen Hashes wurden nicht synchronisiert, in der UCS-Domäne wurde also nur der Hash RC4_HMAC_MD5
überschrieben. Da der Kerberos-Dienst stärkere Hashes wie die AES-Keys bevorzugt, trat die Passwortänderung nicht in Kraft – die AES-Keys wurden ja noch mit dem alten Passwort erzeugt. Das führte dazu, dass Benutzer*innen in der UCS-Domäne nur ihr altes Passwort zur Authentifikation nutzen konnten.
Um das Problem zu lösen, mussten wir zunächst prüfen, ob eine Synchronisation der Kerberos Keys überhaupt möglich ist bzw. ob der Kerberos-Dienst Hashes aus einem fremden Realm (Administrationsbereich) verwenden kann. Hier kommt uns das so genannte Salting in die Quere: Ein Benutzerpasswort wird vor dem Hashing um eine Zeichenkette (den Salt) erweitert. In der Voreinstellung beinhaltet dieser den Namen der Domäne bzw. des Kerberos-Realms. So ist garantiert, dass identische Passwörter stets zu unterschiedlichen Schlüsselwerten führen. Für uns heißt das, dass wir in den zwei Realms unterschiedliche Salts haben, das heißt, der UCS-Kerberos-Dienst könnte Hashes aus den AD-Kerberos-Diensten eigentlich gar nicht verwenden, weil er den Salt nicht kennt.
Ich habe mich daher gefragt, ob die eingegebenen Passwörter mit dem fremden Realm-Namen gesaltet werden würden, bevor der Hash erzeugt und mit dem Hash in der Kerberbos Datenbank verglichen wird. Oder ist es vielmehr so, dass Kerberos für den Salt den eigenen Realm-Namen heranzieht, sodass beim Vergleichen (auch bei korrekter Passworteingabe) keine Authentifizierung gelingt?
Die Lösung: Prä-Authentifizierung
Glücklicherweise wird der Salt unverschlüsselt zusammen mit dem Hash gespeichert, und auch beim Synchronisieren unverschlüsselt übertragen. Wenn der Abgleich dieser Daten also gelingt, kann der Kerberos-Dienst den Salt auslesen, das heißt, dass das Key Distribution Center (KDC) immer den korrekten Salt kennt. Allerdings muss dieser Salt vor der Authentifizierung übertragen werden. Der Client, der sich anmelden möchte, muss den Salt kennen, da er selbst sein Passwort korrekt salten und hashen muss, bevor er die Angaben ans KDC weiterleitet.
Tatsächlich überträgt der Kerberos-Dienst den Salt, bevor die Authentifizierung stattfindet. Dies tut er während eines Verfahrens namens Prä-Authentifizierung, das mit der aktuellen Kerberos-Version 5 eingeführt wurde. Die Prä-Authentifizierung verschickt vorab bestimmte Informationen, die bestätigen, dass ein Client das richtige Kennwort kennt. Erst wenn das erfolgreich war, verschickt Kerberos das Ticket Granting Ticket. Der Client stellt also zuerst eine Anfrage beim Authentication Service und erhält als Antwort die Meldung KRB5KDC_ERR_PREAUTH_REQUIRED
– ein Fehler, den Kerberos intern behandelt.
Die Meldung ist aber nicht einfach nur ein Fehler, sondern sie leitet auch einige andere Informationen vom KDC an den Client weiter. So verrät sie etwa, welcher Hash eingesetzt wird und gibt auch Aufschlüsse zum Salt, den der Client dann verwenden kann. Diese Prä-Authentifizierung sorgt also dafür, Kerberos Keys zwischen verschiedenen Realms zu synchronisieren.
Das Overlay-Modul k5pwd
Damit der Abgleich mit der UCS-Domäne gelingt, ist es außerdem erforderlich, dass der OpenLDAP-Verzeichnisdienst die Hashes auslesen kann. Dazu mussten wir unser eigenes Overlay-Modul k5pwd in UCS anpassen. Dieses kommt zum Einsatz, wenn ein Passwort in der AD-Domäne geändert und mit der UCS-Domäne abgeglichen wird. Der LDAP-Verzeichnisdienst braucht zum Authentifizieren per simple bind das Attribut userPassword. Dieses kann er jedoch nicht erzeugen, da AD nur den NT Hash schickt. Somit gibt es keine Möglichkeit, das Attribut in OpenLDAP zu erzeugen, mit dem der Verzeichnisdienst die Passworteingabe vergleicht.
Das k5pwd-Modul hilft aus: Es schreibt die Zeichenkette {K5KEY}
in das userPassword-Attribut, hasht das vom Anwender eingegebene Kennwort und vergleicht es mit dem NT Hash, den AD verschickt hat. Der NT Hash hat keinen Salt, also mussten wir das Overlay-Modul so anpassen, dass es genau wie das Key Distribution Center von Kerberos den korrekten Salt aus den synchronisierten Keys extrahiert und zum Hashen verwendet.
Aus diesem Grund müssen alle LDAP-Server vor der Aktivierung des neuen Kerberos-Syncs auf UCS 4.4-4 aktualisiert werden.
Und was ist mit Samba?
Als Letztes galt es, die Unterschiede zwischen Samba und Microsoft Windows zu überbrücken und unseren S4 Connector anzupassen. Da Active Directory in der Voreinstellung nicht mehr den DES_CBC_CRC
erzeugt, aber Samba auf die bereits genannten fünf Hashes besteht, mussten wir diese Regel umgehen, um die Hashes übertragen zu können. Den NTLM-Hash übertragen wir nun quasi noch einmal als Dummy und leiten ihn anstelle des DES_CBC_CRC-Hashes an Samba weiter – Problem gelöst. Dieses Vorgehen ist auch von Microsoft verwendet worden um rückwärtskompatibel zu bleiben.
Viel gelernt!
Ich fand die Zeit, die ich mit der Lösung dieses Problems verbringen durfte, sehr spannend. Ich habe viel über Kerberos, Samba, Microsoft Active Directory, OpenLDAP und vor allem über das Zusammenspiel aller Komponenten lernen können. Ich bin sehr froh, die Chance bekommen zu haben, an solchen komplexeren Problemen arbeiten zu können. Wenn Sie eine Frage zur neuen Erweiterung oder der Technik dahinter haben, stellen Sie diese gerne in unserem Forum oder kommentieren diesen Artikel.
Kommentare
Urs Aregger
Vielen Dank für diesen Beitrag. Damit kämpfe ich nun seit ein paar Tagen – leider bis jetzt erfolglos. Was muss ich denn von der AD-Domäne wissen oder kennen, um eine One-Way-Synchronisation einrichten zu können?
Das Ziel ist es, AD-User einer bestimmten Gruppe (nicht OU) read-only zu UCS zu übertragen. Leider habe ich keinen Admin-Zugang zur AD sondern nur einen gewöhnlichen Bind-User. Die direkte Anfrage bei UCS hat keine Antwort gebracht und im Forum finde ich auch keine Lösung.
Michael Grandjean
Hallo Herr Aregger,
für den ordnungsgemäßen Betrieb des AD-Connecters benötigen Sie einen Benutzer im AD der Mitglied der Gruppe „Domain Admins“ ist. Für den Read-only-Modus (UCS als Mitglied einer Active Directory-Domäne) ist das notwendig um im AD ein Rechnerobjekt anlegen und den UCS Server in die AD Domäne aufnehmen zu können (vgl. https://docs.software-univention.de/handbuch-4.4.html#ad-connector:ad-member-einrichtung).
Für den Sync-Modus ist das darüber hinaus auch noch notwendig um die u.a. hier im Artikel beschrieben Passwort-Hashes auslesen zu dürfen (vgl. https://docs.software-univention.de/handbuch-4.4.html#windows:ad:connector).
Um jetzt nur bestimmte Objekte zu synchronisieren, kann mit den UCR-Variablen „connector/ad/mapping/*/ignorelist“ gearbeitet werden. Hier lässt sich definieren, was genau _nicht_ synchronisiert werden soll.
Freundliche Grüße,
Michael Grandjean
Urs Aregger
Hallo Herr Grandjean
Vielen Dank für Ihre Antwort. Aber dann stimmt die Beschreibung im Handbuch nicht. Dort steht unter 9.3.1
«Die beiden Varianten sind:
UCS als Teil (Domänen-Mitglied) einer AD-Domäne (siehe Abschnitt 9.3.2)
Synchronisation von Kontendaten zwischen einer AD-Domäne und einer UCS-Domäne (siehe Abschnitt 9.3.3)
[…]
Der zweite Modus, der sich über die App Active Directory-Verbindung konfigurieren lässt, dient dazu, die UCS Domäne parallel zu einer bestehenden AD-Domäne zu betreiben. In diesem Modus ist jedem Domänen-Benutzer sowohl in der UCS- als auch in der AD-Domäne ein gleichnamiges Benutzerkonto zugeordnet. Durch die Namensidentität und die Synchronisation der verschlüsselten Passwortdaten ermöglicht dieser Modus einen transparenten Zugriff zwischen beiden Domänen. Die Authentifikation eines Benutzers in der UCS-Domäne geschieht in diesem Modus direkt innerhalb der UCS-Domäne und ist damit nicht direkt abhängig von der AD-Domäne. Die Einrichtung diese Betriebsmodus ist im Detail in Abschnitt 9.3.3 beschrieben.»
Ich meine mich übrigens zu erinnern, dass ich im Handbuch auch gelesen habe, dass für die unidirektionale Synchronisation also read-Modus (AD -> UCS) keine Admin-Rechte vonnöten sind (vielleicht hat sich das ja geändert, was ich schade finde).
Es wäre schön, wenn wir unser Vorhaben mit Univention verwirklichen könnten. 😉
Mit freundlichen Grüssen
Urs Aregger
Michael Grandjean
Hallo Herr Aregger,
ich kann aus dem zitierten Abschnitt leider nicht herauslesen, wo die Beschreibung im Handbuch nicht stimmt. Dort steht ja auch:
„Über die Univention Configuration Registry-Variable connector/ad/ldap/binddn wird die LDAP-DN eines privilegierten Replikationsbenutzers konfiguriert. Dieser muss im AD Mitglied der Gruppe Domänen-Admins sein.“
Reden wir aneinander vorbei?
Gerne können wir die Unterhaltung im Forum weiterführen: https://help.univention.com/c/ucs/5
Erstellen Sie dort gerne ein neues Thema und taggen mich mit @grandjean.
Freundliche Grüße,
Michael Grandjean