RC4 abschalten ohne Blackout: Kerberos-Verschlüsselungstypen im Griff

Es gibt zwei Sorten von Ausfällen. Die erste kommt von einer Änderung, die jemand vorgenommen hat; die findet man, indem man das Änderungsprotokoll aufschlägt. Die zweite kommt von einer Änderung, die niemand vorgenommen hat, weil sie schon monatelang im Kalender stand und mit einem gewöhnlichen Windows-Update ins Haus kam. Diese zweite Sorte ist die unangenehmere, weil sie sich nicht zurückrollen lässt und weil das Ticketsystem hartnäckig behauptet, es habe niemand etwas angefasst. Die Abschaltung von RC4 in Kerberos gehört zur zweiten Sorte.

Fachlich ist der Sachverhalt unstrittig. RC4 ist ein Stromchiffre aus den späten Achtzigern, und die Art, wie Kerberos ihn benutzt, macht aus jedem Dienstkonto mit einem mittelmäßigen Kennwort ein offenes Buch. Wer das noch verteidigen möchte, hat vermutlich auch beim Ende von DES einen Widerspruch eingelegt. Die eigentliche Schwierigkeit liegt nicht in der Kryptografie, sondern im Bestand: In fast jeder gewachsenen Umgebung hängen an RC4 genau die Dinge, die in keiner Dokumentation auftauchen. Ein Dienstkonto aus einer Migration, deren Projektleitung inzwischen im Ruhestand ist. Ein Speichersystem, dessen Wartungsvertrag zweimal den Anbieter gewechselt hat. Eine Vertrauensstellung in eine Domäne, die eigentlich 2019 abgeschaltet werden sollte und die jedes Jahr aufs Neue „im nächsten Quartal“ verschwindet.

Und dann gibt es noch die zweite, deutlich peinlichere Kategorie von Ausfällen: die selbst gebauten. Ein gut gemeintes Härtungsskript setzt auf zwölfhundert Konten das Attribut msDS-SupportedEncryptionTypes auf „nur AES“, meldet zwölfhundert Erfolge — und am nächsten Morgen authentifizieren sich vierzig davon überhaupt nicht mehr. Nicht, weil AES nicht funktionieren würde, sondern weil diese vierzig Konten schlicht keine AES-Schlüssel besitzen. Ein Attribut zu setzen erzeugt nämlich keine Schlüssel. Das tut ausschließlich ein Kennwortwechsel. Dieser eine Satz ist der Kern des ganzen Beitrags, und er ist der Grund, warum RC4-Härtungen so verlässlich an einem Freitagabend eskalieren.

Was jetzt folgt, ist der Weg, der ohne Blackout funktioniert: erst messen, dann Schlüssel erzeugen, dann erlauben, dann verbieten, dann kontrollieren. In dieser Reihenfolge und in keiner anderen. Dazu die Werkzeuge, mit denen man den Ist-Zustand ehrlich erhebt, statt ihn zu schätzen, eine Wertetabelle für die berüchtigte Bitmaske — und am Ende die Fehlerbilder, an denen man erkennt, was man kaputt gemacht hat, falls es doch passiert ist.

Zur Einordnung: Dieser Beitrag gehört zur Serie rund um Microsoft Kerberos; den Überblick über alle Bausteine gibt die Pillar-Seite /microsoft-kerberos. Warum ein TGT und ein Service-Ticket unterschiedlich verschlüsselt sein können und wessen Schlüssel dabei jeweils zum Einsatz kommt, steht in /kerberos-tickets-tgt-und-service-ticket. Wie ein Dienstname überhaupt an ein Konto kommt — die Zuordnung, über die der Domänencontroller in diesem Thema ständig stolpert — erklärt /spns-richtig-setzen-setspn. Und wer nach der Umstellung feststellt, dass zusätzlich die Weitergabe von Identitäten klemmt, findet die Modelle dahinter in /kerberos-delegierung-unconstrained-bis-rbcd.

Warum RC4 weg muss — und warum es sich trotzdem hält

Bevor wir uns über Bitmasken beugen, lohnt eine kurze Verständigung darüber, warum dieser Aufwand überhaupt betrieben wird. Nicht aus Prinzipienreiterei, sondern weil RC4 in Kerberos eine konkrete, seit Jahren industriell ausgenutzte Angriffsfläche aufspannt — und weil die Alternative seit 2008 in jedem Windows steckt.

Was RC4 in Kerberos praktisch anrichtet

Der entscheidende Punkt ist nicht die Chiffre selbst, sondern wie ihr Schlüssel zustande kommt. Beim RC4-Verfahren in Kerberos ist der Langzeitschlüssel eines Kontos unmittelbar aus dem Kennwort abgeleitet — ohne Salt, ohne nennenswerte Iterationen, ohne irgendetwas, das einen Angreifer bremsen würde. Wer ein Service-Ticket in die Finger bekommt, das mit dem RC4-Schlüssel eines Dienstkontos verschlüsselt ist, kann anschließend offline Kennwörter durchprobieren, bis sich das Ticket entschlüsseln lässt. Kein Netzwerkverkehr, keine Kontosperrung nach fünf Fehlversuchen, kein Eintrag in irgendeinem Anmeldeprotokoll. Das Verfahren heißt Kerberoasting, es ist in jedem Werkzeugkasten enthalten, und es ist der Grund, warum Microsoft die Voreinstellungen umgestellt hat.

Verschärfend kommt hinzu, dass jeder authentifizierte Domänenbenutzer für nahezu jeden registrierten Dienstnamen ein Service-Ticket anfordern darf. Das ist kein Fehler, sondern Protokolldesign: Der Domänencontroller weiß ja nicht, ob der Anwender den Dienst gleich benutzen wird oder nur gerade neugierig ist. Bei AES kostet dieses Vorgehen den Angreifer nichts als Rechenzeit ohne Aussicht auf Erfolg. Bei RC4 kostet es ihn einen Nachmittag, falls das Dienstkonto noch das Kennwort aus dem Jahr seiner Anlage trägt. Und Dienstkonten tragen erstaunlich oft das Kennwort aus dem Jahr ihrer Anlage.

Der zweite, seltener genannte Aspekt: Der RC4-Langzeitschlüssel eines Kontos ist derselbe Wert, der auch als NTLM-Hash dient. Wer ihn besitzt, braucht das Klartextkennwort gar nicht mehr — er kann sich damit direkt Tickets ausstellen lassen. RC4 in Kerberos ist damit die Brücke, über die zwanzig Jahre alte NTLM-Angriffstechniken in eine eigentlich moderne Authentifizierung hineinreichen. Man kann diese Brücke abreißen. Man sollte nur vorher nachsehen, wer noch darüber geht.

FAKTEN Drei Zahlen, die die Diskussion abkürzen AES-SHA1 gibt es in Windows seit Windows Server 2008 und Windows Vista. Das letzte Betriebssystem von Microsoft, das kein AES für Kerberos beherrschte, war Windows Server 2003. Wer noch Systeme betreibt, die tatsächlich AES nicht können, hat ein anderes, größeres Problem als Verschlüsselungstypen. Der RC4-Schlüssel eines Kontos entspricht seinem NTLM-Hash. Für einen Angreifer sind das keine zwei Geheimnisse, sondern eines. Windows Server 2025 bringt zusätzlich die AES-SHA2-Verfahren nach RFC 8009 mit (AES128-CTS-HMAC-SHA256-128 und AES256-CTS-HMAC-SHA384-192). DES ist aus Kerberos vollständig entfernt. Die Richtung ist damit eindeutig, und sie zeigt nicht zurück.

 

