RC4 vs AES: Kerberos-Falle bei Windows Server 2025 DCs
In diesem Blogpost möchte ich über ein interessantes Problem berichten, über das ich erst vor Kurzem gestolpert bin, als ich eine bestehende Active-Directory-Umgebung um einen Domain Controller mit Windows Server 2025 erweitern wollte. Dabei handelt es sich weniger um einen klassischen „How-To“-Artikel, wie man ihn von mir gewohnt ist, sondern eher um einen Erlebnisbericht. Ich denke aber trotzdem, dass man als Windows-Administrator seine eigenen Lehren daraus ziehen kann. Lange Rede, kurzer Sinn, legen wir los.
Die Symptome: Anmeldeprobleme nach der DC-Einführung
Der Prozess ist eigentlich relativ straightforward: Man installiert einen neuen Domain Controller auf einem Windows Server 2025 und nimmt ihn als neuen Authentifizierungsserver ins Load Balancing auf. Kurz darauf berichteten jedoch Nutzer, dass der Logon auf Workstations und bei Services innerhalb der Domäne nicht mehr korrekt funktionierte.
Das Interessante daran: Nur einige Nutzer waren betroffen – und selbst bei ihnen trat das Problem nicht durchgängig auf. Bei anderen Nutzern und auch bei eigenen Tests konnte ich die Symptomatik nicht nachvollziehen. Sobald ich den neuen Domain Controller heruntergefahren hatte und somit wieder nur die Windows Server 2019 DCs Authentifizierungsanfragen entgegennahmen, legte sich das Problem sofort.
Die Symptome im Überblick:
- Sobald der neue Windows Server 2025 DC Anfragen entgegennahm, kam es bei einigen Nutzern zu Anmeldeproblemen
- Viele andere Nutzer konnten hingegen problemlos weiterarbeiten und hatten keinerlei Beschwerden
- Das Herunterfahren des neuen DCs behob die Probleme umgehend
Das Spiel konnte man immer wieder wiederholen, das Resultat war jedoch immer das gleiche. Sogar eine komplette Neuinstallation inklusive vorherigem Cleanup der Metadaten brachte keine Besserung. Wir müssen daher tiefer ins Debugging einsteigen.
Die Analyse
Ein Hoch auf das Logging
Zu diesem Zeitpunkt waren bereits einige Stunden vergangen, und ich entschloss mich, tiefergehend mit den Active Directory Security Logs auseinanderzusetzen. Dabei zeigte sich ein interessantes Fehlerbild: Sobald ein Client versuchte, ein Kerberos-Ticket anzufordern, wurde die Anfrage vom W2k25 Domain Controller mit dem Event 4771 quittiert. Das bedeutet so viel wie „Kerberos pre-authentication failed“ und tritt immer dann auf, wenn ein Dienst ein Kerberos-Ticket anfragt, die Anfrage aber vom KDC abgelehnt wird.
Der jeweilige Fehler wird dabei im Feld „Failure Code“ ausgegeben. Gibt der Nutzer beispielsweise sein Kennwort falsch ein, wird der Fehlercode 0x18 geloggt. In meinem Fall sahen die Events wie folgt aus:
Der interessante Teil ist dabei, wie bereits vorhin angesprochen, der „Failure Code“ – und in diesem Beispiel steht dort 0xE, was so viel bedeutet wie „KDC has no support for encryption type„. Um das tatsächliche Problem verständlicher zu machen, müssen wir noch einen kurzen Exkurs in die Welt der Kerberos-Verschlüsselung einlegen.
Kerberos und seine Verschlüsselung
Kerberos unter Windows hat eine lange Historie und geht bis in die frühen 2000er-Jahre zurück. Somit hat das Protokoll bereits einen langen Weg hinter sich und wurde auch einigen Verbesserungen unterzogen. Doch zurück zum eigentlichen Thema.
Setzt ein Nutzer das Kennwort seines Active-Directory-Benutzerkontos, wird es natürlich niemals im Klartext in der NTDS.dit (das ist die AD-Datenbank) gespeichert, sondern immer in gehashter oder verschlüsselter Form.
Dabei gibt es folgende Mechanismen:
- RC4-Schlüssel (entspricht auch dem NT-Hash)
- Eine MD4-Iteration
- Kein Salt
- AES128/AES256-Schlüssel
- 4096 HMAC-SHA1-Iterationen
- Salted mit Nutzernamen und Domäne
RC4 bildet dabei das Urgestein und ist relativ von Beginn an dabei. AES-Verschlüsselung ist erst später dazugekommen und wird heutzutage als Standard angesehen, wohingegen RC4 als veraltet und unsicher gilt. Außerdem ist RC4 auch anfällig für Kerberoasting – wer sich dafür interessiert, kann sich meinen Blogpost zum Thema Kerberoasting näher ansehen.
Moderne Systeme versuchen dabei, immer AES zu verwenden. Allerdings gibt es meistens einen RC4-Fallback, falls der Service kein AES unterstützt oder der Nutzer keinen AES-abgeleiteten Schlüssel besitzt. Und hier kommen wir zur Ursache.
Die Ursache
Uneinigkeit bei der Verschlüsselungsmethode
Die AD-Benutzer dieser Domäne wurden vor einigen Jahren via ADMT aus einer vertrauenswürdigen Domäne migriert. Bei dieser Migration wurde zwar durch das ADMT-Tooling ein RC4-Schlüssel für das Kennwort des jeweiligen Nutzers gesetzt, allerdings kein AES-Derivat.
Windows Server 2025 unterstützt standardmäßig allerdings kein RC4 mehr (siehe What’s new in Windows Server 2025) und benötigt unbedingt AES-Schlüssel. Somit stehen wir bei der Authentifizierung vor folgendem Problem:
- Der Nutzer fragt ein Kerberos-Ticket beim KDC an
- Der KDC antwortet und teilt die verfügbaren Verschlüsselungstypen mit
- Das Kennwort des Nutzers wurde allerdings nur mit RC4 abgelegt (somit existiert einfach kein AES-Schlüssel)
- Client und KDC können sich nicht auf einen Verschlüsselungstyp einigen, die Authentifizierung schlägt fehl und das Event 4771 wird protokolliert
AccountAvailableKeys verrät die Wahrheit
Wir haben nun eine Theorie aufgestellt und müssen sie jetzt im besten Fall nur noch bestätigen. Schauen wir uns dazu das Kerberos-Event eines Domain Controllers an, bei dem die Authentifizierung für denselben Nutzer erfolgreich war:
Auch wenn der Eintrag auf den ersten Blick etwas erdrückend erscheint, der für uns relevante Teil ist dabei nur der Wert „AccountAvailableKeys“. Dieser Wert spiegelt alle für den jeweiligen Nutzer gespeicherten und verfügbaren Schlüssel wider. Und hier sieht man eindeutig, dass der Account nur RC4 bereitstellt. Somit haben wir die Ursache unseres Problems gefunden!
Das erklärt auch, warum das Problem nur bei einigen Nutzern aufgetreten ist und ich es mit meinen Test-Accounts nicht nachvollziehen konnte. Nutzer, die mittels ADMT migriert wurden und ihr Kennwort seit der Migration nicht änderten, besitzen nur einen RC4-Schlüssel. Meine Test-Accounts wurden allerdings neu erstellt und haben daher sowohl einen RC4- als auch einen AES-Schlüssel.
Und jetzt?
Tatsächlich gibt es für das Problem im Grunde nur zwei mögliche Lösungen:
- Nutzer setzen ihr Kennwort erneut oder ändern es im besten Fall auf ein starkes Passwort (falls das nicht bereits der Fall ist). Dabei wird der oben genannte Prozess ausgelöst, wodurch sowohl ein RC4- als auch ein AES-Schlüssel generiert werden.
- Man verzichtet auf einen Windows Server 2025 Domain Controller und installiert stattdessen Windows Server 2022.
Grundsätzlich kommt man um das Neusetzen des Kennworts auf lange Sicht nicht herum. RC4 gilt als veraltet, und als Administrator hat man die Verantwortung, die Umgebung so sicher wie möglich zu gestalten. Daher zum Abschluss mein Appell: Auch wenn es umständlich erscheint, in Sachen Sicherheit sollte man keine Abstriche machen. Denn es gilt nach wie vor der Leitsatz „Security darf wehtun“.
Und mit diesen Worten verabschiede ich mich für diesen Post und hoffe, dass du vielleicht auch noch das ein oder andere lernen konntest.
