Das Juli-Windows-Update entzieht RC4 in Kerberos endgültig den Standard. Domänencontroller aktivieren nach der Installation automatisch den Enforcement-Modus, der bisherige Audit- und Rollback-Schalter entfällt. Für die meisten Umgebungen ist das ein Sicherheitsgewinn. Wer aber Alt-Dienstkonten oder Appliances betreibt, die noch auf RC4 angewiesen sind, riskiert Ausfälle. Dieser Beitrag zeigt, was sich technisch ändert, wie Sie RC4-Abhängigkeiten in wenigen Schritten finden und wie Sie ausfallfrei auf AES umstellen.
Das Wichtigste in 30 Sekunden
Was ist neu? Die Windows-Updates ab Juli 2026 aktivieren die Endausbaustufe der Kerberos-RC4-Härtung automatisch (Enforcement-Modus). Der Audit- und Rollback-Registrierungsschlüssel RC4DefaultDisablementPhase wird entfernt.
Warum? RC4 ist eine veraltete, schwache Verschlüsselung. Über schwache Service-Tickets lassen sich Dienstkonten-Passwörter offline angreifen (Kerberoasting). Grundlage der Härtung ist CVE-2026-20833.
Was ist das Risiko? Konten und Dienste, die zwingend RC4 nutzen und keine AES-Unterstützung haben, können nach dem Update ausfallen.
Der Haken: Nach der Installation ist der bisherige Audit-Modus zum gefahrlosen Beobachten nicht mehr verfügbar.
Ihr nächster Schritt: RC4-Abhängigkeiten über die KDC-Audit-Events vor dem flächendeckenden Rollout finden, auf AES umstellen, unvermeidbare Ausnahmen gezielt und dokumentiert konfigurieren.
Was sich mit dem Juli-2026-Update ändert
Microsoft hat die Abschaltung von RC4 in Kerberos in drei Phasen über das Jahr 2026 verteilt. Mit den Juli-Updates ist die letzte Stufe erreicht: Der Enforcement-Modus wird durch die Installation programmatisch aktiviert, und der Schalter, mit dem sich einzelne Domänencontroller bisher in den beobachtenden Audit-Modus zurücksetzen ließen, entfällt. RC4 funktioniert danach nur noch für Konten, bei denen es explizit über das Attribut msDS-SupportedEncryptionTypes gesetzt ist.
| Phase | Zeitpunkt | Verhalten | Was Sie tun sollten |
|---|---|---|---|
| Audit | ab Januar 2026 | Warn- und Audit-Ereignisse für RC4-Nutzung, kein Blockieren | Audit-Events sammeln, RC4-Abhängigkeiten sichten |
| Enforcement mit Rollback | ab April 2026 | Enforcement wird Standard, einzelne DCs konnten temporär in Audit zurück | Umstellung auf AES vorantreiben, Ausnahmen prüfen |
| Endausbaustufe | mit Juli-2026-Updates | Enforcement automatisch, RC4DefaultDisablementPhase entfällt, Audit-Modus nicht mehr verfügbar | Vor Rollout Restabhängigkeiten beseitigen, Ausnahmen gezielt setzen |
Warum RC4 ein Sicherheitsrisiko ist
RC4 gilt seit Jahren als schwach. In Active-Directory-Umgebungen ist vor allem ein Angriffsmuster relevant: Ein Angreifer, der bereits ein gültiges Benutzerkonto besitzt, fordert Service-Tickets für Dienstkonten an. Sind diese Tickets mit RC4 verschlüsselt, kann er sie mitnehmen und das Passwort des Dienstkontos offline durchprobieren, ohne dass im Netzwerk etwas auffällt. Dieses Kerberoasting ist ein häufiger Zwischenschritt, um Rechte auszuweiten und sich in einer kompromittierten Domäne festzusetzen. Die RC4-Härtung entzieht Angreifern damit ein bewährtes Werkzeug.
RC4 und AES im Vergleich
Der Unterschied lässt sich auf einen Punkt bringen: RC4 erleichtert Offline-Angriffe auf Dienstkonten, AES erschwert sie deutlich. Deshalb ist AES ab Juli 2026 der Standard für alle Konten.
| Kriterium | RC4 | AES (empfohlen) |
|---|---|---|
| Kryptografische Stärke | Veraltet, angreifbar | Modern, robust |
| Offline-Angriff auf Dienstkonten | Erleichtert (Kerberoasting) | Deutlich erschwert |
| Microsoft-Standard ab Juli 2026 | Nicht mehr | Ja |
| Empfehlung | Nur dokumentierte Ausnahme | Standard für alle Konten |
Wer ist betroffen?
Betroffen sind vor allem On-Premises- und Hybrid-Umgebungen mit eigenem Active Directory. Achten Sie besonders auf:
Alt-Dienstkonten, die seit Jahren unverändert laufen und nie auf AES umgestellt wurden.
Vertrauensstellungen (Trusts) zu anderen Domänen oder Wäldern mit RC4-Konfiguration.
Appliances und Drittsysteme (z. B. ältere Netzwerk-, Backup- oder Speicherlösungen), die Kerberos nutzen, aber nur RC4 unterstützen.
Konten mit explizit gesetztem RC4 im Attribut msDS-SupportedEncryptionTypes.
Reine Cloud-only-Umgebungen ohne Active Directory sind vom Kern dieser Änderung in der Regel nicht betroffen.
Checkliste: RC4-Abhängigkeiten finden und auf AES umstellen
Rolle: Domänen-Administrator (zum Prüfen genügt oft Leserecht auf die Verzeichnis- und KDC-Logs). Umsetzung idealerweise in einem Wartungsfenster und mit Testphase.
Audit-Events auswerten. Kerberos- und KDC-Audit-Ereignisse zu RC4-Nutzung sichten, sie zeigen, welche Konten und Dienste RC4 anfordern.
Betroffene Konten inventarisieren. Dienstkonten, Computerkonten, Trusts und Appliances mit RC4-Bezug in einer Liste erfassen.
AES-Unterstützung prüfen. Je Konto und Dienst klären, ob AES unterstützt wird (Herstellerangaben, Konfiguration).
Auf AES umstellen. Konten auf AES konfigurieren, bei Dienstkonten die Passwörter neu setzen, damit AES-Schlüssel erzeugt werden.
Trusts und Appliances nachziehen. Vertrauensstellungen und Drittsysteme aktualisieren bzw. Hersteller-Updates einspielen.
In einer Testphase verifizieren. Anmeldungen und betroffene Dienste vor dem flächendeckenden Rollout testen.
Juli-Update kontrolliert ausrollen und überwachen. Nach dem Rollout die Audit- und Fehlerereignisse weiter beobachten und Restfälle nachbessern.
Was tun, wenn ein Dienst RC4 zwingend braucht?
Manche Alt- oder Drittsysteme lassen sich kurzfristig nicht auf AES umstellen. In diesem Fall gilt laut Microsoft als letztes Mittel:
Auf dem betroffenen Dienstkonto msDS-SupportedEncryptionTypes gezielt so setzen, dass RC4 mit AES-Sessionschlüsseln (Wert 0x24) zulässig ist.
Nur wenn das nicht möglich ist, hilfsweise DefaultDomainSupportedEncTypes auf den relevanten KDCs entsprechend konfigurieren. Das schwächt jedoch die Absicherung breiter und sollte die absolute Ausnahme bleiben.
Jede Ausnahme dokumentieren, terminieren und mit einem Migrationsziel versehen. Ausnahmen sind kein Dauerzustand.
Einordnung: Juli-Patchday und AD-Härtung
Die RC4-Endausbaustufe fällt mit dem Juli-2026-Patchday am 14. Juli zusammen. Nach dem rekordverdächtigen Juni mit über 200 behobenen Schwachstellen, darunter mehrere Zero-Days, ist auch im Juli mit einer umfangreichen Update-Welle zu rechnen. Zwei Empfehlungen:
Planen Sie den Juli-Patch so, dass die RC4-Umstellung vorher abgeschlossen bzw. getestet ist.
Behandeln Sie den Patchday als festen Prozess mit Priorisierung aktiv ausgenutzter Lücken, ein wesentlicher Baustein von Schwachstellen- und Patch-Management, wie es auch NIS2 als Risikomanagementmaßnahme adressiert.
Fazit und nächste Schritte
Die RC4-Abschaltung ist überfällig und stärkt die Sicherheit Ihres Active Directory, vorausgesetzt, sie überrascht Sie nicht bei laufendem Betrieb.
Sofort: KDC-Audit-Events sichten, RC4-Abhängigkeiten identifizieren.
Diese Woche: Betroffene Konten und Dienste auf AES umstellen und testen, bevor der Juli-Patch flächendeckend ausgerollt wird.
Strategisch: Die AD-Härtung in einen wiederkehrenden Prüfprozess überführen, etwa über ein regelmäßiges Active Directory Audit.
RC4-Altlasten im Active Directory aufspüren
Unsicher, wo in Ihrem Active Directory noch RC4-Altlasten schlummern? Unser Active Directory Audit deckt genau solche Schwachstellen strukturiert auf, bevor der Enforcement-Modus zu Ausfällen führt.
Für die Angriffssicht bietet sich ein Pentest an, für den laufenden Schutz Microsoft Defender XDR im Managed Service bzw. Managed Cloud Resilience. Praxisnah dazu: unser Webinar Incident Response, ein Ransomware-Angriff aus der Praxis.
Häufige Fragen zur Kerberos-RC4-Härtung
Es aktiviert den Enforcement-Modus programmatisch. Der Audit- und Rollback-Schlüssel RC4DefaultDisablementPhase entfällt, und RC4 funktioniert nur noch für explizit konfigurierte Konten.
Nur bei Konten und Diensten, die zwingend RC4 nutzen und keine AES-Unterstützung haben. Deshalb sollten Sie die Audit-Events vorher auswerten.
Eine Schwachstelle, über die schwache RC4-Service-Tickets für Offline-Passwortangriffe missbraucht werden können. Die Härtung adressiert genau dieses Risiko.
Über die Kerberos- und KDC-Audit-Ereignisse und die Verschlüsselungstyp-Attribute der Konten.
Konten auf AES konfigurieren, Dienstkonten-Passwörter neu setzen, damit AES-Schlüssel entstehen, Trusts und Appliances nachziehen.
Als letztes Mittel msDS-SupportedEncryptionTypes gezielt auf 0x24 (RC4 mit AES-Sessionschlüssel) setzen und den Ausnahmefall dokumentieren.
Der Kern betrifft On-Premises- und Hybrid-AD. Reine Cloud-only-Umgebungen ohne Active Directory sind in der Regel nicht betroffen.