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 deckt auch nicht den Pfad von Silver Ticket ab. 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.

Kerberos RC4 Fallback Active Directory: was es 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 ein evidence-first AD-Sicherheitsaudit als auch in einen prioritätenorientierten AD-Härtungsplan.

Warum RC4 in modernen AD-Umgebungen weiterhin auftaucht

Der häufigste Fehler besteht darin anzunehmen, dass RC4 in einem Ticket immer auf genau ein fehlerhaftes GPO hindeutet. Die aktuelle Microsoft-Dokumentation zeigt mehrere unterschiedliche Root Causes, und sie lassen sich nicht alle auf die gleiche Weise beheben.

Hier sind zwei Microsoft-Punkte entscheidend.

Erstens haben die Kerberos-Änderungen vom 8. November 2022 RC4 nicht überall entfernt. Microsoft Support sagt, dass diese Updates AES als Standardverschlüsselungstyp für Sitzungsschlüssel bei Konten gesetzt haben, die nicht bereits mit einem Standardverschlüsselungstyp markiert waren, während Microsoft Learn sagt, dass RC4 weiterhin bei Konten auftaucht, die AES-SHA1 nicht unterstützen.

Zweitens verhalten sich Computerkonten und Benutzer- oder Dienstkonten nicht gleich. Microsoft Support sagt, dass Windows-Computer msDS-SupportedEncryptionTypes für ihre Maschinenkonten automatisch auf Basis der lokalen Kerberos-Richtlinie setzen, während Benutzerkonten, group Managed Service Accounts und andere AD-Konten diesen Wert nicht automatisch erhalten. Dieser Unterschied ist einer der Hauptgründe dafür, dass Dienstkonten in RC4-Untersuchungen immer wieder auftauchen.

Wie Sie Kerberos RC4 Fallback erkennen

In den meisten Umgebungen beginnt die Erkennung auf Domänencontrollern und nicht auf dem Service Host, der das Ticket am Ende erhält. Microsoft Learn sagt, dass Details zur Kerberos-RC4-Nutzung in Security Logs auf KDCs unter Windows Server 2019 und neuer aufgezeichnet werden und dass Windows Server 2016 diese Sichtbarkeit nach dem kumulativen Update vom Januar 2025 ebenfalls erhalten hat.

Beginnen Sie mit diesen Datenquellen:

Wenn Sie DC-Telemetrie bereits zentralisieren, gehört das neben die Kerberos-Events aus AD Sicherheitsüberwachung: Event IDs und SIEM und nicht in einen separaten Ad-hoc-Report.

Was Event ID 4769 tatsächlich aussagt

Event ID 4769 ist der praktischste Ort, um Kerberos RC4 Fallback nachzuweisen, weil Microsoft sowohl den Ticket-Verschlüsselungswert als auch die umgebenden Kontextfelder dokumentiert.

Zwei Details sind sofort wichtig:

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

Das macht 4769 zu einem der saubersten Nachweise dafür, dass RC4 noch ausgestellt wird.

Hinweis: Verwechseln Sie Ticket Encryption Type = 0x17 in Event ID 4769 nicht mit msDS-SupportedEncryptionTypes = 0x18 oder DefaultDomainSupportedEncTypes = 0x18. In Event 4769 sind 0x17 und 0x18 Ticketwerte aus der RC4-Familie. Im AD- und KDC-Bitmask-Kontext bedeutet 0x18 ausschließlich AES128 plus AES256.

Diese Unterscheidung ist wichtig, weil sich leicht die falsche Remediation ableiten lässt, wenn Ereigniswerte und AD-Bitmasks vermischt werden.

Wenn Sie 4769 untersuchen, sollten Sie es mit dem umgebenden Kontokontext verbinden:

• Wenn Ticket Encryption Type zur RC4-Familie gehört und das Dienstkonto keine AES-Schlüssel hat, ist die Kennworthistorie oft die eigentliche Ursache.
• Wenn der Client oder das Ziel kein AES ankündigt, ist meist Richtlinien- oder Plattformkompatibilität beteiligt.
• Wenn die Eventfelder darauf hindeuten, dass ein Konto nur 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änenstandard zurückfällt.

Häufige Root Causes hinter der Ausstellung von RC4-Tickets

Alte Konten ohne regenerierte AES-Schlüssel

Microsoft Learn sagt, dass ein Benutzerkonto, das vor der Einführung von AES-SHA1-Unterstützung in Windows Kerberos erstellt wurde und dessen Kennwort danach nie zurückgesetzt wurde, AES-SHA1-Schlüssel fehlen können. Microsoft knüpft das an die historische Einführung von AES-Unterstützung in Windows Server 2003 und sagt ausdrücklich, dass eine Kennwortänderung des Kontos die fehlenden Schlüssel erzeugt.

Deshalb ist RC4-Bereinigung teilweise ein Problem des Kennwort-Lebenszyklus und nicht nur der Protokollrichtlinie. Es erklärt auch, warum sich das Thema häufig mit den Problemen der Dienstkonto-Hygiene aus Active Directory Password Security: Misconfigurations That Matter überschneidet.

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