Die vier Gründe, warum RC4 in Ihrer Umgebung noch lebt

In der Praxis sind es fast immer dieselben vier Kategorien. Es hilft, sie zu kennen, weil jede eine eigene Behandlung braucht — und weil die Aufwandsschätzung sonst systematisch daneben liegt.

Woran RC4 in gewachsenen Umgebungen hängt

Kategorie	Typischer Vertreter	Warum ausgerechnet RC4	Der Ausweg
Altes Dienstkonto ohne AES-Schlüssel	Benutzerkonto, angelegt 2011, Kennwort nie geändert, Häkchen „Kennwort läuft nie ab“ gesetzt	AES-Schlüssel entstehen erst beim Kennwortwechsel. Das Konto hatte nie einen.	Kennwort zurücksetzen, Dienst neu hinterlegen, dann Attribut setzen
Anwendung mit eigener Kerberos-Bibliothek	Java-Anwendung mit Keytab, Appliance mit selbst gebautem Client	Die Keytab enthält nur einen RC4-Eintrag, weil sie 2014 so erzeugt wurde.	Keytab mit AES-Einträgen neu erzeugen, Anwendung neu ausrollen
Gerät ohne AES-Unterstützung	Multifunktionsgerät, Speichersystem, Steuerungsrechner mit sehr altem Kern	Der Hersteller hat AES nie nachgerüstet, weil das Gerät „nur scannt“.	Firmware prüfen, sonst Ausnahme mit Ablaufdatum oder Ersatz
Vertrauensstellung	Vertrauensstellung in eine Alt- oder Partnerdomäne	Das vertrauende Konto trägt kein AES-Bit, das Vertrauenskennwort ist uralt.	AES am Vertrauensobjekt aktivieren, dann Vertrauenskennwort neu setzen

 

Die ersten beiden Kategorien lassen sich mit vertretbarem Aufwand auflösen; das ist Fleißarbeit, kein Projekt. Die dritte ist die, bei der man den Einkauf braucht — und die man deshalb möglichst früh identifiziert, nicht am Ende. Die vierte ist die, die man vergisst, weil Vertrauensstellungen in keiner Konteninventur auftauchen und weil sie erst dann Krach machen, wenn jemand auf der anderen Seite arbeiten will.

Skizze 1: Die Termine der RC4-Abschaltung. Sie kommen mit dem Windows-Update ins Haus — ein Änderungsantrag wurde dafür nicht gestellt.

Was seit Juli 2026 gilt

Microsoft hat die Umstellung über mehrere Jahre in Phasen gelegt. Der erste große Schnitt kam im November 2022 mit CVE-2022-37966: Seither gilt AES-SHA1 als angenommener Standard für Konten, bei denen niemand etwas gesetzt hat, und seither gibt es den Registrierungswert DefaultDomainSupportedEncTypes, mit dem sich diese Annahme domänenweit steuern lässt. Historisch nahm ein Domänencontroller ohne diesen Wert die Menge 0x27 an — inklusive RC4 und sogar den DES-Bits.

Der zweite Schnitt ist der, der 2026 für Unruhe gesorgt hat. Er hängt an CVE-2026-20833 und läuft in drei Stufen: Ab Januar 2026 protokollieren aktualisierte Domänencontroller nur, ab April 2026 setzen sie durch, und ab Juli 2026 ist der Rücknahmeschalter entfernt. Wir schreiben September 2026 — die Stufen sind also sämtlich hinter uns. Wer jetzt noch Konten betreibt, für die RC4 stillschweigend angenommen wurde, betreibt sie nicht mehr, sondern sucht gerade nach der Ursache.

WICHTIG Der Rückwärtsgang wurde ausgebaut Bis Juli 2026 ließ sich das neue Verhalten über den Registrierungswert RC4DefaultDisablementPhase (unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters) auf Audit zurückstellen. Dieser Schalter wird von aktuellen Domänencontrollern nicht mehr gelesen. Was bleibt, ist die Steuerung über die Konten selbst — und, als ausdrücklich als letztes Mittel gekennzeichneter Notausgang, ein domänenweiter Wert 0x24 in DefaultDomainSupportedEncTypes. Der macht allerdings genau das wieder auf, was die Änderung schließen sollte, und zwar für jedes Konto der Domäne gleichzeitig. Übersetzt: Die Umstellung ist keine Frage mehr, sondern ein Zustand. Die einzige Entscheidung, die noch offensteht, ist, ob man sie geordnet nachvollzieht oder störungsgetrieben.

 

Ist-Aufnahme: messen statt schätzen

Der häufigste Fehler zu Beginn eines solchen Vorhabens ist die Annahme, man wisse schon ungefähr, wo RC4 noch benutzt wird. Diese Annahme ist in jeder Umgebung falsch, die älter als fünf Jahre ist, und sie ist meistens in beide Richtungen falsch: Man vermutet Probleme bei Systemen, die längst sauber sind, und übersieht ein Konto, das seit 2013 unbeachtet einen Nachtlauf betreibt. Deshalb steht am Anfang keine Änderung, sondern eine Messung.

Die Ereignisse 4768 und 4769 richtig lesen

Die Domänencontroller protokollieren jede Ticketausstellung — sofern die Überwachungsrichtlinien für „Kerberos-Authentifizierungsdienst“ und „Kerberos-Diensttickets“ aktiv sind, was in vielen Umgebungen zumindest für die Erfolgsereignisse der Fall ist. Das Ereignis 4768 steht für die Ausstellung eines TGT, das Ereignis 4769 für ein Service-Ticket. Beide tragen ein Feld „Verschlüsselungstyp des Tickets“, und genau dieses Feld ist die Ist-Aufnahme.

Verschlüsselungstypen in den Ereignissen 4768 und 4769

Wert im Ereignis	Verfahren	Bewertung
0x1	DES-CBC-CRC	Sollte nicht mehr vorkommen; aus Kerberos entfernt
0x3	DES-CBC-MD5	Sollte nicht mehr vorkommen; aus Kerberos entfernt
0x11	AES128-CTS-HMAC-SHA1-96	In Ordnung
0x12	AES256-CTS-HMAC-SHA1-96	Das Ziel
0x13	AES128-CTS-HMAC-SHA256-128	Neu ab Windows Server 2025
0x14	AES256-CTS-HMAC-SHA384-192	Neu ab Windows Server 2025
0x17	RC4-HMAC	Das, wonach Sie suchen
0x18	RC4-HMAC-EXP	Exportvariante; historisch, aber gelegentlich noch da
0xFFFFFFFF	kein Typ ausgehandelt	Fehlerfall, meist Vorauthentifizierung

 

WARNUNG 0x18 heißt hier nicht dasselbe wie dort Der Wert 0x18 ist doppelt belegt und sorgt zuverlässig für Verwirrung. Im Attribut msDS-SupportedEncryptionTypes bedeutet 0x18 die Bitkombination AES128 plus AES256 — also genau das, was man haben will. Im Feld „Verschlüsselungstyp des Tickets“ eines Ereignisses 4769 bedeutet 0x18 dagegen RC4-HMAC-EXP, also genau das, was man loswerden will. Das eine ist eine Bitmaske, das andere eine Nummer aus der Kerberos-Typenliste. Wer beides in derselben Auswertung nebeneinander stellt, sollte die Spalten sehr deutlich beschriften — sonst meldet der Bericht Vollzug, während die Hälfte der Umgebung noch auf RC4 läuft.

 

