Kerberos RC4 ist Geschichte: Was Microsofts Frist im Juli 2026 für mobiles SSO bedeutet

Lukas Schönbächler · Juli 2026 · 7 Min. Lesezeit

Im Juni haben wir Microsofts Plan zur Abschaltung von NTLM durchgespielt und gezeigt, was er für mobile Flotten bedeutet. NTLM ist aber nicht die einzige Legacy-Authentifizierung, die Microsoft 2026 abbaut. Die andere, die RC4-Verschlüsselung innerhalb von Kerberos selbst, hat soeben den Punkt erreicht, an dem es kein Zurück mehr gibt: Mit dem kumulativen Update vom Juli 2026 verschwindet die letzte Notluke endgültig. Was sich geändert hat, warum Kerberoasting der Grund dafür ist und wo mobiles Single Sign-on dabei leise kaputtgehen kann.

Was sich am 14. Juli 2026 geändert hat

Es ist die letzte Phase eines Rollouts, den Microsoft im Januar 2026 als Reaktion auf CVE-2026-20833 gestartet und in KB5073381 dokumentiert hat:

• 13. Januar 2026 (Phase 1): Domänencontroller beginnen, Audit-Ereignisse zu protokollieren (Kdcsvc-Ereignisse 201 bis 209 im Systemprotokoll), sobald ein Ticket von RC4 abhängt. Der Registrierungswert RC4DefaultDisablementPhase unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters kommt hinzu, damit Administratoren die Durchsetzung schon früher aktivieren können.
• 14. April 2026 (Phase 2): Die Standard-Cipher-Suite der Domäne wechselt auf reines AES-SHA1 (0x18). Konten ohne explizit gesetzte Verschlüsselungstypen erhalten keine RC4-Tickets mehr. Was dabei kaputtging, liess sich über den Registrierungswert in den Audit-Modus zurückversetzen.
• 14. Juli 2026 (Phase 3): Der Rollback-Wert wird entfernt und nicht mehr gelesen. Die Durchsetzung ist endgültig.

Microsofts AskDS-Engineering-Team formuliert es unmissverständlich: «Nach der Installation der kumulativen Windows-Updates vom Juli 2026 ist das Verhalten identisch mit April 2026, allerdings können Sie nicht mehr in den Audit-Modus zurückwechseln.» RC4 funktioniert nur noch bei Konten, bei denen es in msDS-SupportedEncryptionTypes explizit gesetzt ist, eine Ausnahme pro Konto, von der Microsoft ausdrücklich abrät.

Abbildung 1: Die drei Phasen der RC4-Abschaltung. Seit dem 14. Juli 2026 gibt es keinen domänenweiten Weg zurück zu RC4.

Warum RC4 sterben musste: Kerberoasting

Der Angriff, der RC4 das Genick gebrochen hat, heisst Kerberoasting. Jeder authentifizierte Domänenbenutzer kann ohne erhöhte Rechte ein Kerberos-Serviceticket für jedes Konto mit einem Service Principal Name (SPN) anfordern. Dieses Ticket ist mit dem Schlüssel des Servicekontos verschlüsselt, und die Anfrage löst keinerlei Alarm aus. Der Angreifer nimmt das Ticket offline mit und rechnet das Passwort per Brute Force heraus.

Ob dieser Angriff praktikabel ist, entscheidet die Chiffre. Ein RC4-HMAC-Ticket ist mit einem Schlüssel verschlüsselt, der direkt aus dem NT-Passworthash des Kontos abgeleitet wird; handelsübliche GPUs arbeiten sich mit enormer Geschwindigkeit daran ab, und mässig komplexe Passwörter fallen innerhalb von Stunden. AES-Schlüssel entstehen über PBKDF2 mit Tausenden von Iterationen und einem Salt, was denselben Angriff um Grössenordnungen verlangsamt. Ein Servicekonto mit reinem RC4-Schlüsselmaterial lässt sich offline in aller Ruhe knacken, und Servicekonten haben oft weitreichende Berechtigungen.

Dazu kommt die Compliance-Seite: NIST SP 800-131A hat RC4 bereits 2016 untersagt, PCI-DSS 4.0 verlangt dokumentierte Sanierungspläne für schwache Chiffren, und Cyberversicherer fragen in den Erneuerungsfragebögen 2026 nach dem Stand der Kerberos-Verschlüsselung.

