Kerberos RC4 Fallback Active Directory: Wie Sie es erkennen, warum es weiter auftritt und wie Sie es entfernen

Der Begriff kerberos rc4 fallback active directory beschreibt den Zustand, in dem ein Domänencontroller weiterhin Kerberos-Material mit RC4 ausstellt, weil Client, Dienst, Kontoschlüssel oder die effektive Konfiguration der Verschlüsselungstypen es nicht zulassen, dass der Austausch bei AES bleibt. Das ist auch 2026 noch relevant, weil RC4-gestützte Service Tickets die Offline-Cracking-Seite von Kerberoasting relevant halten, selbst in Domänen, die auf dem Papier bereits modern wirken.

Dieser Artikel ist kein zweiter Kerberoasting-Leitfaden. Er ist ein Leitfaden für Erkennung und Remediation, mit dem Sie nachweisen, wo RC4 noch verwendet wird, warum der KDC es weiterhin auswählt und wie sich diese Abhängigkeit beseitigen lässt, ohne die Authentifizierung zu brechen.

Was Kerberos-RC4-Fallback in Active Directory bedeutet

In der Praxis ist Kerberos RC4 Fallback keine einzelne Einstellung. Es ist das Ergebnis davon, dass der KDC RC4 für ein Ticket oder einen Sitzungsschlüssel auswählt, weil AES nicht verfügbar ist, nicht angekündigt wird, für das Konto noch nicht erzeugt wurde oder durch die effektive Konfiguration ausgeschlossen ist.

Microsoft formuliert das inzwischen klar. In der aktuellen Kerberos-Guidance sagt Microsoft, dass RC4 auslaufen soll, dass Windows-Updates vom 8. November 2022 oder später das Standardverhalten von Kerberos so geändert haben, dass AES-SHA1 für Konten bevorzugt wird, bei denen kein Verschlüsselungstyp ausdrücklich gesetzt wurde, und dass RC4 für Konten, die AES-SHA1 nicht unterstützen, weiterhin verwendet wird. Deshalb gehört dieses Thema sowohl in eine auditorientierte AD-Sicherheitsprüfung als auch in einen härtungsorientierten AD-Bereinigungsplan.

Warum RC4 in modernen AD-Umgebungen weiterhin auftaucht

Der häufigste Fehler besteht darin, anzunehmen, dass RC4 in einem Ticket immer auf eine einzelne fehlerhafte GPO zurückzuführen ist. Microsofts aktuelle Dokumentation nennt mehrere unterschiedliche Grundursachen, und diese lassen sich nicht alle auf dieselbe Weise beheben.

Zwei Punkte aus der Microsoft-Dokumentation sind hier wichtig.

Erstens haben die Kerberos-Änderungen vom 8. November 2022 RC4 nicht überall entfernt. Microsoft Support gibt an, dass diese Updates AES als Standard-Verschlüsselungstyp für Sitzungsschlüssel bei Konten festgelegt haben, die noch nicht mit einem Standard-Verschlüsselungstyp markiert waren, während Microsoft Learn angibt, dass RC4 weiterhin bei Konten auftritt, die AES-SHA1 nicht unterstützen.

Zweitens verhalten sich Computerkonten und Benutzer- beziehungsweise Dienstkonten nicht gleich. Microsoft Support gibt an, dass Windows-Computer msDS-SupportedEncryptionTypes für ihre Computerkonten automatisch anhand der lokalen Kerberos-Richtlinie setzen, dieser Wert bei Benutzerkonten, group Managed Service Accounts und anderen AD-Konten jedoch nicht automatisch gesetzt wird. Dieser Unterschied ist einer der Hauptgründe, warum Dienstkonten in RC4-Untersuchungen immer wieder auftauchen.

Wie Sie Kerberos-RC4-Fallback erkennen

In den meisten Umgebungen beginnt die Erkennung auf den Domänencontrollern, nicht auf dem Dienst-Host, der das Ticket am Ende empfängt. Microsoft Learn gibt an, dass Details zur Kerberos-RC4-Nutzung bei Windows Server 2019 und höher in den Security-Protokollen der KDCs erfasst werden und dass Windows Server 2016 nach dem kumulativen Update vom Januar 2025 ebenfalls Sichtbarkeit der RC4-Nutzung in diesen Ereignissen erhalten hat.