Die neuen Felder, die das Rätselraten beenden

Ältere Windows-Versionen verrieten im Ereignis nur, womit das Ticket verschlüsselt wurde. Das beantwortet die entscheidende Frage aber gerade nicht: Ein Konto kann heute RC4-Tickets bekommen, weil es nur RC4 kann — oder weil ihm bisher niemand etwas anderes erlaubt hat. Der Unterschied entscheidet über den Aufwand.

Aktuelle Windows-Versionen ergänzen die Ereignisse 4768 und 4769 deshalb um drei Felder, die genau diese Unterscheidung erlauben. Sie sind die wertvollste Neuerung der ganzen Umstellung, und sie werden erstaunlich selten benutzt.

Zusätzliche Felder in 4768 und 4769

Feld	Was es zeigt	Wofür man es braucht
msds-SupportedEncryptionTypes	Die Bitmaske, die am Konto konfiguriert ist	Zeigt, ob überhaupt jemand etwas gesetzt hat — oder ob der Standard greift
Available Keys	Die Schlüsseltypen, die für das Konto tatsächlich existieren	Beantwortet die Kernfrage: Gibt es einen AES-Schlüssel oder nur RC4?
Session Encryption Type	Das Verfahren des Sitzungsschlüssels in diesem Vorgang	Trennt die Verschlüsselung des Tickets von der des Sitzungsschlüssels

 

Die Spalte „Available Keys“ ist die, wegen der sich das Aktualisieren der Domänencontroller lohnt, bevor man mit der Härtung anfängt. Sie beantwortet ohne Umweg über Vermutungen, welche Konten den Kennwort-Reset zwingend brauchen. Ohne dieses Feld bleibt nur der indirekte Schluss über das Datum des letzten Kennwortwechsels — und der ist schon deshalb unzuverlässig, weil ein Kennwortwechsel, der vor der Anhebung der Domänenfunktionsebene lag, keine AES-Schlüssel erzeugt hat.

Auswertung, die man am Montag zeigen kann

Für die erste Runde reicht Bordmittel. Der folgende Aufruf zieht die Service-Tickets der letzten Woche und gruppiert die RC4-Fälle nach Zielkonto — das ist die Liste, mit der man arbeitet.

Welche Dienstkonten bekommen noch RC4-Service-Tickets? $von = (Get-Date).AddDays(-7)   Get-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 4769 StartTime = $von } | ForEach-Object { $x = ([xml]$_.ToXml()).Event.EventData.Data [pscustomobject]@{ Dienst = ($x | Where-Object Name -eq 'ServiceName').'#text' Client = ($x | Where-Object Name -eq 'TargetUserName').'#text' EncType = ($x | Where-Object Name -eq 'TicketEncryptionType').'#text' } } | Where-Object { $_.EncType -in '0x17', '0x18' } | Group-Object Dienst | Sort-Object Count -Descending | Select-Object Count, Name

 

Zwei Hinweise, die einen halben Tag sparen: Erstens muss das auf jedem Domänencontroller laufen, nicht nur auf dem, an dem man gerade angemeldet ist — Kerberos verteilt sich, und der eine Nachtlauf spricht ausgerechnet mit dem Domänencontroller im Zweigstellenrechenzentrum. Zweitens ist eine Woche das absolute Minimum. Alles, was monatlich läuft, taucht darin nicht auf. Wer die Umstellung ernst meint, sammelt einen vollen Monat, idealerweise über den Monatsabschluss hinweg, und schaut anschließend noch einmal ausdrücklich nach Quartalsläufen.

Für die Bestandsseite — welches Konto trägt welches Attribut, und wann wurde zuletzt das Kennwort gewechselt — genügt eine Verzeichnisabfrage. Die Sortierung nach dem Kennwortdatum ist dabei nicht Kosmetik, sondern die eigentliche Risikoliste.

Dienstkonten mit SPN, Attributwert und Alter des Kennworts Get-ADUser -Filter 'servicePrincipalName -like "*"' ` -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, servicePrincipalName | Select-Object Name, @{ n = 'EncTypes'; e = { $v = $_.'msDS-SupportedEncryptionTypes' if ($null -eq $v -or $v -eq 0) { '<nicht gesetzt>' } else { '0x{0:X}' -f $v } } }, PasswordLastSet, @{ n = 'SPNs'; e = { $_.servicePrincipalName -join '; ' } } | Sort-Object PasswordLastSet

 

TIPP Microsoft liefert die Auswertung inzwischen mit Im Projekt microsoft/Kerberos-Crypto auf GitHub stehen zwei Skripte, die genau diese Arbeit abnehmen: List-AccountKeys.ps1 wertet die Ereignisse 4768 und 4769 aus und listet die Konten, für die keine AES-Schlüssel zu sehen sind. Get-KerbEncryptionUsage.ps1 erzeugt einen Bericht auf Anfrageebene, in dem sowohl die Ticket- als auch die Sitzungsverschlüsselung je Vorgang stehen. Dazu gibt es einen EType-Rechner als Webseite, mit dem sich Bitmasken hin und her übersetzen lassen. Das klingt nach einer Spielerei, verhindert aber genau die Sorte Zahlendreher, die eine Änderung im Verzeichnis unangenehm macht. Der Vorteil gegenüber selbst gebauten Abfragen liegt weniger in der Technik als in der Diskussion: Ein Bericht, der von Microsoft stammt, muss in der Runde mit der Anwendungsbetreuung nicht mehr verteidigt werden.

 

Die Ereignisse 201 bis 209 im Systemprotokoll

Neben den Sicherheitsereignissen protokolliert der Domänencontroller seit Januar 2026 eine eigene Reihe unter der Quelle KDCSVC — und zwar im Systemprotokoll, nicht im Sicherheitsprotokoll. Diese Ereignisse sind gezielt auf die Umstellung zugeschnitten: Sie melden nicht, was passiert ist, sondern was ohne Eingriff demnächst nicht mehr passieren wird. In der Audit-Phase erschienen sie als Warnungen; in der Durchsetzung sind aus denselben Sachverhalten Fehler geworden.

KDCSVC-Ereignisse zur RC4-Umstellung (Systemprotokoll)

ID	Art	Auslöser	Was zu tun ist
201	Warnung	Der anfragende Client bietet nur RC4 an, und am Dienstkonto ist kein msDS-SupportedEncryptionTypes gesetzt	Client oder Keytab auf AES bringen
202	Warnung	Das Dienstkonto hat keine AES-Schlüssel und keine ausdrückliche Konfiguration	Kennwort des Dienstkontos zurücksetzen
203	Fehler	Wie 201, aber in der Durchsetzung — die Anfrage wird abgewiesen	Sofortmaßnahme am Client beziehungsweise an der Keytab
204	Fehler	Wie 202, aber in der Durchsetzung — kein Ticket mehr	Kennwort-Reset, danach erneut prüfen
205	Warnung	DefaultDomainSupportedEncTypes ist ausdrücklich auf einen Wert gesetzt, der schwache Verfahren erlaubt	Domänenweite Ausnahme abbauen; wird nie zum Fehler hochgestuft
206	Warnung	Nur-RC4-Client trifft auf ein Dienstkonto, das ausdrücklich auf AES-SHA1 gestellt ist	Client ertüchtigen oder befristete Ausnahme am Konto
207	Warnung	Dienstkonto ohne AES-Schlüssel, obwohl auf AES-SHA1 gestellt	Der Klassiker aus Abschnitt vier: Kennwort-Reset
208	Fehler	Wie 206 in der Durchsetzung	Abgewiesen; Ursache am Client
209	Fehler	Wie 207 in der Durchsetzung	Abgewiesen; Ursache im Konto

 

WARNUNG Stille ist kein Nachweis Microsoft weist ausdrücklich darauf hin, dass das Ausbleiben dieser Ereignisse nicht garantiert, dass alle Geräte weiterhin funktionieren. Der Grund ist naheliegend: Der Domänencontroller sieht nur, was ihn erreicht. Ein Gerät, das seine Kerberos-Anfrage gar nicht erst stellt, weil es an einer vorgelagerten Aushandlung scheitert, hinterlässt am Domänencontroller keine Spur. Betroffen sind vor allem Nicht-Windows-Systeme mit Keytab-Dateien. Deren Inhalt kennt nur, wer die Datei aufmacht. Ein sauberes Protokoll ersetzt die Rückfrage beim Hersteller also nicht — es reduziert nur die Zahl der Rückfragen.

 

msDS-SupportedEncryptionTypes: die Bitmaske ohne Aberglauben

Um dieses Attribut ranken sich in Foren mehr Halbwahrheiten als um jeden anderen Wert im Verzeichnis. Dabei ist es schlicht eine 32-Bit-Zahl, in der jedes Bit für ein Verfahren oder ein Merkmal steht. Wer die untersten acht Bits kennt, kennt praktisch alles, was im Alltag vorkommt.

Skizze 2: Die relevanten Bits des Attributs und die drei Werte, die in jedem Projekt auftauchen.

Die Wertetabelle

Bitwerte des Attributs msDS-SupportedEncryptionTypes

Bit	Hex	Dezimal	Verfahren beziehungsweise Merkmal	Einschätzung
0	0x00000001	1	DES-CBC-CRC	Aus Kerberos entfernt; nur noch historischer Ballast
1	0x00000002	2	DES-CBC-MD5	Ebenfalls entfernt
2	0x00000004	4	RC4-HMAC	Das Bit, um das es in diesem Beitrag geht
3	0x00000008	8	AES128-CTS-HMAC-SHA1-96	Verfügbar seit 2008
4	0x00000010	16	AES256-CTS-HMAC-SHA1-96	Verfügbar seit 2008; der Regelfall
5	0x00000020	32	AES256-CTS-HMAC-SHA1-96-SK	Erzwingt AES-Sitzungsschlüssel, auch wenn RC4 im Spiel ist
6	0x00000040	64	AES128-CTS-HMAC-SHA256-128	AES-SHA2 nach RFC 8009; ab Windows Server 2025
7	0x00000080	128	AES256-CTS-HMAC-SHA384-192	AES-SHA2 nach RFC 8009; ab Windows Server 2025
16	0x00010000	65536	FAST wird unterstützt	Kein Verschlüsselungsverfahren, sondern ein Merkmal
17	0x00020000	131072	Zusammengesetzte Identität	Für Anspruchsauswertung und Zugriffssteuerung
18	0x00040000	262144	Ansprüche werden unterstützt	Gehört zu dynamischer Zugriffssteuerung
19	0x00080000	524288	SID-Komprimierung abgeschaltet	Notwendig für manche Nicht-Windows-Dienste

 

Wichtig an dieser Tabelle ist die Trennlinie zwischen den unteren acht und den oberen vier Einträgen. Die unteren acht sind Verschlüsselungsverfahren; sie beantworten die Frage „womit darf verschlüsselt werden“. Die oberen vier sind Merkmalsbits; sie beantworten ganz andere Fragen und haben mit der RC4-Umstellung nichts zu tun. Wer beim Setzen des Attributs die Merkmalsbits versehentlich überschreibt, schaltet unter Umständen die zusammengesetzte Identität ab — und sucht die Ursache dann in einer völlig anderen Ecke.

Die Kombinationen, die im Alltag vorkommen

Gebräuchliche Kombinationen und ihre Bedeutung

Wert	Dezimal	Enthält	Wann sinnvoll
0x18	24	AES128 + AES256	Der Zielwert. Auf diesen Wert läuft die gesamte Umstellung hinaus.
0x1C	28	RC4 + AES128 + AES256	Übergangswert. AES wird bevorzugt, RC4 bleibt als Netz. Gut für eine Migrationswoche, schlecht als Dauerzustand.
0x1F	31	DES + RC4 + AES128 + AES256	Kommt aus alten Anleitungen. Die DES-Bits sind wirkungslos, machen aber jede Auswertung unübersichtlich.
0x24	36	RC4 + AES256-SK	Der ausdrücklich als letztes Mittel bezeichnete Rückfallwert. Sitzungsschlüssel werden AES, das Ticket selbst darf RC4 bleiben.
0x38	56	AES128 + AES256 + AES256-SK	Wie 0x18, zusätzlich mit erzwungenen AES-Sitzungsschlüsseln.
0x3C	60	RC4 + AES128 + AES256 + AES256-SK	Der Wert aus vielen Anleitungen von 2022. Sicherer als der damalige Standard, aber heute zu großzügig.

 

Wo überall an derselben Schraube gedreht wird

Der zweite große Grund für Verwirrung ist, dass es nicht eine Stelle gibt, an der Verschlüsselungstypen konfiguriert werden, sondern fünf. Sie wirken auf unterschiedlichen Ebenen, sie haben eine klare Rangfolge, und sie werden in der Praxis regelmäßig verwechselt — meistens, weil jemand eine Gruppenrichtlinie setzt und sich wundert, dass sich am Verhalten der Domänencontroller nichts ändert.

Fünf Stellen, die auf dasselbe Thema wirken

Stellschraube	Wo	Wirkt auf	Rang
msDS-SupportedEncryptionTypes	Attribut am jeweiligen Konto im Verzeichnis	Genau dieses eine Konto	Höchster. Schlägt alles darunter.
DefaultDomainSupportedEncTypes	Registrierung am Domänencontroller unter HKLM\SYSTEM\CurrentControlSet\Services\KDC	Alle Konten ohne eigenes Attribut	Greift nur, wenn das Attribut leer oder 0 ist
Eingebauter Standard des KDC	Fest im Betriebssystem	Alles, wo weder Attribut noch Registrierungswert gesetzt sind	Seit April 2026 AES-SHA1 statt RC4
Netzwerksicherheit: Zulässige Verschlüsselungstypen für Kerberos	Gruppenrichtlinie, Sicherheitsoptionen	Den Kerberos-Client des jeweiligen Computers	Steuert, was ein Rechner anbietet — nicht, was das KDC ausstellt
Vertrauensobjekt	Attribut am Objekt der Vertrauensstellung	Den Verkehr über genau diese Vertrauensstellung	Eigene Welt; wird bei Inventuren regelmäßig übersehen

 

Die vierte Zeile ist die, an der die meisten Projekte Zeit verlieren. Die Gruppenrichtlinie „Netzwerksicherheit: Zulässige Verschlüsselungstypen für Kerberos“ steuert den Client eines Computers und schreibt in dessen Registrierung den Wert SupportedEncryptionTypes. Sie legt fest, was dieser Rechner in einer Anfrage anbietet und annimmt. Sie legt nicht fest, womit der Domänencontroller ein Ticket für ein Dienstkonto verschlüsselt — das entscheidet allein das Zielkonto. Wer die Richtlinie auf die Domänencontroller anwendet, ändert deren Verhalten als Client, nicht als KDC. Diese Unterscheidung klingt akademisch und ist der Grund für mindestens jede dritte ergebnislose Fehlersuche in diesem Themenfeld.

Skizze 3: Die Rangfolge, in der das KDC den Verschlüsselungstyp bestimmt — und die Schnittmenge am Ende, die leer sein kann.

FAKTEN Warum ein Wert von 0 nicht „nichts“ bedeutet Ein Attribut, das nicht gesetzt oder auf 0 gesetzt ist, bedeutet nicht „keine Verfahren erlaubt“. Es bedeutet „keine Angabe — frag eine Ebene tiefer“. Genau diese Ebene hat Microsoft im April 2026 umgestellt. Praktisch heißt das: Der Unterschied zwischen einem leeren Attribut und dem Wert 0x18 ist nicht kosmetisch. Beim leeren Attribut hängt das Verhalten davon ab, was in der Registrierung des jeweiligen Domänencontrollers steht — und das kann von Domänencontroller zu Domänencontroller abweichen, wenn jemand vor Jahren einen Wert gesetzt und die Dokumentation vergessen hat. Ein ausdrücklich gesetzter Wert am Konto ist deshalb nicht nur sicherer, sondern vor allem vorhersagbar. Vorhersagbarkeit ist in der Fehlersuche mehr wert als jedes zusätzliche Bit.

 

Der Kennwort-Reset ist keine Kür, sondern die Voraussetzung

Wenn Sie aus diesem Beitrag nur einen Absatz mitnehmen, dann diesen. Das Attribut msDS-SupportedEncryptionTypes ist eine Erlaubnis. Es sagt aus, welche Verfahren für dieses Konto benutzt werden dürfen. Es erzeugt keine Schlüssel. Die AES-Langzeitschlüssel eines Kontos entstehen ausschließlich dann, wenn das Kennwort dieses Kontos gesetzt wird — beim Anlegen, beim Zurücksetzen oder beim regulären Wechsel. Vorher existieren sie nicht, egal wie eindeutig das Attribut formuliert ist.

Skizze 4: Zwei Konten mit demselben Attribut und entgegengesetztem Verhalten. Der Unterschied ist ein einziger Kennwortwechsel.

WARNUNG Der Klassiker: AES aktiviert, Kennwort nie neu gesetzt — Konto authentifiziert nicht mehr Ausgangslage: Ein Dienstkonto aus dem Jahr 2011, Häkchen „Kennwort läuft nie ab“, Kennwort seither unverändert. Im Rahmen der Härtung setzt ein Skript msDS-SupportedEncryptionTypes auf 0x18. Die Änderung wird ohne Fehler geschrieben, das Verzeichnis repliziert sie, alles sieht gut aus. Was tatsächlich passiert ist: Das Konto besitzt weiterhin ausschließlich einen RC4-Langzeitschlüssel. AES128 und AES256 sind erlaubt, aber nicht vorhanden. Der Domänencontroller bildet die Schnittmenge aus „erlaubt“ und „vorhanden“ und erhält die leere Menge. Ergebnis: KDC_ERR_ETYPE_NOTSUPP. Kein Ticket, keine Anmeldung. Der Dienst startet unter Umständen sogar noch, weil er sein Kennwort lokal gespeichert hat — er bekommt nur von niemandem mehr eine Antwort. Beim nächsten Neustart ist auch das vorbei. Die Heimtücke liegt im Zeitversatz. Zwischen der Attributänderung und dem ersten Ausfall können Stunden bis Tage liegen, weil noch gültige Tickets im Zwischenspeicher liegen. Bis der Zusammenhang gefunden ist, hat die Änderung längst die Freigabe passiert und gilt als erledigt. Die Reihenfolge lautet deshalb ausnahmslos: erst Kennwort zurücksetzen, dann Attribut setzen. Nicht umgekehrt, und schon gar nicht beides im selben Skript ohne Prüfung dazwischen.

 

Welche Konten sich selbst helfen und welche nicht

Nicht jedes Konto braucht Handarbeit. Die Kunst besteht darin, die Fälle zu trennen, die sich von allein erledigen, von denen, die einen Termin mit der Anwendungsbetreuung brauchen.

Wer braucht wirklich einen Kennwort-Reset?

Kontotyp	Wechselt das Kennwort von allein?	Was zu tun ist
Computerkonto	Ja, standardmäßig alle 30 Tage	In der Regel nichts. AES-Schlüssel sind vorhanden. Bei Zweifeln lässt sich der sichere Kanal gezielt erneuern.
Gruppenverwaltetes Dienstkonto (gMSA)	Ja, automatisch nach Intervall	Nichts. Genau dafür wurde diese Kontoart erfunden.
Klassisches Dienstkonto als Benutzerkonto	Nein, meist mit „Kennwort läuft nie ab“	Kennwort-Reset erforderlich, koordiniert mit dem Hinterlegen im Dienst
Konto mit Keytab-Datei	Nein	Kennwort-Reset und anschließend neue Keytab mit AES-Einträgen erzeugen und ausrollen
krbtgt	Nein	Nur relevant, wenn die Domäne sehr alt ist; Reset in zwei Durchgängen mit Wartezeit für die Replikation
Konto einer Vertrauensstellung	Bei Windows-Vertrauensstellungen regelmäßig, sonst nein	AES am Vertrauensobjekt aktivieren, dann Vertrauenskennwort neu setzen

 

Für die dritte Zeile — das klassische Dienstkonto — ist der Ablauf immer derselbe, und er hat einen kritischen Moment: Zwischen dem Zurücksetzen des Kennworts im Verzeichnis und dem Hinterlegen desselben Kennworts an jeder Stelle, an der der Dienst es benutzt, ist der Dienst nicht funktionsfähig. „Jede Stelle“ ist dabei die Falle. Ein Konto kann in einem Windows-Dienst, in einem Anwendungspool, in einer geplanten Aufgabe und in einer Verbindungszeichenfolge gleichzeitig hinterlegt sein — und alle vier müssen es erfahren.

Ablauf für ein einzelnes Dienstkonto — die Reihenfolge ist nicht verhandelbar # 1) Vorher festhalten, wie es aussieht Get-ADUser svc-archiv -Properties msDS-SupportedEncryptionTypes, PasswordLastSet | Format-List Name, msDS-SupportedEncryptionTypes, PasswordLastSet   # 2) Kennwort zurücksetzen – erst hierdurch entstehen die AES-Schlüssel $kennwort = Read-Host -AsSecureString 'Neues Kennwort aus dem Tresor' Set-ADAccountPassword -Identity svc-archiv -Reset -NewPassword $kennwort   # 3) Kennwort überall hinterlegen, Dienst neu starten, Funktion prüfen # (Dienst, Anwendungspool, geplante Aufgabe, Verbindungszeichenfolge)   # 4) Erst jetzt die Erlaubnis einschränken Set-ADUser -Identity svc-archiv -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }   # 5) Kontrolle: welcher Typ wird jetzt tatsächlich ausgestellt? klist purge klist get HTTP/archiv.example.internal

 

Der Schritt fünf ist der, den man nicht auslassen sollte. `klist get` fordert gezielt ein Service-Ticket an und zeigt anschließend den ausgehandelten Verschlüsselungstyp an. Das ist die einzige Prüfung, die tatsächlich beweist, dass es funktioniert — im Gegensatz zu „der Dienst läuft noch“, was nach einer Attributänderung ungefähr so aussagekräftig ist wie ein Blick auf eine Uhr, die stehen geblieben ist.

TIPP Computerkonten muss man nicht anfassen — meistens Computerkonten wechseln ihr Kennwort standardmäßig alle dreißig Tage selbstständig und verfügen dadurch über aktuelle AES-Schlüssel. Der Sonderfall sind Rechner, die monatelang ausgeschaltet oder abgeklemmt waren, sowie Systeme, bei denen jemand den automatischen Wechsel bewusst deaktiviert hat — was in Prüflaboren und bei Steuerungsrechnern häufiger vorkommt, als einem lieb ist. Für einen einzelnen Verdachtsfall genügt auf dem betroffenen Rechner ein Test-ComputerSecureChannel -Repair oder ein nltest /sc_change_pwd, um das Kennwort und damit die Schlüssel zu erneuern. Beides braucht eine funktionierende Verbindung zu einem Domänencontroller — was in genau den Fällen, in denen man es braucht, gern die eigentliche Hürde ist.

 

Die Reihenfolge: Konten, dann Richtlinie, dann Kontrolle

Alles Bisherige läuft auf eine einzige organisatorische Erkenntnis hinaus: Die technische Zielkonfiguration ist trivial und in zehn Minuten beschrieben. Was darüber entscheidet, ob die Umstellung eine ruhige Woche oder eine unruhige Nacht wird, ist ausschließlich die Reihenfolge.

Skizze 5: Dieselbe Zielkonfiguration, zwei sehr verschiedene Wochen.

Schritt für Schritt

Der Ablauf, der sich in der Praxis bewährt hat, besteht aus fünf Etappen. Vier davon sind langweilig, und das ist Absicht.

Erstens messen. Mindestens vier Wochen Ereignisse 4768 und 4769 von allen Domänencontrollern, ausgewertet nach Verschlüsselungstyp und Zielkonto. Parallel dazu die Bestandsliste aus dem Verzeichnis: welches Konto hat welches Attribut, wann wurde das Kennwort zuletzt gesetzt. Ergebnis ist eine Liste konkreter Konten, keine Schätzung.

Zweitens Schlüssel erzeugen. Für jedes Konto auf der Liste einen Kennwort-Reset einplanen, mit der Anwendungsbetreuung terminiert und mit einem Weg zurück. Computerkonten und gruppenverwaltete Dienstkonten kann man dabei überspringen. Diese Etappe ist die aufwendigste und die, die niemand abkürzen kann.

Drittens Erlaubnis setzen. Erst jetzt bekommt jedes einzelne Konto sein msDS-SupportedEncryptionTypes auf 0x18 — kontoweise oder in kleinen, geprüften Gruppen, nicht per Sammelbefehl über eine Organisationseinheit mit zwölfhundert Objekten.

Viertens kontrollieren. Erneut messen. Erst wenn über einen vollen Zyklus hinweg ausschließlich 0x11, 0x12 oder die AES-SHA2-Werte in den Ereignissen auftauchen, ist die Kontoebene erledigt.

Fünftens die Domänenebene aufräumen. Wenn irgendwo noch ein großzügiger DefaultDomainSupportedEncTypes steht — etwa 0x3C aus einer Anleitung von 2022 — wird er jetzt entfernt oder auf 0x18 gesetzt. Auf allen Domänencontrollern, mit Neustart, und mit einer Notiz, wer ihn wann warum gesetzt hat.

Der fünfte Punkt ist der, der gern liegen bleibt, weil zu diesem Zeitpunkt alles funktioniert und niemand mehr Lust auf Domänencontroller-Neustarts hat. Er ist trotzdem wichtig: Solange ein domänenweiter Wert RC4 zulässt, hat jedes neu angelegte Konto ohne Attribut wieder die alte, großzügige Annahme — und die Aufräumarbeit beginnt in zwei Jahren von vorn.

Vertrauensstellungen: der Sonderfall, den man vergisst

Vertrauensstellungen folgen eigenen Regeln, tauchen in keiner Konteninventur auf und melden sich erst dann, wenn jemand tatsächlich über sie hinweg arbeiten will. Das ist typischerweise nicht der Tag der Umstellung, sondern der Montag darauf.

Technisch gibt es zwei Stellschrauben. Die eine ist das Attribut am Objekt der Vertrauensstellung, das dieselbe Bitmaske trägt wie ein Konto; bei Gesamtstruktur-Vertrauensstellungen entspricht das dem Kontrollkästchen „Die andere Domäne unterstützt Kerberos-AES-Verschlüsselung“ in den Eigenschaften. Die andere ist das Vertrauenskennwort selbst — und für das gilt exakt dieselbe Regel wie für jedes andere Konto: Ohne Neusetzen keine AES-Schlüssel.

Vertrauensstellungen: Attribut setzen und Kennwort erneuern # Verschlüsselungstypen am Vertrauensobjekt anzeigen und setzen Get-ADObject -Filter { ObjectClass -eq 'trustedDomain' } ` -Properties msDS-SupportedEncryptionTypes, trustPartner | Select-Object trustPartner, msDS-SupportedEncryptionTypes   ksetup /setenctypeattr partner.example.internal AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96   # Danach das Vertrauenskennwort neu setzen – erst dann existieren AES-Schlüssel netdom trust example.internal /Domain:partner.example.internal /Reset /PasswordT:* /UserO:…

 

WARNUNG Vertrauensstellungen haben zwei Seiten und einen gemeinsamen Ausfall Eine Vertrauensstellung wird auf beiden Seiten gepflegt. Wer nur die eigene Seite auf AES stellt und die Gegenseite nicht einbezieht, erzeugt eine Konstellation, in der die eine Richtung funktioniert und die andere nicht. Das Fehlerbild wirkt zunächst sprunghaft und kostet erfahrungsgemäß einen ganzen Tag, bis jemand auf die Idee kommt, die Richtung systematisch zu prüfen. Bei Vertrauensstellungen zu Fremdsystemen — etwa in eine MIT-Kerberos-Umgebung — kommt hinzu, dass die Gegenseite eigene Vorstellungen von unterstützten Verfahren hat und diese nicht unbedingt im Verzeichnis dokumentiert. Hier hilft nur ein abgestimmtes Wartungsfenster mit beiden Betriebsmannschaften. Praktischer Rat: Vertrauensstellungen kommen früh in die Bestandsaufnahme und spät in die Umsetzung. Früh, weil die Abstimmung mit der Gegenseite Vorlauf braucht. Spät, weil ein Fehler hier zwei Organisationen betrifft.

 

Wenn es doch geknallt hat

Für den Fall, dass die Reihenfolge in der Praxis eine andere war als die empfohlene — was vorkommt, und zwar nicht selten —, hier die Sofortmaßnahmen in der Reihenfolge, in der man sie ausprobiert.

Sofortmaßnahmen nach einem Fehlstart

Situation	Sofortmaßnahme	Danach
Ein Konto authentifiziert nicht mehr, Attribut wurde gerade gesetzt	Attribut am Konto auf 0x1C setzen — RC4 wieder erlaubt, AES bevorzugt	Kennwort zurücksetzen, dann zurück auf 0x18
Mehrere Konten betroffen, Ursache unklar	Betroffene Attributänderungen zurücknehmen, nicht domänenweit eingreifen	Ereignisse 4769 und KDCSVC auswerten, Liste erstellen
Ein Gerät ohne AES-Fähigkeit blockiert	Am zugehörigen Konto RC4 ausdrücklich erlauben (0x1C), befristet	Ablaufdatum in der Dokumentation, Hersteller anschreiben
Vertrauensstellung ausgefallen	Attribut am Vertrauensobjekt zurücknehmen, Gegenseite informieren	Gemeinsames Fenster für Kennwort und Attribut vereinbaren
Breitflächiger Ausfall, Ursache im Domänenstandard	DefaultDomainSupportedEncTypes auf 0x24 — ausdrücklich letztes Mittel	Umgehend kontoweise nacharbeiten, Wert schnellstmöglich wieder entfernen

 

Die letzte Zeile verdient eine Bemerkung. Der Wert 0x24 in DefaultDomainSupportedEncTypes ist die einzige verbliebene domänenweite Rückfallebene — und Microsoft bezeichnet ihn ausdrücklich als letztes Mittel, weil er sämtliche Konten der Domäne wieder angreifbar macht. Er ist eine Feuerlöschmaßnahme, kein Betriebszustand. Wer ihn setzt, sollte im selben Atemzug den Termin für seine Entfernung eintragen, sonst steht er in drei Jahren noch da und niemand weiß mehr, warum.

Häufige Fragen

Was bedeutet KDC_ERR_ETYPE_NOTSUPP genau?

Der Fehler mit dem Zahlenwert 14 beziehungsweise 0x0E besagt: Der Domänencontroller konnte keinen Verschlüsselungstyp finden, der gleichzeitig erlaubt, vorhanden und vom anfragenden Client unterstützt ist. Er ist eine Aussage über eine leere Schnittmenge, nicht über einen Defekt. In der Praxis gibt es drei Ursachen: Das Zielkonto besitzt keinen Schlüssel des erlaubten Typs — das ist der häufigste Fall und fast immer ein fehlender Kennwort-Reset. Oder der Client bietet nur Verfahren an, die am Ziel nicht erlaubt sind, typischerweise ein Gerät mit RC4-only-Keytab. Oder jemand hat das Attribut auf einen Wert gesetzt, der gar kein Verschlüsselungsbit enthält, etwa weil beim Rechnen mit Merkmalsbits die unteren acht Bits verloren gingen.

Ich habe das Attribut auf 0x18 gesetzt und jetzt geht nichts mehr. Was tun?

Als Sofortmaßnahme das Attribut auf 0x1C setzen. Damit ist RC4 wieder erlaubt, AES bleibt bevorzugt, und der Dienst arbeitet in aller Regel binnen Minuten wieder — gegebenenfalls nach einem `klist purge` auf der Clientseite, weil gescheiterte Aushandlungen kurz zwischengespeichert werden. Anschließend das Kennwort des Kontos zurücksetzen und überall hinterlegen. Erst wenn eine Prüfung mit `klist get` bestätigt, dass tatsächlich ein AES-Ticket ausgestellt wird, geht man wieder auf 0x18. Diese Schleife dauert eine halbe Stunde und ist deutlich angenehmer als die Alternative, nämlich unter Druck an fünf Stellen gleichzeitig zu ändern.

Woran erkenne ich, ob ein Konto überhaupt AES-Schlüssel besitzt?

Am zuverlässigsten am Feld „Available Keys“ in den Ereignissen 4768 und 4769 aktueller Domänencontroller; genau dafür wurde es ergänzt. Wo dieses Feld noch nicht zur Verfügung steht, bleibt der indirekte Weg über PasswordLastSet: Liegt der letzte Kennwortwechsel vor der Anhebung der Domänenfunktionsebene auf Windows Server 2008 oder höher, existieren mit Sicherheit keine AES-Schlüssel. Liegt er danach, existieren sie höchstwahrscheinlich. Für den Zweifelsfall gilt der pragmatische Grundsatz: Ein Kennwort-Reset schadet keinem Dienstkonto, dessen Kennwort ohnehin seit Jahren unverändert ist — er kostet nur ein Wartungsfenster.

Reicht es nicht, einfach die Gruppenrichtlinie für Verschlüsselungstypen zu setzen?

Nein, und diese Verwechslung ist die zweithäufigste Ursache für erfolglose Umstellungen. Die Richtlinie „Netzwerksicherheit: Zulässige Verschlüsselungstypen für Kerberos“ konfiguriert den Kerberos-Client eines Computers — sie legt fest, was dieser Rechner anbietet und akzeptiert. Womit ein Service-Ticket für ein Dienstkonto verschlüsselt wird, entscheidet dagegen ausschließlich die Konfiguration des Zielkontos. Beide Ebenen braucht man, aber die Richtlinie allein ändert an der Ausstellung nichts. Wer sie flächendeckend restriktiv ausrollt, ohne vorher die Konten in Ordnung zu bringen, erzeugt zusätzlich das umgekehrte Problem: Clients, die RC4 nicht mehr anbieten, treffen auf Dienste, die nur RC4 können.

Was ist mit dem Bit 0x20, dieser AES256-SK-Geschichte?

Das Bit 5 mit dem Wert 0x20 steht für AES256-CTS-HMAC-SHA1-96-SK und ist kein eigenständiges Verschlüsselungsverfahren, sondern eine Anweisung an das KDC: Überall dort, wo sonst ein RC4-Sitzungsschlüssel entstünde, soll stattdessen ein AES-Sitzungsschlüssel verwendet werden. Das ist ein Kompromiss für Umgebungen, in denen RC4 aus Kompatibilitätsgründen erlaubt bleiben muss: Der Langzeitschlüssel des Dienstkontos darf dann noch RC4 sein, der Sitzungsschlüssel aber nicht. Der bekannte Rückfallwert 0x24 setzt sich genau daraus zusammen, aus RC4 und diesem Bit. Als Dauerzustand ist das eine halbe Lösung, als Brücke über ein hartnäckiges Altsystem ist es besser als nacktes RC4.

Muss ich das krbtgt-Konto anfassen?

In den allermeisten Fällen nein. Das krbtgt-Konto bekommt seine AES-Schlüssel, sobald sein Kennwort auf einer Domäne mit ausreichender Funktionsebene gesetzt wurde — was bei jeder Domäne der Fall ist, die in den letzten Jahren einmal durchgereicht oder im Rahmen einer Sicherheitsmaßnahme zurückgesetzt wurde. Interessant wird es nur bei sehr alten Domänen, die seit der Anhebung der Funktionsebene nie ein krbtgt-Reset gesehen haben; dort können TGTs weiterhin mit RC4 verschlüsselt sein. Der Reset erfolgt dann in zwei Durchgängen mit vollständiger Replikation dazwischen — nicht zweimal hintereinander, das ist der Fehler, mit dem man eine Domäne über Nacht unbenutzbar macht.

Wie gehe ich mit einem Gerät um, das AES wirklich nicht kann?

Zuerst prüfen, ob die Behauptung stimmt. „Kann kein AES“ heißt in neun von zehn Fällen „hat eine Keytab von 2014“ oder „läuft mit einer Firmware, für die es seit vier Jahren einen Nachfolger gibt“. Erst wenn der Hersteller schriftlich bestätigt, dass AES nicht unterstützt wird, kommt die Ausnahme: RC4 ausdrücklich am zugehörigen Dienstkonto erlauben, also 0x1C oder besser 0x24, damit wenigstens der Sitzungsschlüssel AES ist. Diese Ausnahme gehört mit Ablaufdatum dokumentiert, das Konto in eine eigene Organisationseinheit, und das Kennwort auf eine Länge, bei der sich Kerberoasting nicht lohnt — vierzig Zeichen und mehr sind hier keine Übertreibung, sondern der eigentliche Schutz.

Die Ereignisse 201 bis 209 tauchen bei mir gar nicht auf. Ist alles in Ordnung?

Nicht zwingend. Erstens werden diese Ereignisse nur von Domänencontrollern protokolliert, die die entsprechenden Updates installiert haben — ein alter Domänencontroller schweigt einfach. Zweitens sieht das KDC nur Anfragen, die es auch erreichen; ein Gerät, das schon bei der Aushandlung scheitert, erzeugt dort keinen Eintrag. Microsoft weist ausdrücklich darauf hin, dass fehlende Ereignisse keine Garantie dafür sind, dass alle Nicht-Windows-Geräte weiterhin funktionieren. Das Systemprotokoll ist ein sehr gutes Frühwarnsystem und ein sehr schlechter Vollständigkeitsnachweis.

Sind AES-SHA2 und die neuen Bits 0x40 und 0x80 jetzt schon relevant?

Für die RC4-Abschaltung nicht. AES128-CTS-HMAC-SHA256-128 und AES256-CTS-HMAC-SHA384-192 nach RFC 8009 kommen mit Windows Server 2025 und entfalten ihren Nutzen erst in Umgebungen, in denen alle beteiligten Systeme sie beherrschen. Wer heute zwischen 0x18 und einem Wert mit AES-SHA2-Bits schwankt, löst ein Problem, das er noch nicht hat, und riskiert eines, das er nicht braucht. Der praktische Rat lautet: erst RC4 sauber loswerden, dann in einem eigenen Vorhaben auf AES-SHA2 schauen. Wer die Gruppenrichtlinie pflegt, lässt allerdings die Option „Zukünftige Verschlüsselungstypen“ aktiviert — sonst blockiert man sich den Weg dorthin unnötig.

Wie lange dauert so eine Umstellung realistisch?

Die reine Konfigurationsarbeit ist an einem Tag erledigt. Realistisch sind vier bis acht Wochen, und der Aufwand liegt fast vollständig in zwei Posten: der Messung über einen vollen Zyklus inklusive Monatsabschluss, und der Terminfindung für die Kennwort-Resets mit den jeweiligen Anwendungsbetreuungen. Wer diese beiden Posten streicht, kommt auf drei Tage — und danach auf eine Woche Störungsbetrieb. Das ist keine Schätzung aus dem Lehrbuch, sondern die Erfahrung aus Projekten, in denen genau diese Abkürzung genommen wurde.

Fazit

Die Abschaltung von RC4 ist technisch eine der einfachsten Härtungsmaßnahmen im Active Directory. Man setzt an ein paar hundert Objekten eine Zahl, entfernt vielleicht einen Registrierungswert, und fertig. Dass sie trotzdem regelmäßig schiefgeht, liegt nicht an der Technik, sondern daran, dass eine Erlaubnis mit einer Fähigkeit verwechselt wird. Das Attribut msDS-SupportedEncryptionTypes sagt, was ein Konto darf. Ob es das auch kann, entscheidet allein die Frage, ob sein Kennwort irgendwann einmal neu gesetzt wurde.

Daraus folgt die einzige Regel, die man sich merken muss: erst Schlüssel, dann Erlaubnis, dann Verbot, dann Kontrolle. Wer diese vier Schritte in dieser Reihenfolge geht, hat eine unspektakuläre Woche mit ein paar Wartungsfenstern. Wer bei Schritt drei anfängt, hat eine Nacht mit Rufbereitschaft und eine Ursachensuche, die rückwärts durch drei Tage Änderungsprotokoll führt — bis zu einer Änderung, die damals als „reine Attributpflege, kein Risiko“ freigegeben wurde.

Und noch etwas gehört zur ehrlichen Bilanz: Die Umstellung erzwingt eine Inventur, die in vielen Umgebungen überfällig ist. Am Ende steht nicht nur eine Domäne ohne RC4, sondern auch eine Liste von Dienstkonten mit bekannten Eigentümern, nachvollziehbaren Kennwortwechseln und dokumentierten Ausnahmen. Dieser Nebeneffekt ist in der Praxis oft wertvoller als der eigentliche Anlass — und er ist der einzige Teil des Vorhabens, den man auch dann behält, wenn Microsoft in fünf Jahren die nächste Chiffre für unzumutbar erklärt. Was übrigens keine Prophezeiung ist, sondern eine Erfahrungstatsache.

Quellen

Microsoft Support: How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 — https://support.microsoft.com/en-us/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc

Microsoft Windows Server Blog: Beyond RC4 for Windows authentication — https://www.microsoft.com/en-us/windows-server/blog/2025/12/03/beyond-rc4-for-windows-authentication/

Microsoft Learn, [MS-KILE] 2.2.7: Supported Encryption Types Bit Flags — https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919

Microsoft Learn, [MS-ADA2] 2.481: Attribut msDS-SupportedEncryptionTypes — https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/a75d1c3f-0bb3-470c-99bd-2bb557119483

Microsoft Support KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966 — https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d

Microsoft Learn: Network security — Configure encryption types allowed for Kerberos — https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos

GitHub microsoft/Kerberos-Crypto: Skripte List-AccountKeys.ps1 und Get-KerbEncryptionUsage.ps1 — https://github.com/microsoft/Kerberos-Crypto

Microsoft: Kerberos EType Calculator — https://microsoft.github.io/Kerberos-Crypto/pages/etype-calc.html

Microsoft Community Hub, Ask the Directory Services Team: What is going on with RC4 in Kerberos? — https://techcommunity.microsoft.com/blog/askds/what-is-going-on-with-rc4-in-kerberos/4489365

Microsoft Community Hub: Removal of DES in Kerberos for Windows Server and Client — https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/removal-of-des-in-kerberos-for-windows-server-and-client/4386903

RFC 8009: AES Encryption with HMAC-SHA2 for Kerberos 5 — https://www.rfc-editor.org/rfc/rfc8009

RFC 4757: The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows — https://www.rfc-editor.org/rfc/rfc4757

 

Weiterführend in dieser Serie: /microsoft-kerberos (Pillar-Seite zur gesamten Serie), /spns-richtig-setzen-setspn, /kerberos-tickets-tgt-und-service-ticket, /kerberos-delegierung-unconstrained-bis-rbcd.