Kerberos RC4 2026: AES-Migration prüfen

28.10.2026 · IT-Wissen

Kerberos RC4 2026: Microsoft hat die Absicherung der Kerberos-Verschlüsselung im Jahr 2026 deutlich verschärft. Die gestaffelten Windows-Updates begannen mit Vorbereitungsschritten im Januar, führten im April neue Default-Verhaltensweisen ein und erreichten im Juli 2026 die finale Enforcement-Phase im Kontext von CVE-2026-20833. Das bedeutet nicht, dass sämtliche ausdrücklich konfigurierten RC4-Szenarien auf einen Schlag unmöglich wurden. Unklare Legacy-Abhängigkeiten können aber zu fehlgeschlagenen Service-Ticket-Anfragen führen. Dieser Leitfaden zeigt, wie Sie AES-Unterstützung prüfen, Ereignisse auswerten, Dienstkonten migrieren und Störungen vermeiden.

Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen · 28. Oktober 2026

Warum RC4 in Active Directory noch verwendet wird

Kerberos verwendet Tickets für die Anmeldung an Diensten. Ältere Windows- und Nicht-Windows-Systeme haben historisch RC4-HMAC eingesetzt. In gewachsenen Domänen finden sich Accounts mit alten Schlüsseln, expliziten Verschlüsselungseinstellungen oder nicht modernisierten Drittanwendungen. Dieser Betrieb funktioniert häufig jahrelang, bis ein Domain-Controller-Update die Annahmen über unterstützte Algorithmen verändert. Das Risiko betrifft nicht nur Benutzeranmeldungen, sondern auch Hintergrunddienste, SQL-Verbindungen und geplante Aufgaben.

RC4 gilt als schwächer als moderne AES-basierte Ticketverschlüsselung. Bestimmte Angriffsverfahren versuchen, aus erbeuteten Service-Tickets offline Kennwörter wiederzugewinnen. Die Umstellung reduziert einen Teil dieses Risikos, vorausgesetzt, Anwendungen, KDCs und Accounts unterstützen die Zielkonfiguration. Ein Sicherheitsprojekt muss deshalb Kryptografie, Dienstinventar und Betrieb gemeinsam betrachten. Ein Patch ohne anschließende Anwendungsprüfung reicht nicht.

Kerberos RC4 2026: Microsofts Update-Phasen verstehen

Microsoft veröffentlichte im Januar 2026 Änderungen zur Vorbereitung und Prüfung der RC4-Abhängigkeiten. Im April folgte ein stärker auf AES ausgerichtetes Standardverhalten mit vorübergehenden Möglichkeiten zur Fehlerbehandlung. Seit den Juli-2026-Sicherheitsupdates ist der zuvor vorgesehene Audit-/Rollback-Übergang für die betroffene Änderung abgeschlossen. Enforcement ist die unterstützte Betriebsart; der temporäre Schalter RC4DefaultDisablementPhase steht nicht mehr als Ausweichmöglichkeit zur Verfügung.

Die präzise technische Einordnung ist entscheidend: Die Änderung adressiert insbesondere Service-Ticket-Anfragen, die sich bisher auf implizite RC4-Unterstützung verlassen haben. Sie ist nicht mit einem sofortigen globalen Verbot jeder explizit unterstützten RC4-Konfiguration gleichzusetzen. Administratoren sollten die eingesetzten Windows-KBs und Microsofts Hinweise zu CVE-2026-20833 dokumentieren. Ein Blogbeitrag aus der Übergangsphase darf nicht als gültige Anleitung für Oktober 2026 verwendet werden.

Security Events 4768 und 4769 systematisch auswerten

Die Security-Events 4768 für Ticket-Granting-Ticket-Anfragen und 4769 für Service-Ticket-Anfragen helfen, verwendete und unterstützte Verschlüsselungstypen sichtbar zu machen. Auf Windows Server 2019 und später sind entsprechende Felder dokumentiert; Windows Server 2016 erhielt erweiterte Informationen mit kumulativen Updates ab Januar 2025. Sammeln Sie die Ereignisse von allen relevanten Domain Controllern, nicht nur von einem primären KDC. Berücksichtigen Sie Standorte und den Zeitraum wiederkehrender Batch-Jobs.