Zwei Abschaltungen, ein Drehbuch

Falls Ihnen das Muster bekannt vorkommt: Das sollte es. Die RC4-Abschaltung folgt demselben dreistufigen Drehbuch wie die NTLM-Abschaltung: zuerst Audit-Ereignisse, dann neue Standardwerte, zuletzt fliegt die Notluke raus. RC4 hat den ganzen Zyklus nur in sechs Monaten durchlaufen. Betrachten Sie es als Generalprobe dafür, wie sich die NTLM-Durchsetzung anfühlen wird.

	NTLM-Abschaltung	Kerberos-RC4-Abschaltung
Audit-Phase	Ereignisse 4020 / 4022 / 4032 (Win 11 24H2, Server 2025)	Kdcsvc-Ereignisse 201 bis 209 (Januar 2026)
Neuer Standard	BlockNTLMv1SSO auf Enforce, Oktober 2026 (KB5066470)	Nur noch AES (0x18), 14. April 2026
Notluke	Reaktivierung per Gruppenrichtlinie (bis zur nächsten LTSC)	Registrierungsschlüssel RC4DefaultDisablementPhase
Punkt ohne Wiederkehr	Nächste Windows Server LTSC (voraussichtlich 2027)	14. Juli 2026: Schlüssel entfernt
Typische Opfer	Mobilgeräte, Workgroup- und Legacy-Clients	Servicekonten, Drucker, Appliances, Drittanbieter-Apps
Erkennung	Ereignis 8003 / 4022 auf App-Servern	Ereignis 4769 mit Ticketverschlüsselungstyp 0x17
Lösung für mobile Abläufe	PKINIT-Zertifikate über Ihr MDM	AES-Schlüsselmaterial auf den Konten hinter Ihren Apps

Was das für mobiles Kerberos-SSO bedeutet

Ein mobiler Kerberos-Ablauf besteht aus zwei Hälften. Zuerst holt das Gerät ein Ticket Granting Ticket (TGT) für den Benutzer. Diese Hälfte ist unkritisch. Hypergate Authenticator handelt standardmässig AES aus; es braucht also kein App-Update, keine Änderung an der Managed Configuration und keine Vorbereitung auf dem Gerät für diesen Stichtag. Die eine Ausnahme: Wer je über eine eigene Kerberos-Konfiguration Legacy-Chiffren erzwungen hat, sollte diese Übersteuerung im Zuge dieser Aufräumaktion entfernen. Danach fordert das Gerät für jede interne Anwendung, die der Benutzer öffnet, ein Serviceticket für den SPN dieser App an, und dieses Ticket ist mit dem Schlüssel des Servicekontos verschlüsselt.

In dieser zweiten Hälfte schlägt der 14. Juli zu. Hat das Konto vor Ihrem Intranet, Ihrem lokalen SharePoint oder einer Fachanwendungs-API nur RC4-Schlüsselmaterial, kann der KDC kein Ticket mehr dafür ausstellen. Die App liefert 401 in einer Endlosschleife. Für die Benutzer sieht das exakt so aus wie eine NTLM-Blockade, und genau deshalb wird es leicht falsch diagnostiziert: Teams, die mobil gerade erst von NTLM auf Kerberos migriert sind, verdächtigen die Migration, dabei ist der eigentliche Schuldige ein AD-Konto, dessen Passwort zuletzt 2009 gesetzt wurde.

Eine Unterscheidung grenzt die Suche deutlich ein. SPNs auf Computerkonten sind meist unproblematisch: Maschinenkonten rotieren ihre Passwörter alle 30 Tage und haben ihre AES-Schlüssel längst erzeugt. Das Risiko konzentriert sich auf Servicekonten vom Typ Benutzer, wie sie typischerweise hinter SAP, alten Webanwendungen oder einem IIS-Anwendungspool stecken, der einmal eingerichtet und nie wieder angefasst wurde. Deren Schlüssel erneuern sich nur bei einem Passwortwechsel, und bei manchen dieser Konten hat der schlicht nie stattgefunden.

Abbildung 2: Das Gerät erhält sein AES-TGT problemlos. Der Bruch passiert einen Schritt später, wenn das Serviceticket für den SPN einer App von einem Servicekonto abhängt, das nie AES-Schlüssel bekommen hat.

