Passwort-Hashes zwischen MS Active Directory und UCS-Domäne abgleichen

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.