Microsoft Support sagt, dass Domänencontroller einen Standardwert von 0x27 annehmen oder den Registry-Wert DefaultDomainSupportedEncTypes verwenden, wenn für ein Konto kein msDS-SupportedEncryptionTypes gesetzt ist oder dieser Wert 0 ist. Microsoft Learn sagt außerdem, dass der KDC den Domänenstandard verwendet, wenn Quell- oder Zielmaschine keinen definierten Wert haben.

Das bedeutet, dass RC4 weiterhin auftreten kann, ohne dass ein Administrator je ausdrücklich ein RC4-Kästchen auf dem Konto gesetzt hat.

Verwenden Sie die Microsoft-eigenen 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 aus Microsoft Support und dient gezielt dazu, Konten zu finden, bei denen DES oder RC4 ausdrücklich aktiviert sind, AES aber nicht.

Für die Prü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

Die Microsoft-Dokumentation zur Kerberos-Richtlinie warnt weiterhin davor, dass die Einstellung Network security: Configure encryption types allowed for Kerberos die Kompatibilität mit Clientcomputern, Diensten und Anwendungen beeinflussen kann. Dieselbe Microsoft-Learn-Guidance sagt, dass Windows Server 2003 die letzte Windows-Plattform ohne AES-SHA1-Unterstützung war und empfiehlt die Migration von Geräten, die noch auf altes Verhalten angewiesen sind.

Hier wird RC4 Fallback zu einem Engineering-Thema und nicht zu einer Checkbox. Wenn Sie RC4 deaktivieren, bevor Sie verstanden haben, welche Clients und Dienste es noch brauchen, tauschen Sie ein Sicherheitsproblem gegen einen Authentifizierungsausfall ein.

Linux-integrierte Randfä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 sagt, dass das Erzwingen von msDS-SupportedEncryptionTypes auf 24 (0x18) oder das Umschalten des Kerberos-Verschlüsselungstyp-GPO das Problem nicht löst.

Der dokumentierte Grund ist enger als „Linux verursacht RC4“. Microsoft sagt, dass das Problem entsteht, weil das Attribut operatingSystemVersion so interpretiert wird, dass der KDC das Konto behandelt, als seien unterstützte Verschlüsselungstypen nicht befüllt, und deshalb stattdessen angenommene unterstützte Verschlüsselungstypen verwendet.

Das ist ein nützlicher Randfall, weil er zeigt, dass einige RC4-Befunde durch die Semantik von Verzeichnis-Metadaten entstehen und nicht nur durch offensichtliche Richtliniendrift.

Wie Sie RC4-Abhängigkeiten sicher beseitigen

Die sicherste Reihenfolge für Remediation ist schrittweise.

Actionable next steps

Bestätigen Sie zunächst die RC4-Ausstellung, gruppieren Sie betroffene Konten und behandeln Sie diese Bereinigung im selben Fluss wie einen prioritätenorientierten AD-Härtungsplan, bevor Sie global härten.

1. Nachweisen, wo RC4 ausgestellt wird, bevor Standardwerte geändert werden

Beginnen Sie nicht damit, RC4 domänenweit zu deaktivieren. Beginnen Sie damit, nachzuweisen, wo RC4 in 4769 noch ausgestellt wird und welchem Konto oder Dienst jedes Event zugeordnet ist. Wenn Sie Domänencontroller mit den Windows-Updates vom 13. Januar 2026 oder später aktualisiert haben, überwachen Sie zusätzlich die Kdcsvc-Audit-Events, die für den RC4-Service-Ticket-Härtungspfad eingeführt wurden.

2. Fehlende AES-Schlüssel dort regenerieren, wo das die echte Ursache ist

Wenn einem alten Benutzer- oder Dienstkonto AES-Schlüssel fehlen, sagt Microsoft, dass eine Kennwortänderung diese erzeugt. Das sollte passieren, bevor breitere KDC-seitige Änderungen eingeführt werden. Bei Dienstkonten mit SPN ist dies auch der Punkt, an dem sich das Risiko mit Kerberoasting überschneidet: RC4-gestützte Tickets lassen sich leichter in Offline-Cracking überführen, wenn zugleich schwache oder wiederverwendete Kennwörter vorhanden sind.

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

Prüfen Sie das rohe Attribut msDS-SupportedEncryptionTypes und vergleichen Sie es anschließend mit dem, was das Event zeigt. Wenn das Attribut leer ist oder 0 enthält, verwendet der KDC möglicherweise stattdessen DefaultDomainSupportedEncTypes. Wenn ein Maschinenkonto den Wert automatisch aus der lokalen Richtlinie setzt, korrigieren Sie die Geräterichtlinie. Wenn ein Benutzer- oder Dienstkonto einen expliziten Wert braucht, ändern Sie dieses Konto gezielt, statt zuerst den Domänenstandard insgesamt zu ändern.

4. Legacy-Abhängigkeiten entfernen, bevor die Kerberos-Richtlinie verschärft wird

