In vielen AD-Umgebungen, die ich betreue, steht das Abschalten von RC4 in Kerberos schon seit Jahren auf der To-do-Liste. Ernsthaft angepackt wird es meist erst, wenn der Druck wächst, und genau das passiert jetzt: Microsoft hat angekündigt, RC4 ab 2026 auf Domain Controllern standardmäßig zu deaktivieren. Wer noch Altlasten betreibt, muss sie vorher aufspüren und beseitigen, sonst schlägt die Authentifizierung eines Tages ohne Vorwarnung fehl. Für Überraschungen sorgen dabei immer wieder Servicekonten, alte Appliances und externe Systeme.

RC4 hat im Kerberos-Protokoll endgültig ausgedient

RC4 gilt seit Langem als schwach und blieb in Kerberos jahrelang nur aus Kompatibilitätsgründen erhalten. In Angriffsanalysen (z. B. Pass-the-Ticket, Kerberoasting) tauchen RC4-Tickets regelmäßig als Einfallstor auf. Der Grund liegt darin, dass der Schlüssel direkt aus dem Passwort abgeleitet wird und sich entsprechend leicht angreifen lässt; nachlesen kann man das etwa im Kerberos-Überblick von Microsoft. AES verschlüsselt Tickets deutlich sicherer, ist aber längst nicht überall Standard. Dass RC4 jetzt abgeschaltet wird, steht fest. Klären muss man nur noch, ob und wo es Abhängigkeiten gibt.

Eventlogs und Defender for Identity decken die verbleibende RC4-Nutzung auf

Die Suche nach RC4 ist ein ehrlicher Realitätscheck für die eigene Umgebung, und fast immer kommt dabei etwas Unerwartetes ans Licht. Ausgangspunkt ist das Security-Eventlog der Domain Controller. Die Events 4768 (TGT-Issuance) und 4769 (Service Ticket) enthalten das Feld „Ticket Encryption Type“, und der Wert 0x17 steht dort für RC4. Für ein systematisches Vorgehen eignet sich ein Sammelskript, das diese Events laufend ausliest und auswertet. Am bequemsten geht das über einen Log-Analytics-Workspace, in den die DCs ohnehin schon schreiben (z. B. über Azure Monitor oder Sentinel). So sieht eine schnelle Auswertung direkt in Log Analytics aus:

SecurityEvent
| where EventID in (4768, 4769)
| extend EncryptionType = tostring(parse_xml(EventData).EventData.Data[5]['#text'])
| where EncryptionType == '0x17'
| summarize Count = count() by Account = tostring(parse_xml(EventData).EventData.Data[0]['#text'])

Voraussetzung: Log-Analytics-Workspace mit SecurityEvent-Daten aus den DCs, Leserechte auf den Workspace.

Aus diesen Daten geht hervor, welche Konten oder Systeme noch RC4-Tickets bekommen. In kleinen Umgebungen genügt es mitunter, die Eventlogs direkt auf dem DC zu durchsuchen (z. B. mit PowerShell und Get-WinEvent), nur skaliert das nicht. Wer Microsoft Defender for Identity einsetzt, kann außerdem auf das Weak Cipher Security Assessment zurückgreifen, das viele Schwachstellen gleich mit anzeigt. Dort stößt man oft auf Anwendungen oder Server, die weiterhin RC4 verlangen, typischerweise NAS-Systeme, Appliances oder ältere Linux-Server.

Servicekonten, Keytabs und msDS-SupportedEncryptionTypes bergen die typischen Stolperfallen

Heikel sind vor allem Servicekonten mit uralten Passwörtern und Konten, bei denen das Attribut msDS-SupportedEncryptionTypes fehlt oder nur RC4 zulässt. Schaltet der DC RC4 ab, können sich diese Konten nicht mehr anmelden. In mehreren Projekten habe ich erlebt, dass bei der Passwortrotation von Servicekonten (z. B. für SQL oder IIS) niemand daran gedacht hat, die unterstützten Verschlüsselungstypen richtig zu setzen oder den Keytab zu erneuern. Noch kritischer sind Storage-Systeme, Firewalls oder Appliances mit fest hinterlegtem Keytab. Hier bleibt oft nur, beim Hersteller nach aktuellem Kerberos-Support zu fragen und anschließend einen neuen Keytab mit AES-Unterstützung einzuspielen.

Praxis-Tipp: Servicekonten mit sehr alten Passwörtern unbedingt ausfindig machen und deren Passwort gezielt neu setzen – erst danach erzeugt AD die AES-Schlüssel. Keytabs für Nicht-Windows-Systeme grundsätzlich mit aktuellen Verschlüsselungstypen erstellen.

Solche Konten findet man mit einem einfachen PowerShell-Filter (Active-Directory-Modul, z. B. auf einem Management-Server mit RSAT):

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { !$_.msDS-SupportedEncryptionTypes -or $_.msDS-SupportedEncryptionTypes -band 4 }

Der Befehl gibt alle Konten aus, bei denen gar keine Verschlüsselung oder nur RC4 hinterlegt ist. Für Computerkonten lässt sich der Filter entsprechend anpassen.

Eine Pilot-OU mit eigener GPO zeigt, was ohne RC4 noch funktioniert

Bevor RC4 flächendeckend verschwindet, steht die eigentliche Bewährungsprobe an, denn erst dann zeigt sich, ob es sich wirklich überall gefahrlos abschalten lässt. Ich empfehle, eine Pilot-OU mit Testsystemen und Servicekonten aufzubauen und auf den zugehörigen DCs RC4 gezielt per GPO zu deaktivieren. Welche Anwendungen oder Dienste dann ausfallen, merkt man sehr schnell, und man kann an den richtigen Stellen nachbessern. Wer auf Nummer sicher gehen will, spielt die geplante Konfiguration in einer Testumgebung durch und hält alle Auswirkungen schriftlich fest. Neue Systeme sollten ohnehin von Anfang an ohne RC4 auskommen.

Das folgende Diagramm zeigt den Ablauf der RC4-Abschaltung in vereinfachter Form:

flowchart TD
    Suche["RC4-Nutzung finden"] --> Konten["Servicekonten prüfen und Passwort reset"]
    Suche --> Geräte["Keytabs auf Geräten prüfen"]
    Konten --> Pilot["Pilot-OU RC4 deaktivieren"]
    Geräte --> Pilot
    Pilot --> Test["Funktionstests durchführen"]
    Test --> Rollout["RC4 auf allen DCs abschalten"]

Abbildung: Typischer Ablauf für das sichere Abschalten von RC4 in Kerberos.

Der Zeitplan für 2026 spricht dafür, jetzt aufzuräumen

Nach der aktuellen Ankündigung will Microsoft RC4 im Jahr 2026 abschalten. Wie das im eigenen Windows-Releasezyklus konkret aussieht, verrät die Seite „Windows Release Health“, die man deshalb regelmäßig im Blick behalten sollte. Ich rate dazu, das Thema jetzt mit hoher Priorität anzugehen und nicht abzuwarten. In den letzten Monaten haben immer mehr Umgebungen RC4 bereits vollständig deaktiviert. Wer jetzt aufräumt, erhöht die Sicherheit und wird gleichzeitig Altlasten bei Servicekonten, Kennwortprozessen und der Pflege von Appliances los. Meine Erfahrung: Je früher man anfängt, desto entspannter ist man, wenn Microsoft ernst macht.