So finden Sie Ihre RC4-Abhängigkeiten

Zwei Stellen zeigen Ihnen, wo Sie stehen. Auf den Domänencontrollern enthält das Systemprotokoll die Kdcsvc-Ereignisse aus KB5073381: 201 und 202 sind die Audit-Warnungen, 203, 204, 208 und 209 bedeuten, dass ein Ticket tatsächlich verweigert wurde. Im Sicherheitsprotokoll identifiziert Ereignis 4769 mit Ticketverschlüsselungstyp 0x17 jedes Serviceticket, das noch mit RC4 ausgestellt wird (AES256 erscheint als 0x12).

Auf der Verzeichnisseite listen Sie jedes Konto mit einem SPN auf und prüfen dessen Verschlüsselungstypen:

# Alle Servicekonten (SPN gesetzt) und ihre Kerberos-Verschlüsselungstypen
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name,
        @{N='EncTypes';E={'0x{0:X}' -f [int]$_.'msDS-SupportedEncryptionTypes'}},
        @{N='SPNs';E={$_.ServicePrincipalName -join ', '}}

So lesen Sie die Werte: 0x18 bedeutet nur AES, der neue Standard und das Ziel. 0x4 bedeutet nur RC4, was seit dem 14. Juli nicht mehr funktioniert. 0x0 (nie gesetzt) fällt jetzt auf AES zurück, hilft aber nur, wenn das Konto tatsächlich AES-Schlüssel besitzt; Konten, deren Passwort älter ist als der Wechsel der Domäne auf die Funktionsebene von Windows Server 2008, haben nie welche erzeugt. 0x24 ist der dokumentierte Interoperabilitäts-Fallback (RC4 mit AES-Sitzungsschlüsseln) und sollte nur als Übergangslösung dienen.

Die Lösung: AES-Schlüssel statt Ausnahmen

Für jedes Konto, das der Audit zutage fördert, ist die Lösung dieselbe und in Minuten erledigt:

1. Setzen Sie das Kontopasswort zurück. Ein Passwort-Reset erzeugt frisches Schlüsselmaterial, inklusive der fehlenden AES-Schlüssel. Für die meisten Konten ist das bereits die ganze Lösung.
2. Setzen Sie msDS-SupportedEncryptionTypes auf 0x18 bei kritischen Servicekonten, damit die Konfiguration explizit ist und nicht von einem Standardwert geerbt wird.
3. Prüfen Sie von der mobilen Seite aus. Öffnen Sie die Kerberos-geschützten Apps Ihrer Flotte und kontrollieren Sie, dass die 4769-Ereignisse für deren SPNs jetzt Verschlüsselungstyp 0x12 zeigen.
4. Wo Sie den Dienst selbst betreiben, prüfen Sie ein gMSA. Group Managed Service Accounts rotieren automatisch 240 Zeichen lange Zufallspasswörter, tragen von Haus aus AES-Schlüssel und lassen kein von Menschen gewähltes Passwort übrig, das ein Angreifer knacken könnte.

Was Sie nicht tun sollten: RC4-Ausnahmen über einzelne Konten verstreuen. Jede Ausnahme stellt genau das Kerberoasting-Ziel wieder her, das diese ganze Übung beseitigt. Microsofts Leitfaden ist da eindeutig: Der Ausnahmepfad ist ein letzter Ausweg für Legacy-Appliances, keine Migrationsstrategie.

Wo Sie damit stehen

Die Richtung kennt nur einen Weg: RC4 hat im Juli seinen Rollback verloren, NTLMv1 wird im Oktober blockiert (KB5066470), und Netzwerk-NTLM endet mit der nächsten Windows Server LTSC. Jeder Schritt führt an denselben Ort, nämlich zu Kerberos mit AES und zunehmend zu Zertifikaten statt Passwörtern. Für mobile Flotten ist die gute Nachricht, dass ein PKINIT-basiertes Setup bereits durchgehend AES spricht; die verbleibende Arbeit ist Active-Directory-Hygiene bei den Konten hinter Ihren Apps. Prüfen Sie jetzt die Verschlüsselungstypen in den 4769-Ereignissen und setzen Sie die Nachzügler zurück, dann geht der nächste Legacy-Stichtag vorbei, ohne dass es jemand merkt.

---