Kerberos Authentifizierung Änderungen 2026.

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.

Was wird sich bei Kerberos ändern?

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

Supported encryption type

 

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

Supported Windows versions

 

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

Visualisierung der drei Update Phasen für Kerberos Änderung

Phase 1 (Audit Phase)

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.

Phase 2 (Enforcement with manual rollback)

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.

Phase 3 (Enforcement)

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.

Hintergrund: Kerberos AES und RC4

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.

Muss ich bei Kerberos handeln?

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.

Was sollte ich jetzt machen?

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.

  1. Prüfen, ob Domain Function Level auf mind. Windows Server 2008 ist. Wenn drunter → unbedingt handeln.
  2. Prüfen, ob Legacy Systeme benutzt werden. Unter Legacy Systemen zählen Windows Server 2003 / Windows XP und älter → unbedingt handeln.
  3. Prüfen, ob Service Accounts (normale User & gMSA) genutzt werden → normale User durch gMSA ersetzen. RC4 bei gMSA ausschalten.
  4. Jeder Domain Controller ist auf dem gleichen Windows Update Stand von Januar 2026.
  5. Auf den Domain Controller sind die Events ID 201-209 im SYSTEM LOG zu prüfen.

Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.

 

Ansprechpartner

Buchen Sie einen Termin mit unseren Experten oder schreiben Sie uns eine Nachricht um mehr zu erfahren.
Close-up_Shot_Rounded_Web.png

Daniel Meier

Ihr Partner für IT-Beratung und Services.

Wir sind für Sie da
Erfolgreiche Projekte mit Rewion als Trusted Advisor
DHBW
stack it
Dr. Frontheim
IKK Kliniken
Landes Krankenhaus
AWO
Röchling
TÜV Rheinland
thyssenkrupp
SWR
Siemens
Schwarz Gruppe
Die Stuttgarter
LVM
FEIN
Kärcher
HSD
HITACHI
Frankfurt Airport
EF Eugster Frismag
dm Tech
DHBW
stack it
Dr. Frontheim
IKK Kliniken
Landes Krankenhaus
AWO
Röchling
TÜV Rheinland
thyssenkrupp
SWR
Siemens
Schwarz Gruppe
Die Stuttgarter
LVM
FEIN
Kärcher
HSD
HITACHI
Frankfurt Airport
EF Eugster Frismag
dm Tech
dataport
Carthago
Bucher
Deichmann
Bauwerk
Ritter Sport
Dürr
Ilm-Kreis-Kliniken
Robert-Bosch Krankenhaus
ARD
Fritz
RAPS
Bayrisches Staatsministerium
coop
BALLUFF
hr
NDR
MDR
Universitätsklinikum Freiburg
Konstruktionsgruppe Bauen
BIM Cluster
dataport
Carthago
Bucher
Deichmann
Bauwerk
Ritter Sport
Dürr
Ilm-Kreis-Kliniken
Robert-Bosch Krankenhaus
ARD
Fritz
RAPS
Bayrisches Staatsministerium
coop
BALLUFF
hr
NDR
MDR
Universitätsklinikum Freiburg
Konstruktionsgruppe Bauen
BIM Cluster

Technischer Support

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.

Support-Hotline

Für dringende Anfragen erreichen Sie uns telefonisch unter:

Support E-Mail

Senden Sie uns Ihr Anliegen mit allen relevanten Details an:

Fernwartung via TeamViewer

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].