Werten Sie Ticket Encryption Type, Supported Encryption Types, Client und betroffenen Service Principal Name gemeinsam aus. Ein einzelner Zahlenwert ohne Account- und Zielkontext liefert kein belastbares Urteil. Manche Felder enthalten berechnete beziehungsweise verarbeitete Werte und sind nicht identisch mit einem unverändert ausgelesenen AD-Attribut. Die Analyse soll zeigen, welcher Client welches Dienstkonto für welche Anwendung erreicht und ob die betreffende Ticketanforderung tatsächlich erfolgreich war.

Servicekonten mit alten Kerberos-Schlüsseln identifizieren

Der größte Migrationsaufwand liegt oft bei langjährig betriebenen Servicekonten. Dazu zählen SQL-Server-Dienste, Webanwendungen, Dateiserver, Java-Dienste, Backup-Software und proprietäre Integrationen. Ein Konto, dessen Passwort seit sehr langer Zeit unverändert ist, besitzt möglicherweise nicht alle modernen Kerberos-Schlüssel. Auch ausdrücklich konfigurierte Verschlüsselungstypen oder falsche SPNs können die Abhängigkeit verstärken.

Führen Sie ein Dienstkontenregister mit SPNs, verantwortlichen Teams, Passwortänderungsprozess und unterstützten Betriebssystemversionen. Prüfen Sie, welche Anwendungen das Konto verwenden, bevor Sie dessen Kennwort ändern oder die erlaubten Verfahren einschränken. Ein technisch erfolgreicher Passwortwechsel kann trotzdem einen Geschäftsprozess stoppen, wenn dieselben Zugangsdaten an einer zweiten Stelle gespeichert sind. Stimmen Sie die Prüfung deshalb mit den jeweiligen Anwendungsverantwortlichen ab.

AES für Benutzer, Computer und Dienste vorbereiten

Aktuelle Kerberos-Umgebungen unterstützen üblicherweise AES128 und AES256. Welche Ticketverschlüsselung zum Einsatz kommt, ergibt sich aus Client, KDC, Servicekonto und verfügbaren Schlüsseln. Stellen Sie sicher, dass die betroffenen Konten über kompatible Schlüssel verfügen. Bei einem geeigneten Passwortwechsel werden neue Schlüssel abgeleitet, sofern Plattform und Konto dies unterstützen. Für passende Windows-Dienste können Group Managed Service Accounts die Verwaltung vereinfachen.

Ändern Sie Gruppenrichtlinien nicht blind auf allen Domänencomputern. Dokumentieren Sie zunächst die reale Abhängigkeit, führen Sie einen begrenzten Piloten durch und prüfen Sie danach tatsächlich ausgestellte Tickets. Ob eine lokale GPO-Konfiguration erforderlich ist, muss im Kontext von Domain Controller, Client und Dienstkonto entschieden werden. Der Sicherheitsgewinn entsteht durch nachgewiesene AES-Nutzung, nicht durch einen Registry-Wert, dessen Auswirkungen niemand bewertet hat.

msDS-SupportedEncryptionTypes richtig interpretieren

Das Attribut msDS-SupportedEncryptionTypes beschreibt im Active Directory die Unterstützung bestimmter Kerberos-Methoden. Es kann ausdrücklich gesetzt sein oder bei fehlendem Wert über KDC-Defaults interpretiert werden. Windows-Versionen und Sicherheitsupdates haben die Darstellung und das Verhalten im Laufe der Zeit verändert. Ein leeres Attribut ist daher kein Beweis für eine sichere Konfiguration, genauso wenig wie die Sichtbarkeit eines RC4-Bits automatisch eine aktuelle RC4-Ticketnutzung belegt.

Prüfen Sie die Einstellungen gemeinsam mit den KDC-Events und der tatsächlich genutzten Ticketverschlüsselung. Bei Windows Server 2025 bestehen zusätzliche Unterschiede zu älteren Domain-Controller-Versionen, die in Microsofts Dokumentation beschrieben sind. Änderungen sollten deshalb auf den unterstützten Konfigurationswegen erfolgen, mit Backup der betroffenen Werte und einer fachlichen Validierung nach dem Change.