Beginnen Sie mit diesen Datenquellen:

Wenn Sie DC-Telemetrie bereits zentral erfassen, gehört dies neben die Kerberos-Ereignisse aus Active Directory Monitoring: Die wichtigsten Security Event IDs, nicht in einen separaten Ad-hoc-Bericht.

Was Event ID 4769 wirklich aussagt

Event ID 4769 ist die praktischste Stelle, um Kerberos-RC4-Fallback nachzuweisen, da Microsoft sowohl den Wert für die Ticketverschlüsselung als auch die umgebenden Kontextfelder dokumentiert.

Zwei Details sind sofort relevant:

1. Microsoft dokumentiert Ticket Encryption Type = 0x17 als RC4-HMAC und 0x18 als RC4-HMAC-EXP.
2. Microsoft gibt außerdem an, dass ab Windows Vista und Windows Server 2008 die erwarteten Verschlüsselungswerte für Service Tickets 0x11 und 0x12 sind, beides Algorithmen aus der AES-Familie.

Das macht 4769 zu einer der saubersten Möglichkeiten nachzuweisen, dass RC4 weiterhin ausgestellt wird.

Diese Unterscheidung ist wichtig, weil es leicht passiert, die falsche Remediation zu planen, wenn Sie Ereigniswerte mit AD-Bitmask-Werten vermischen.

Wenn Sie 4769 untersuchen, betrachten Sie es zusammen mit dem umgebenden Kontokontext:

• Wenn Ticket Encryption Type aus der RC4-Familie stammt und das Dienstkonto keine AES-Schlüssel hat, ist oft die Passworthistorie das eigentliche Problem.
• Wenn der Client oder das Ziel kein AES ankündigt, spielt in der Regel Richtlinien- oder Plattformkompatibilität eine Rolle.
• Wenn die Ereignisfelder darauf hindeuten, dass ein Konto nur das Standardverhalten unterstützt, prüfen Sie, ob das Konto tatsächlich einen rohen msDS-SupportedEncryptionTypes-Wert in AD hat oder ob der KDC auf den Domänen-Standardwert zurückfällt.

Häufige Grundursachen für die Ausstellung von RC4-Tickets

Alte Konten ohne neu erzeugte AES-Schlüssel

Microsoft Learn gibt an, dass einem Benutzerkonto AES-SHA1-Schlüssel fehlen können, wenn es erstellt wurde, bevor die AES-SHA1-Unterstützung zu Windows Kerberos hinzugefügt wurde, und das Passwort seitdem nie zurückgesetzt wurde, und dass eine Änderung des Kontopassworts diese fehlenden Schlüssel erzeugt.

Ein Vorbehalt zu den Datumsangaben, denn Microsofts eigene Seiten widersprechen sich hier. Die RC4-Remediation-Seite gibt an, dass die AES-SHA1-Unterstützung in Windows Kerberos „in Windows Server 2003 hinzugefügt wurde", bezeichnet auf derselben Seite jedoch Windows Server 2003 auch als die letzte Windows-Version, die AES-SHA1 nicht unterstützte. Die übrigen Microsoft-Referenzen stimmen mit der zweiten Lesart überein: Die Kerberos-Richtliniendokumentation führt AES128_HMAC_SHA1 und AES256_HMAC_SHA1 als „Nicht unterstützt unter Windows 2000 Server, Windows XP oder Windows Server 2003" auf, und die Dokumentation zu Event ID 4769 führt 0x11 und 0x12 als „Unterstützt ab Windows Server 2008 und Windows Vista" auf. Betrachten Sie Windows Vista und Windows Server 2008 als den Zeitpunkt, ab dem AES-SHA1 verfügbar wurde, und Windows Server 2003 als die letzte Windows-Plattform ohne diese Unterstützung.

