2026 verschärft Microsoft die Standards für Kerberos in Active Directory: Die veraltete RC4-Verschlüsselung wird schrittweise deaktiviert. Ziel ist es, bekannte Risiken zu reduzieren und die Sicherheitslücke CVE-2026-20833 zu adressieren. Mit den Sicherheitsupdates des ersten Halbjahres im Jahr 2026 wird das Standardverhalten am Key Distribution Center (KDC) phasenweise angepasst. Ohne saubere Vorbereitung kann das zu Authentifizierungsfehlern und Zugriffsproblemen führen.
Der Artikel gibt Ihnen einen kompakten Überblick und zeigt, wie Sie Ihr Unternehmen rechtzeitig dafür prüfen und vorbereiten können.
Um die Änderung einordnen zu können, lohnt sich ein Blick ins Jahr 2022: Damals hat Microsoft ein grundlegendes Standardverhalten definiert. Microsoft steuert die zulässigen Kerberos-Verschlüsselungsalgorithmen über zwei Registry-Einträge: Der eine steuert das domänenweite Standardverhalten (DefaultDomainSupportedEncTypes) und der andere (msds-SupportedEncryptionTypes) steuert das Verhalten dezidiert für Computer und Serverdienste. Mit den Updates aus 2022 und 2026 ändert sich jeweils der implizite Standardwert von DefaultDomainSupportedEncTypes. Wenn man einen anderen Wert möchte, muss man ihn explizit setzen. Der KDC orientiert sich immer dann an DefaultDomainSupportedEncTypes, wenn msds-SupportedEncryptionTypes entweder nicht gesetzt oder 0 entspricht. Beide Werte bestimmen den genutzten Verschlüsselungsalgorithmus für die Kerberos Anmeldung. Das Key Distribution Center ist die Steuerzentrale für das Active Directory und übernimmt die Rolle eines Türstehers, der den Einlass kontrolliert.
Vereinfacht gesagt: vor 2022 akzeptierte der KDC entweder RC4 oder AES – je nachdem, was angefragt wurde. Seit 2022 gilt implizit ein Default von 0x27. Ab 2026 wird der Standardwert auf 0x18 gesetzt.
| Wert | Übersetzung | Bewertung |
| 0x18 | AES-128, AES-256 | ✅ |
| 0x27 | DES, RC4, AES-256-SK | ❌ |
| 0x1C | RC4, AES-128, AES-256 | ⚠️ |
| 0x1F | DES, RC4, AES-128, AES-256 | ❌ |
Wird der Standard auf 0x18 gesetzt, können ältere Systeme oder alte Konfiguration scheitern, wenn Sie auf RC4 angewiesen sind. Der KDC erlaubt nur Algorithmen, die effektiv erlaubt sind.
| Betriebssystem | DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_HMAC_SHA1 | AES256_HMAC_SHA1 |
| Windows 2003, Windows XP und älter |
Supported | Supported | Supported | No support | No support |
| Windows Vista | Supported | Supported | Supported | Supported | Supported |
| Windows 2008 | Supported | Supported | Supported | Supported | Supported |
| Windows 2008R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 7 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 10 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2016 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2022 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 11 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2025 | No support | No support | Deactivated | Supported | Supported |
Die automatische Umsetzung wird über den im Januar 2026 eingeführten Wert RC4DefaultDisablementPhase gesteuert. Je nachdem, wie dieser eingestellt ist, werden RC4 Versuche zugelassen, blockiert oder protokolliert.
Bei aktiviertem RC4DefaultDisablementPhase wird AES zum Standard und setzt damit DefaultDomainSupportedEncTypes implizit auf den Wert 0x18. Bei einem aktivierten Audit Wert werden Meldungen generiert, die die fehlende Unterstützung kenntlich machen.
Eine vorzeitige Überprüfung Ihrer Umgebung ist daher dringendst zu empfehlen. Nach Abschluss der Umstellung wird RC4 für Kerberos in einer Active Directory Umgebung deaktiviert und daher erstmal nicht mehr nutzbar sein.
Microsoft unterteilt die Umstellung in drei Phasen:

Visualisierung der drei Update Phasen für Kerberos Änderung
Die erste Phase ist die Audit Phase. In dieser Phase werden zusätzliche Telemetriedaten und Events eingeführt, um Probleme zu identifizieren, bevor die Durchsetzung greift. Ziel ist es, die RC4-Abhängigkeiten sichtbar zu machen und erforderliche Anpassungen rechtzeitig umzusetzen. Optional kann die Deaktivierung von RC4 bereits in dieser Phase manuell vorgezogen werden. Eine vorzeitige Deaktivierung sollte dennoch unbedingt vorab geprüft werden, da sie ansonsten zu Authentifizierungsabbrüchen und damit zu Dienstunterbrechungen führen kann. Für die Auswertung der Events bietet sich eine zentrale Stelle zur Protokollanalyse an (bspw. über Windows Eventlog Forwarding oder SIEM). Die Event ID’s 201-209, 4768-4769 sind zu prüfen.
In der zweiten Phase wird der Standard von RC4 auf AES automatisch gesetzt. Diese Umstellung kann noch rückgängig gemacht werden. Diese Phase ist die letzte Phase, in der Administratoren noch die Flexibilität haben, RC4DefaultDisablementPhase zurückzudrehen. Bevor es zur dritten Phase geht, sollte sichergestellt werden, dass kein Gerät mehr auf RC4 angewiesen ist, da ansonsten die Authentifizierung fehlschlägt.
Die dritte Phase ist die letzte Phase. In dieser Phase gibt es kein einfaches Entrinnen mehr. Die Durchsetzung greift ein und deaktiviert RC4. Eine Reaktivierung über RC4DefaultDisablementPhase ist dann nicht mehr möglich. Wenn Sie diese Phase überstanden haben und Ihre Serverdienste weiterhin laufen, haben Sie gute Arbeit geleistet.
Beides sind weitverbreitete Verschlüsselungsalgorithmen. RC4 war lange Bestandteil von vielen Softwares, da es im Vergleich zu AES effizienter und eine größere Abwärtskompatibilität gewährleistet.
Der Rivest Cipher 4 (RC4) Verschlüsselungsalgorithmus ist kryptografisch unsicher und kann durch sogenannte „Roasting Attacken“ wie dem Kerberoasting ausgenutzt werden. Hierbei fordert ein Angreifer ein Kerberos Ticket an und „brute forced“ offline das Passwort des Authentifizierungstickets. Gelingt es, das Passwort zu knacken, sind u.a. weitergehende Ticket-Manipulation wie dem Silver Ticket möglich, um sich Zugriff auf Dienste zu verschaffen.
Sie müssen handeln, wenn Sie eine Active Directory oder Hybrid-Umgebung nutzen. Sobald sich ein Legacy Gerät im Netzwerk befindet und das Update eingespielt wird, schlägt die Kerberos Authentifizierung fehl und es kommt zu einem Fallback zu NTLM. Bei NTLM gibt es ganz andere Angriffsvektoren, die zu beheben sind. Wenn Sie NTLM bereits erfolgreich unterbunden haben, schlägt die Anmeldung grundlegend fehl. Ggf. müssen Sie regulatorische Anforderungen (wie NIS2, DORA, ISO/IEC 27001 etc.) nachkommen und wollen daher beim Audit glänzen. Das können Sie nur, wenn Sie RC4 deaktivieren und AES die Bühne geben.
Um obiges kurz und knapp zusammenzufassen, hier eine Handlungsempfehlung zu der bevorstehenden technischen Umstellung seitens Microsofts. Es ist wichtig, dass Sie sich unbedingt vorab ein Bild Ihrer Umgebung machen. Die Umstellung findet automatisch statt und kann im schlimmsten Fall den Zugriff auf Serverdienste einschränken.
Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.
There are no results matching your search
There are no results matching your search
There are no results matching your search
























































































































Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].