Kerberos RC4-Enforcement im Juli 2026: Letzter Aufruf für Ihre Domain Controller
CVE-2026-20833 – warum der eigentliche Bruch schon im April passiert ist und der Juli nur das Sicherheitsnetz entfernt
Mit den kumulativen Updates ab Juli 2026 schließt Microsoft die mehrstufige Härtung von Kerberos auf Windows Domain Controllern ab. Hintergrund ist CVE-2026-20833 – eine Schwachstelle, bei der ein authentifizierter Angreifer die kryptografische Schwäche von RC4 ausnutzen kann, um per Kerberoasting Service-Tickets zu erbeuten und Dienstkonten-Passwörter offline zu knacken. Die Lösung: RC4 verschwindet als implizit unterstützter Verschlüsselungstyp. Wer jetzt nicht aufgeräumt hat, riskiert Authentifizierungsausfälle.
Die wichtigste Nuance zuerst: Der „große Knall” war nicht der Juli, sondern der April 2026. Bereits mit dem April-Update wurde das Standardverhalten der KDC auf AES-SHA1-only umgestellt (Enforcement aktiv). Bis Juli konnten Sie über den Audit-Modus manuell zurückrollen. Mit dem Juli-Update entfällt genau dieser Rückwärtsgang – der Registry-Subkey RC4DefaultDisablementPhase wird ignoriert bzw. entfernt.
Der Zeitplan in drei Phasen
| Phase | Ab | Verhalten |
|---|---|---|
| Initial / Audit | Januar 2026 | Neue Audit-Events warnen vor RC4-Abhängigkeiten, kein Funktionsbruch |
| Second Deployment | April 2026 | KDC stellt für Konten ohne explizite Konfiguration auf AES-SHA1-only um; Enforcement aktiv, Audit-Modus als Rückrollung verfügbar |
| Final Enforcement | Juli 2026 | Audit-Modus entfällt, Rückrollung nicht mehr möglich; RC4 nur noch bei expliziter Konfiguration pro Konto |
Nach dem Juli-Update funktioniert RC4 also nur noch für Konten, die es ausdrücklich über das Attribut msDS-SupportedEncryptionTypes deklarieren. Alles andere bekommt AES.
Wer fällt typischerweise um?
Gewachsene AD-Umgebungen enthalten fast immer Konten und Geräte, die implizit oder explizit auf RC4 angewiesen sind. Die üblichen Verdächtigen:
- Domänengebundene NAS-Systeme und alte File-Server
- Netzwerkdrucker und Multifunktionsgeräte mit veraltetem Kerberos-Stack
- Industrie- und Branchenanwendungen mit alten Authentifizierungsbibliotheken
- Nicht-Windows-Systeme (Linux/Unix-Interop, Appliances)
- Azure Files SMB mit Active-Directory-basierter Authentifizierung
Jetzt prüfen: RC4-Abhängigkeiten finden
Konten ohne explizit gesetzten Verschlüsselungstyp (Attribut leer) fallen auf das KDC-Standardverhalten zurück – und das ist seit April AES-only. Diese Konten gilt es zu identifizieren:
# Konten finden, die RC4 explizit erlauben (Bit 0x4) oder kein EncType gesetzt haben
Get-ADObject -Filter * -Properties msDS-SupportedEncryptionTypes |
Where-Object {
($null -eq $_.'msDS-SupportedEncryptionTypes') -or
($_.'msDS-SupportedEncryptionTypes' -band 0x4)
} |
Select-Object Name, ObjectClass, msDS-SupportedEncryptionTypes |
Sort-Object ObjectClass, Name
Parallel sollten Sie das System-Ereignisprotokoll der Domain Controller auf Kerberos-Events überwachen. Audit-Events werden nur dann erzeugt, wenn Active Directory kein AES-SHA1-Service-Ticket oder keinen Session-Key ausstellen kann – die Abwesenheit von Events ist also kein Beweis dafür, dass alle (insbesondere Nicht-Windows-)Geräte nach dem Enforcement weiter funktionieren. Testen Sie Interoperabilität aktiv.
Enforcement vorab testen: Mit dem transitorischen Registry-Wert RC4DefaultDisablementPhase = 2 können Sie das Verhalten vor dem globalen Wechsel proaktiv aktivieren – ideal, um in einem Wartungsfenster Ausfälle aufzudecken, solange der Rückwärtsgang noch existiert.
# Enforcement-Verhalten vorab testen (vor Juli, solange Rueckrollung moeglich)
$path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
New-ItemProperty -Path $path -Name 'RC4DefaultDisablementPhase' -PropertyType DWord -Value 2 -Force | Out-Null
# Neustart des DC erforderlich
Wenn ein Gerät RC4 wirklich noch braucht
Lässt sich eine Altlast bis Juli nicht ablösen, konfigurieren Sie RC4 ausdrücklich auf dem betroffenen Konto – statt das gesamte KDC-Standardverhalten zu schwächen. Der Bitmask-Wert 28 (0x1C) erlaubt AES128 + AES256 + RC4:
# Nur fuer das eine Legacy-Dienstkonto, das RC4 zwingend braucht
Set-ADUser -Identity svc_legacy -Replace @{ 'msDS-SupportedEncryptionTypes' = 28 }
# 0x04 RC4 + 0x08 AES128 + 0x10 AES256 = 28 (0x1C)
Verstehen Sie das als Notausgang, nicht als Lösung: Jedes Konto mit aktivem RC4 bleibt ein Kerberoasting-Ziel. Setzen Sie eine Frist für die Ablösung und dokumentieren Sie die Ausnahme.
Fazit
Der Juli 2026 bringt keine strengere Logik als der April – aber er nimmt Ihnen die Möglichkeit zurückzurollen. Wer bis dahin nicht weiß, welche Konten und Appliances noch auf RC4 setzen, riskiert stille Authentifizierungsausfälle ohne Notbremse. Die Hausaufgabe ist klar: inventarisieren, im Wartungsfenster testen, Altlasten gezielt mit expliziten EncTypes versehen und einen Ablöseplan terminieren.
Kerberos-Verschlüsselung domänenweit auditieren?
Der ISW Kerberos Audit Analyzer und der ISW AD Tier Model Manager machen RC4-Abhängigkeiten, Encryption-Types und Kerberos-Schwachstellen über die gesamte Domäne sichtbar – inklusive Diagnostik zu Armoring/FAST. Mehr dazu auf isw-adtools.de.