Deshalb ist die RC4-Bereinigung teilweise ein Problem des Passwort-Lebenszyklus und nicht nur ein Problem der Protokollrichtlinie. Das erklärt auch, warum sich das Problem häufig mit den in Active Directory-Passwortsicherheit: Fehlkonfigurationen, die zählen beschriebenen Hygieneproblemen bei Dienstkonten überschneidet.

msDS-SupportedEncryptionTypes fehlt, ist unvollständig oder wird falsch gelesen

Microsoft Support gibt an, dass Domänencontroller einen Standardwert von 0x27 annehmen oder die Registrierungseinstellung DefaultDomainSupportedEncTypes verwenden, wenn ein Konto keinen gesetzten msDS-SupportedEncryptionTypes-Wert hat oder dieser auf 0 steht. Microsoft Learn gibt außerdem an, dass der KDC den Domänen-Standardwert verwendet, wenn für die Quell- oder Zielmaschine kein definierter Wert vorliegt.

Das bedeutet, dass RC4 auch dann noch auftreten kann, wenn nie ein Administrator explizit eine RC4-Option am Konto selbst aktiviert hat.

Verwenden Sie Microsofts eigene Befehle, um zu prüfen, was tatsächlich konfiguriert ist.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Diese Abfrage stammt von Microsoft Support und ist speziell dafür gedacht, Konten zu finden, bei denen DES oder RC4 explizit aktiviert ist, AES jedoch nicht.

Für die Überprüfung eines einzelnen Objekts zeigt Microsoft Learn dieses Muster:

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Legacy-Geräte und -Dienste, die AES weiterhin nicht unterstützen

Microsofts Kerberos-Richtliniendokumentation warnt weiterhin, dass die Einstellung Netzwerksicherheit: Konfigurieren der für Kerberos zulässigen Verschlüsselungstypen „die Kompatibilität mit Clientcomputern, Diensten oder Anwendungen beeinträchtigen kann". Getrennt davon — und das stammt aus Microsofts Leitfaden zu RC4-Erkennung und -Remediation, nicht von der Richtlinienseite — gibt Microsoft an, dass die letzte Windows-Version ohne AES-SHA1-Unterstützung Windows Server 2003 war, und rät dazu, auf eine Windows-Version zu migrieren, die AES-SHA1 unterstützt.

An diesem Punkt wird RC4-Fallback zu einem technischen Problem statt zu einer bloßen Checkbox. Wenn Sie RC4 deaktivieren, bevor Sie wissen, welche Clients und Dienste es noch benötigen, tauschen Sie ein Sicherheitsproblem gegen einen Authentifizierungsausfall ein.

Linux-integrierte Grenzfälle

Microsoft dokumentiert inzwischen ein spezifisches Linux-integriertes Szenario, in dem AD DS weiterhin RC4-verschlüsselte Tickets ausstellt. In diesem Fall zeigt Event ID 4769 Ticket Encryption Type: 0x17, und Microsoft gibt an, dass weder das erzwungene Setzen von msDS-SupportedEncryptionTypes auf 24 (0x18) noch das Umschalten der Kerberos-Verschlüsselungstyp-GPO das Problem löst.

Der dokumentierte Grund ist enger gefasst als „Linux verursacht RC4". Microsoft gibt an, dass das Problem auftritt, weil das Attribut operatingSystemVersion so interpretiert wird, dass der KDC das Konto so behandelt, als seien keine unterstützten Verschlüsselungstypen hinterlegt, wodurch der KDC stattdessen angenommene unterstützte Verschlüsselungstypen verwendet.

Microsofts dokumentierte Lösungen sind ebenso eng gefasst: das Attribut operatingSystemVersion entfernen, seinen Wert so setzen, dass das erste Zeichen keine Ziffer ist, oder zu einer Systemversion wechseln, die der Spezifikation entspricht.

Das ist ein Grenzfall, den man kennen sollte, denn er zeigt, dass manche RC4-Befunde durch die Semantik von Verzeichnismetadaten verursacht werden und nicht nur durch offensichtliche Richtlinienabweichungen.

Wie Sie RC4-Abhängigkeiten sicher beseitigen

Die sicherste Reihenfolge für die Remediation ist schrittweise.