Wenn Client, Dienst, Appliance oder nicht-Windows-Stack AES nicht tatsächlich unterstützen, lautet die Microsoft-eigene Guidance, nach Möglichkeit zu migrieren oder zu ersetzen. Deshalb warnt die Kerberos-GPO-Dokumentation weiterhin vor Kompatibilitätsauswirkungen. RC4-Bereinigung muss zuerst Legacy-Abhängigkeiten entfernen und darf nicht so tun, als gäbe es sie nicht.

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

Microsoft dokumentiert, dass Protected Users seine Mitglieder für Kerberos auf AES beschränkt, die Erzeugung von DES- oder RC4-Schlüsseln stoppt und DES oder RC4 in der Kerberos-Preauthentication verhindert. Das macht die Gruppe für ausgewählte menschliche Konten nützlich, die bereits sauber auf AES arbeiten können.

Es ist kein universeller Hebel für RC4-Remediation. Microsoft warnt ausdrücklich davor, Dienst- oder Computerkonten zu Protected Users hinzuzufügen. Mit anderen Worten: Protected Users ist ein gezielter Control für passende Benutzerkonten und kein Ersatz für die Korrektur von Dienstkonten, Geräten oder KDC-Konfiguration.

6. Sich mit expliziten Daten auf die RC4-Standardänderungen 2026 vorbereiten

Die Microsoft-Guidance zu RC4-Service-Tickets ergänzt eine zweite Timeline, die operativ wichtig ist:

• January 13, 2026: Die erste Bereitstellungsphase beginnt und fügt Audit-Events für riskantes Standard-RC4-Verhalten hinzu.
• April 14, 2026: Die Enforcement-Phase setzt den Standardwert DefaultDomainSupportedEncTypes für KDC-Operationen auf 0x18, also nur AES-SHA1, für Konten ohne expliziten msDS-SupportedEncryptionTypes-Wert.
• July 2026: Microsoft sagt, dass der temporäre Rollback-Control für dieses Verhalten entfernt wird und Enforcement zum dauerhaften Modus wird.

Das ist die aktuelle Microsoft-Timeline. Wenn Sie nach dem 14. April 2026 weiterhin RC4 benötigen, sagt Microsoft, dass es explizit im msDS-SupportedEncryptionTypes-Bitmask des Dienstkontos aktiviert werden muss, statt auf das alte Standardverhalten zu vertrauen.

Validierung nach dem Umstieg auf AES

Sie sind fertig, wenn sich die Evidenz ändert, nicht wenn das GPO sauberer aussieht.

Validieren Sie die Änderung in dieser Reihenfolge:

1. Bestätigen Sie, dass neue Event-ID-4769-Einträge für die bereinigten Dienste keine Ticketwerte aus der RC4-Familie mehr zeigen.
2. Bestätigen Sie, dass stattdessen erwartete Werte aus der AES-Familie erscheinen, typischerweise 0x11 oder 0x12.
3. Bestätigen Sie, dass das Konto jetzt AES-Schlüssel hat, wenn eine Kennwortrücksetzung die beabsichtigte Korrektur war.
4. Bestätigen Sie, dass die Dienstauthentifizierung nach Kennwortrücksetzung, Dienstart oder Kontoeinstellungsänderung weiterhin funktioniert.
5. Bestätigen Sie auf Domänencontrollern, die für den 2026-Härtungspfad aktualisiert wurden, dass keine relevanten Kdcsvc-201-209-Warnungen oder -Fehler für die bereinigten Pfade mehr auftreten.
6. Testen Sie nicht-Windows-Interoperabilität ausdrücklich. Microsoft sagt, dass das Fehlen von Audit-Events nicht garantiert, dass jedes nicht-Windows-Gerät nach dem Enforcement-Update vom 14. April 2026 weiter funktioniert.

Wenn Sie das nicht als einmalige Bereinigung, sondern fortlaufend verfolgen wollen, nehmen Sie es in einen wiederkehrenden Audit-Workflow auf und halten Sie es in derselben Kontrollfamilie wie die häufigsten Sicherheitsfehlkonfigurationen in Active Directory, die Identitätsdrift treiben.

Wie EtcSec Kerberos RC4 Fallback erkennt

EtcSec erkennt Kerberos RC4 Fallback, indem es die Evidenz korreliert, die Microsoft inzwischen operativ sichtbar macht:

• Ausstellung von Kerberos-Service-Tickets aus der RC4-Familie
• Konten, die weiterhin von standardmäßigen oder expliziten RC4-fähigen Verschlüsselungseinstellungen abhängen
• Principals, denen nach Kontenalter- oder Kennworthistorien-Drift nutzbare AES-Schlüssel fehlen
• Dienstkontopfad-Ketten, in denen RC4 Fallback und Crackable-Ticket-Exponierung zusammenfallen

Dadurch können Teams nach Kennwortrücksetzungen, Kontoeinstellungsänderungen, Legacy-Service-Bereinigung und KDC-Härtung erneut messen, statt RC4 als einmaliges Prüfthema 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
• 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