SQL Server, IIS, Samba und Non-Windows-Clients

Mittelständische Netzwerke bestehen häufig aus mehreren Betriebssystemen und Identitätsdomänen. Ein Linux-Samba-Server oder ein proprietäres NAS nutzt möglicherweise andere Kerberos-Bibliotheken als ein aktueller Windows-Client. Anwendungen können einen eigenen SPN erwarten oder eine über Jahre etablierte Anmeldung nutzen. Eine reine Testanmeldung an Windows beweist deshalb nicht, dass Datenbankzugriffe, SMB-Freigaben und IIS-Anwendungen ebenfalls funktionieren.

Planen Sie Ende-zu-Ende-Tests mit echten Servicekonten und repräsentativen Fachanwendungen. Dokumentieren Sie pro Test, welches Ticket benötigt wird, welcher Zielserver erreicht wird und welches Ergebnis nach der Änderung vorliegt. Berücksichtigen Sie seltene Geschäftsprozesse: nächtliche Backups, Monatsabschlüsse und Jobs, die nur nach einer Wartung starten. Fehler in diesen Abläufen werden sonst möglicherweise erst Wochen nach der eigentlichen Kryptografie-Änderung bemerkt.

Kerberos RC4 ist nicht dasselbe wie NTLM

Die Abschaltung von NTLM und die Ablösung von RC4 in Kerberos sind verwandte, aber unterschiedliche Projekte. NTLM ist ein eigenes Authentifizierungsprotokoll. RC4 beschreibt hier eine mögliche Verschlüsselung innerhalb einer Kerberos-basierten Anmeldung. Eine Anwendung kann erfolgreich auf Kerberos umgestellt worden sein und dennoch RC4-basierte Service-Tickets anfordern. Umgekehrt kann eine vollständig AES-fähige Umgebung weiterhin unsichere NTLM-Fallbacks erlauben.

Verbinden Sie die Projekte über ein gemeinsames Identitäts- und Anwendungsinventar, führen Sie jedoch getrennte Abnahmekriterien. Ein Ergebnis „NTLM ausgeschaltet“ darf nicht als „Kerberos RC4 behoben“ berichtet werden. Fragen Sie bei Problemen nach dem Authentifizierungsprotokoll, den konkreten Tickettypen und den KDC-Daten, statt sämtliche Probleme mit dem Schlagwort Single Sign-On zu vermischen.

Authentifizierungsfehler nach Updates diagnostizieren

Wenn nach einem Windows-Update eine Anwendung nicht mehr authentifiziert, prüfen Sie zuerst den genauen Zeitpunkt, den betroffenen KDC, das Servicekonto und die Fehlermeldung. Fehlende SPNs, DNS-Probleme, Uhrzeitabweichungen und Berechtigungsfehler können ähnliche Symptome hervorrufen. Erst wenn die Ticketverschlüsselung und die KDC-Informationen passend sind, wird eine RC4-Abhängigkeit als wahrscheinliche Ursache eingestuft.

Im Incident-Ticket sollten betroffene Clients, erfolgreiche und fehlerhafte Zielsysteme, eingesetzte Konten und der letzte funktionierende Softwarestand stehen. Vermeiden Sie eine domänenweite Abschwächung der Sicherheitsrichtlinie als reflexartige Notlösung. Wo eine befristete technische Ausnahme noch unterstützt ist, begrenzen Sie sie auf die konkret betroffenen Konten, dokumentieren das Risiko und vereinbaren ein verbindliches Enddatum.

Kerberoasting-Risiko auch organisatorisch senken

Kerberoasting beschreibt Angriffe, bei denen Service-Tickets abgegriffen und offline gegen schwache Kontenkennwörter angegriffen werden. AES-Nutzung und starke, individuelle Dienstkennwörter reduzieren einen Teil des Risikos. Servicekonten sollten außerdem nur die Rechte erhalten, die ihre Anwendung benötigt, keine unnötigen interaktiven Anmeldungen erlauben und nicht pauschal Mitglied privilegierter AD-Gruppen sein.