1. Nachweisen, wo RC4 ausgestellt wird, bevor Sie Standardwerte ändern

Beginnen Sie nicht damit, RC4 domänenweit zu deaktivieren. Weisen Sie zunächst anhand von 4769 nach, wo RC4 noch ausgestellt wird und welchem Konto oder Dienst jedes Ereignis zuzuordnen ist. Überwachen Sie auf Domänencontrollern, die mit den Windows-Updates vom 13. Januar 2026 oder später aktualisiert wurden, zusätzlich die Kdcsvc-Audit-Ereignisse, die für den RC4-Service-Ticket-Hardening-Pfad eingeführt wurden.

2. Fehlende AES-Schlüssel dort neu erzeugen, wo das die eigentliche Ursache ist

Fehlen einem alten Benutzer- oder Dienstkonto AES-Schlüssel, gibt Microsoft an, dass eine Änderung des Kontopassworts diese erzeugt. Das sollte geschehen, bevor Sie umfassendere Änderungen auf KDC-Seite vornehmen. Bei Dienstkonten mit SPNs überschneidet sich das Risiko an dieser Stelle auch mit Kerberoasting: RC4-gestützte Tickets lassen sich leichter für Offline-Cracking nutzen, wenn zusätzlich schwache oder wiederverwendete Passwörter vorliegen.

3. Rohe AD-Konfiguration vom effektiven KDC-Verhalten trennen

Prüfen Sie das rohe Attribut msDS-SupportedEncryptionTypes und vergleichen Sie es mit dem, was das Ereignis zeigt. Ist das Attribut leer oder 0, verwendet der KDC möglicherweise stattdessen DefaultDomainSupportedEncTypes. Setzt ein Computerkonto den Wert automatisch anhand der lokalen Richtlinie, beheben Sie die Geräterichtlinie. Benötigt ein Benutzer- oder Dienstkonto einen expliziten Wert, ändern Sie gezielt dieses Konto, statt zuerst den gesamten Domänen-Standardwert zu ändern.

4. Legacy-Abhängigkeiten entfernen, bevor Sie die Kerberos-Richtlinie verschärfen

Unterstützt der Client, Dienst, das Gerät oder der Nicht-Windows-Stack AES tatsächlich nicht, lautet Microsofts eigene Empfehlung, ihn wo möglich zu migrieren oder zu ersetzen. Das ist auch der Grund, warum die Kerberos-GPO-Dokumentation immer wieder vor Kompatibilitätsauswirkungen warnt. Die RC4-Bereinigung sollte Legacy-Abhängigkeiten zuerst entfernen, statt so zu tun, als gäbe es sie nicht.

5. Protected Users nur dort einsetzen, wo es wirklich passt

Microsoft dokumentiert, dass Protected Users Mitglieder bei Kerberos auf AES beschränken, die Erzeugung von DES- oder RC4-Schlüsseln stoppen und DES oder RC4 bei der Kerberos-Vorabauthentifizierung verhindern. Das macht die Gruppe nützlich für ausgewählte menschliche Konten, die bereits sauber auf AES arbeiten können.

Sie ist kein universeller Hebel zur RC4-Remediation. Microsoft warnt ausdrücklich davor, jemals Konten für Dienste und Computer zu Protected Users hinzuzufügen. Anders gesagt: Protected Users ist eine gezielte Kontrolle für die richtigen Benutzerkonten, kein Ersatz dafür, die Konfiguration von Dienstkonten, Geräten oder dem KDC zu beheben — dasselbe Abgrenzungsproblem, das in Active Directory – privilegierte Konten: Protected Users, Delegation und Lücken bei Dienstkonten behandelt wird.

6. Die 2026er RC4-Standardänderungen berücksichtigen, die bereits ausgeliefert sind

Microsofts Leitfaden zu RC4-Service-Tickets enthält einen zweiten Zeitplan, der operativ relevant ist. Alle drei Phasen liegen inzwischen in der Vergangenheit — es handelt sich also nicht mehr um vorbereitende Arbeit, sondern um den Zustand, den Sie auf aktualisierten Domänencontrollern annehmen müssen:

• 13. Januar 2026: Die anfängliche Rollout-Phase wurde ausgeliefert, warnte vor der kommenden Durchsetzung und fügte Audit-Ereignisse für riskantes RC4-Standardverhalten hinzu.
• 14. April 2026: Die Durchsetzungsphase änderte den Standardwert von DefaultDomainSupportedEncTypes für KDC-Operationen auf 0x18, also ausschließlich AES-SHA1, bei Konten ohne expliziten msDS-SupportedEncryptionTypes-Wert. In dieser Phase ließ sich die Durchsetzung noch manuell zurückrollen.
• Juli 2026: Windows-Updates, die im Juli 2026 oder später veröffentlicht wurden, entfernten die Unterstützung für den Registrierungs-Subkey RC4DefaultDisablementPhase, sodass die manuelle Rollback-Kontrolle entfällt und die Durchsetzung der dauerhafte Modus ist.

Wenn Sie RC4 heute noch benötigen, gibt Microsoft an, es explizit im Attribut msDS-SupportedEncryptionTypes des Dienstkontos zu konfigurieren, statt sich auf das alte Standardverhalten zu verlassen, da der Domänen-Standardwert es nicht mehr bereitstellt.

Validierung nach dem Wechsel zu AES

Sie sind fertig, wenn sich die Nachweise ändern — nicht, wenn die GPO nur sauberer aussieht.

Validieren Sie die Änderung in dieser Reihenfolge:

1. Bestätigen Sie, dass neue Event-ID-4769-Einträge für die remediierten Dienste keine Ticketwerte aus der RC4-Familie mehr zeigen.
2. Bestätigen Sie, dass stattdessen die erwarteten Ticketwerte aus der AES-Familie erscheinen, typischerweise 0x11 oder 0x12.
3. Bestätigen Sie, dass das Konto jetzt AES-Schlüssel hat, wenn ein Passwort-Reset die vorgesehene Lösung war.
4. Bestätigen Sie, dass die Dienstauthentifizierung nach Passwort-Resets, Dienstneustarts oder Änderungen an Kontoeinstellungen weiterhin funktioniert.
5. Bestätigen Sie auf Domänencontrollern, die für den 2026er Hardening-Pfad aktualisiert wurden, dass für die remediierten Pfade keine relevanten Kdcsvc-201-209-Warnungen oder -Fehler mehr auftreten.
6. Testen Sie die Interoperabilität mit Nicht-Windows-Systemen explizit. Microsoft gibt an, dass das Fehlen von Audit-Ereignissen nicht garantiert, dass alle Nicht-Windows-Geräte nach dem Update vom April 2026 die Kerberos-Authentifizierung erfolgreich akzeptieren.

Wenn Sie das über die Zeit hinweg verfolgen möchten statt als einmalige Bereinigung, integrieren Sie es in einen wiederkehrenden Audit-Workflow und behandeln Sie es als Teil derselben Prüffamilie wie die umfassenderen Active-Directory-Sicherheitsfehlkonfigurationen, die Identity Drift verursachen.

Wie EtcSec Kerberos-RC4-Fallback erkennt

EtcSec erkennt Kerberos-RC4-Fallback, indem es die Nachweise korreliert, die Microsoft inzwischen operativ bereitstellt:

• Ausstellung von Tickets der RC4-Familie in der Telemetrie der Kerberos-Service-Tickets
• Konten, die weiterhin von standardmäßigen oder expliziten RC4-fähigen Verschlüsselungseinstellungen abhängen
• Principals, denen nach Kontoalter oder Passworthistorie-Drift nutzbare AES-Schlüssel fehlen
• Dienstkonto-Pfade, bei denen sich RC4-Fallback und knackbare Ticket-Exposition überschneiden

Das ermöglicht es Teams, nach Passwort-Resets, Änderungen an Kontoeinstellungen, der Bereinigung von Legacy-Diensten und KDC-Hardening erneut zu messen, statt RC4 als einmaligen Prüfpunkt zu behandeln.

Primäre Referenzen

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• CVE-2026-20833 in the NVD
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos