Die Uhr tickt für einen der langlebigsten (und unsichersten) Cipher in unseren Netzwerken. Microsoft macht ernst und forciert die Abschaltung der RC4-Verschlüsselung im Kerberos Protokoll. Wer jetzt nicht handelt, riskiert im April – spätestens aber im Juli – weitreichende Authentifizierungsprobleme in Active Directory.

Bei TEAL begleiten wir Kunden seit Jahren bei der Härtung ihrer Infrastruktur. Dabei ist das Abschalten von RC4 einer der „Klassiker“. Doch wer noch nicht gehandelt hat, muss sich jetzt beeilen! Dieses Mal wird die Timeline nicht von der internen IT, sondern direkt von Redmond diktiert.

Die drei Wege durch den April und Juli

Wenn die Änderungen an der Kerberos-Verschlüsselungslogik im April greifen, haben Unternehmen genau drei Möglichkeiten:

1. 1. Hoffen, dass man irgendwie bereit ist.
   2. Panisch den „Panic Button“ drücken und die Änderungen verzögern (auf eigene Gefahr).
   3. Wissen, dass man bereit ist, weil man seine Hausaufgaben gemacht hat.

Rate mal welchen Punkt wir bevorzugen 😉.

Was ändert sich konkret?

Bisher fielen Service Tickets oft auf RC4 zurück, wenn AES auf SPN-fähigen Konten nicht explizit aktiviert war. Nach dem April-Update ist der Standard AES. RC4 wird nur noch dann genutzt, wenn es manuell im Attribut msds-SupportedEncryptionTypes hinterlegt ist. Zusätzlich werden standardmäßig nur noch AES-Session-Keys unterstützt.

Man kann also RC4 auch nach dem April Update weiter nutzen, aber nur bis Juli! Dann wird Microsoft das ganze erzwingen. Spätestens bis dann müsst ihr gehandelt haben. Wenn nicht werdet ihr von den folgenden Problemen betroffen sein:

Das Problem: In historisch gewachsenen Umgebungen lauern Stolperfallen, die Kerberos-Logins scheitern lassen:

• • Veraltete Hardware/Systeme: Alles vor Windows 7 oder Server 2008.
  • Passwort-Altlasten: Konten, deren Passwörter seit 2008 nicht geändert wurden oder die via ADMT (nur NTLM-Hashes) migriert wurden.
  • Falsch konfigurierte Service Accounts können nicht mehr genutzt werden.
  • Dritthersteller-Lösungen: Appliances oder Legacy-Software, die kein AES beherrscht.

Die TEAL-Experten-Einschätzung: Der Teufel steckt im Detail

Unsere Erfahrung zeigt: Verlass dich nicht allein auf Gruppenrichtlinien (GPOs). Diese werden in diversen Szenarien ignoriert, besonders wenn Attribute an den Konten fehlen.

„Microsoft hat mit dem RegKey DefaultDomainSupportedEncTypes und dem im Januar eingeführten RC4DefaultDisablementPhase Werkzeuge geliefert, um die Abschaltung zu testen. Aber Vorsicht: Die Zeit bis Ende Juni ist wertvoll. Mit dem Juli-Update wird die RC4-Tür endgültig zugeschlagen – dann ist ein Rollback nicht mehr möglich.“ – so einer unserer TEAL-Experten

Dein Fahrplan zur RC4-Freiheit (Anleitung)

Damit du nicht von Fehlermeldungen überrollt wirst, empfehlen wir folgendes Vorgehen:

1. 1. Auditing aktivieren & Monitoring starten

Mit dem Januar-Update hat Microsoft 9 neue Event-IDs eingeführt. Diese sind dein Frühwarnsystem.

• • Fokus auf Events 201 & 206: Diese zeigen Geräte an, denen der AES-Support fehlt.
  • Fokus auf Events 202 & 207: Hier findest du Konten, die dringend einen Passwort-Reset benötigen.
  • Prüfen: Stelle sicher, dass das Auditing nicht durch manuell definierte DefaultDomainSupportedEncTypes auf den Domain Controllern blockiert wird.

Um nicht manuell in den Event-Logs zu versinken, solltest du den Prozess automatisieren. Microsoft stellt hierfür auf GitHub (Kerberos-Crypto) hilfreiche PowerShell-Module und Skripte bereit. Damit lässt sich das Einsammeln der Events professionalisieren.

Richte am besten Scheduled Tasks ein, die die entsprechenden Events stündlich einsammeln und für eine einfache Analyse in CSV-Dateien exportieren. So behältst du den Überblick, ohne den DC permanent manuell abfragen zu müssen.

1. 2. Den „Ernstfall“ simulieren

Nutze den temporären Registry-Key RC4DefaultDisablementPhase. Damit kannst du die RC4-Abschaltung bereits vor der offiziellen Deadline in Testumgebungen (oder kontrolliert in Produktion) provozieren, um Inkompatibilitäten aufzudecken. Du kannst den key RC4DefaultDisablementPhase auch dazu nutzen,  dir Zeit zu verschaffen. Sollte die Ernstfallsimulation gründlich schief gehen, kannst du das Deaktivieren von RC4 noch bis Juli hinauszuzögern.

Sobald deine Scheduled Tasks die Daten in CSVs ausgespuckt haben, beginnt die eigentliche Detektivarbeit. Die schiere Menge an Daten kann erschlagend wirken, aber der Fokus ist klar: Filtere in deiner Excel-Liste gezielt nach dem Ticket-Typ „RC4“.

Wenn du den Filter gesetzt hast, siehst du sofort das „Who-is-Who“ deiner Sicherheitslücken. In der Auswertung lässt sich präzise ablesen:

• Welche Applikation (Source/Requestor) noch auf den alten Standard setzt.

• Welche Service Accounts (Target) betroffen sind.

• Welche Systeme dringend ein Update oder eine Neukonfiguration benötigen.

Diese Liste ist nun deine „To-Do-Liste“ für die Bereinigung.

1. 3. Altlasten bereinigen

• • Identifiziere Keytab-Dateien ohne AES-Keys und generiere diese neu.
  • Erzwinge Passwortänderungen für Uralt-Konten.
  • Aktualisiere oder isoliere Systeme, die kein AES unterstützen.

Fazit: Handeln, bevor die Automatik greift

Angreifer lieben RC4-Schwachstellen. Die Deaktivierung ist aus Security-Sicht ein längst überfälliger Schritt. Wer die Projekte jetzt nicht priorisiert, wird im zweiten Halbjahr 2026 das Nachsehen haben, wenn Microsoft die Rückwege endgültig kappt.

Detaillierte technische Informationen zu den Änderungen und der CVE-2026-20833 findest du direkt im Microsoft Support Artikel.