Ergänzen Sie die technische Umstellung durch regelmäßige Prüfungen von SPNs, Administratorrechten, Delegation und ungewöhnlichen Ticketanforderungen. Einzelne 4769-Events sind noch kein Angriffsnachweis. Die Relevanz entsteht aus Umfang, Häufung, Client-Kontext und tatsächlicher Dienstverwendung. Ein sinnvoller Detection-Use-Case stellt diese Zusammenhänge dar und ermöglicht eine Reaktion, bevor ein Konto zu größerem Schaden führt.

Pilot, Change Management und Rückfallkonzept

Teilen Sie die Anwendungen in Gruppen: moderne Windows-Dienste, ältere Anwendungen und Non-Windows-Integrationen. Dokumentieren Sie je Gruppe die verantwortlichen Teams, Testfälle, Wartungsfenster und eine sichere Möglichkeit, die Änderungen an der Anwendung zurückzunehmen. Ein Rollback darf seit Juli 2026 nicht von einem inzwischen entfernten temporären Enforcement-Schalter ausgehen.

Für produktive Servicekonten protokollieren Sie die Anpassungen, den angewendeten Tickettyp und das Testergebnis. Eine Störung soll durch eine korrekte, unterstützte Konfiguration behoben werden, nicht durch das Abstellen weiterer Schutzfunktionen. Erst wenn SQL-Verbindungen, Web-SSO, geplante Aufgaben und Dateifreigaben nachweislich arbeiten, gilt die Umstellung als erfolgreich.

30-Tage-Plan zur AES-Migration

Woche eins: KDC-Patchstände, Dienstkonten, SPNs und Kerberos-Events erfassen. Woche zwei: RC4-Abhängigkeiten nach Geschäftsrelevanz priorisieren und Pilottests mit zuständigen Anwendungsteams planen. Woche drei: Konten, Geräte und Drittanbieterintegrationen schrittweise modernisieren. Woche vier: kritische Geschäftsabläufe prüfen, bestehende Ausnahmen dokumentieren und ein kontinuierliches Monitoring etablieren.

Der wichtigste Erfolgsindikator ist nicht die Zahl geänderter Konten, sondern der Anteil geschäftskritischer Anwendungen, die zuverlässig mit AES-basierten Tickets arbeiten. Beobachten Sie nach dem Rollout neu auftretende RC4-Nutzung und Authentifizierungsfehler, damit spätere Softwareinstallationen keine unsicheren Abhängigkeiten wieder einführen.

Häufige Fragen zur Kerberos RC4 Migration

Sind seit Juli 2026 alle RC4-Tickets verboten?

Nein. Die Änderung betrifft insbesondere die standardmäßig angenommene Unterstützung bei bestimmten Service-Ticket-Anfragen. Langfristiges Ziel ist die sichere AES-Nutzung.

Welches Event zeigt Service-Ticket-Anfragen?

Security Event ID 4769. Event ID 4768 bezieht sich auf Ticket-Granting-Ticket-Anfragen.

Kann ich alle Dienstkonten gleichzeitig umstellen?

Das ist riskant. Vorher müssen sämtliche abhängigen Dienste, SPNs und Jobs bekannt sein.

Ersetzt AES-Migration das Abschalten von NTLM?

Nein, das sind unterschiedliche Authentifizierungs- und Sicherheitskontrollen.

Fazit: AES-Migration nachprüfbar betreiben

Die Anforderungen rund um Kerberos RC4 2026 machen ein vollständiges Anwendungsinventar, die gezielte Auswertung von KDC-Events und erfolgreiche Funktionstests besonders wichtig. Der richtige Weg ist Erkennen, Priorisieren, Migrieren und dauerhaftes Monitoring – nicht das globale Abschwächen von Sicherheitsrichtlinien.

Über den Autor

Salman Dolatpanah Gortlar schreibt für GORTNET über Windows Server, Active Directory und Cybersecurity mit Schwerpunkt auf praxisorientierter Systemadministration und nachvollziehbaren Sicherheitsprüfungen.

Offizielle Quellen

Prüfen Sie konkrete Windows-Versionen, Sicherheitsupdates und Anwendungskompatibilität vor Produktivänderungen.