Ein auf 0x18 gesetztes msDS-SupportedEncryptionTypes erzeugt keine AES-Schlüssel für ein Dienstkonto. Für die Diagnose vergleichst du das Angebot des Clients mit den vorhandenen Kontoschlüsseln und den Angaben zum ausgestellten Dienstticket. Die Anwendung muss dieses Ticket mit ihrem Schlüsselmaterial entschlüsseln können, etwa über eine dazu passende Keytab.
Eine pauschale Umstellung auf AES ist der falsche erste Reparaturschritt, weil ein Client ohne AES-Unterstützung eine andere Korrektur verlangt als ein Dienstkonto ohne AES-Schlüssel.
RC4-Hardening 2026: Updates und Konfiguration
Bei Konten ohne explizit gesetzte Verschlüsselungstypen wählt der KDC die Verfahren anhand seiner wirksamen Standardwerte aus. Nach einem Sicherheitsupdate kann sich diese Auswahl ändern. Eine geänderte Standardauswahl belegt allerdings nicht, dass der DC sämtliche RC4-Anforderungen ablehnt.
Für jeden beteiligten DC gehören folgende Angaben in die Diagnose:
- Der Betriebssystem-Build und das installierte kumulative Update
- Ein gegebenenfalls ausstehender Neustart
- Die wirksamen Kerberos-Gruppenrichtlinien auf dem Client und dem DC
- Vorhandene KDC-Vorgaben wie
DefaultDomainSupportedEncTypes
Get-HotFix zeigt Update-Einträge, erfasst aber nicht den vollständigen Wartungszustand eines Systems. Für den Abgleich werden deshalb auch der Betriebssystem-Build und die Daten aus dem Patch-Management benötigt.
Weiterführende Schulungen zur Administration der beteiligten Systeme findest du in der Kategorie Windows-Server-Trainings. Für die Ereignissuche muss zunächst feststehen, welchem Konto der angeforderte Dienstname zugeordnet ist.
Anwendung, Dienstkonto, SPN und Client zuordnen
Ein HTTP-Dienst kann unter einem Dienstbenutzerkonto laufen oder die Identität eines Computerkontos verwenden. Der KDC verschlüsselt das Dienstticket mit einem Schlüssel des Kontos, dem der angeforderte Service Principal Name (SPN) zugeordnet ist. Dieses Konto muss mit der Identität übereinstimmen, deren Schlüssel die Anwendung tatsächlich verwendet.
Für den beispielhaften SPN HTTP/app.example.net sucht die erste Abfrage forestweit nach der Registrierung. Die zweite Abfrage zeigt Attribute des beispielhaften Benutzerkontos svc_web und benötigt das PowerShell-Modul ActiveDirectory.
setspn.exe -F -Q HTTP/app.example.net
Get-ADUser -Identity svc_web -Properties ServicePrincipalName,
'msDS-SupportedEncryptionTypes', 'msDS-KeyVersionNumber', PasswordLastSet |
Select-Object SamAccountName, ServicePrincipalName,
'msDS-SupportedEncryptionTypes', 'msDS-KeyVersionNumber', PasswordLastSetFür ein Computerkonto liefert Get-ADComputer die entsprechenden Attribute, für ein gruppenverwaltetes Dienstkonto (gMSA) dient Get-ADServiceAccount. Weder das Datum der letzten Kennwortänderung noch die Schlüsselversionsnummer beweist, welche Verschlüsselungsschlüssel vorhanden sind.
Beim Attribut msDS-SupportedEncryptionTypes stehen die Bits 0x8 und 0x10 für AES128 beziehungsweise AES256 mit SHA1. Zusammen ergeben sie 0x18, dezimal 24. Der Attributwert beschreibt die konfigurierten Verfahren, nicht den tatsächlichen Schlüsselbestand.
Zur Zuordnung gehört außerdem, ob Windows die Dienstanmeldedaten verwaltet oder die Anwendung eine separat gepflegte Keytab lädt. Ein reproduzierbarer Zugriff mit Zeitstempel einschließlich Zeitzone, Client-Adresse und verwendetem Zielnamen liefert anschließend den Bezugspunkt für die Ereignissuche.
Security-Ereignisse und Kdcsvc-Meldungen korrelieren
Im Security-Ereignis 4768 protokolliert der DC die Anforderung eines Ticket Granting Tickets (TGT), in 4769 die Anforderung eines Diensttickets. Bei einem bereits zwischengespeicherten TGT entsteht zum Testzeitpunkt nicht zwangsläufig ein neues Ereignis 4768. Für die Aufzeichnung müssen die Audit-Unterkategorien für den Kerberos-Authentifizierungsdienst und die Kerberos-Dienstticketvorgänge mit den benötigten Erfolgs- beziehungsweise Fehlerereignissen aktiviert sein.
Die folgenden Abfragen begrenzen die Suche auf die letzten 15 Minuten. Sie benötigen Leserechte auf den jeweiligen Ereignisprotokollen; bei mehreren möglichen DCs werden die Protokolle aller infrage kommenden Systeme ausgewertet.
$since = (Get-Date).AddMinutes(-15)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4768, 4769
StartTime = $since
} | Select-Object TimeCreated, Id, Message
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
Id = 208, 209
StartTime = $since
} | Select-Object TimeCreated, ProviderName, Id, MessageDer Provider-Filter verhindert, dass gleich nummerierte Ereignisse anderer Quellen in die KDC-Auswertung geraten. Über den Zeitstempel, das Konto und die Client-Adresse lassen sich die Einträge dem Test zuordnen. Den konkret verwendeten SPN belegen zusätzlich der Ticketcache und die Angaben der Anwendung.
Konfigurierte Verfahren, vorhandene Schlüssel und Tickets unterscheiden
Die verfügbaren Ereignisfelder hängen von der Windows-Version und dem Update-Stand des DCs ab. Bei entsprechend erweiterten Ereignissen werden folgende Angaben getrennt ausgewertet:
- Unter Supported Encryption Types stehen die für das jeweils benannte Konto konfigurierten oder vom KDC angenommenen Verfahren
- Unter Client Advertized Encryption Types stehen die vom Client für die Anfrage angebotenen Verfahren
- Unter Available Keys führt der DC die vorhandenen Schlüssel des jeweils benannten Kontos auf
- Unter Ticket Encryption Type steht das Verfahren, mit dem der KDC das Ticket verschlüsselt hat
- Unter Session Encryption Type steht das Verfahren des Sitzungsschlüssels
Bei Ticket-Etypes bedeutet 0x11 AES128-SHA1, 0x12 AES256-SHA1 und 0x17 RC4-HMAC. Diese Werte sind keine Attribut-Bitmasken. Die Ticket-Verschlüsselung in 4768 betrifft das TGT und belegt nicht die Verschlüsselung des späteren Anwendungstickets.
Der Client entschlüsselt den für den Dienst bestimmten Ticketinhalt nicht selbst. Ein AES-verschlüsseltes Dienstticket beweist daher noch nicht, dass auch der Sitzungsschlüssel AES verwendet. Fehlt in einem Ereignis das Feld Available Keys, lässt sich daraus kein fehlender Schlüssel ableiten.
Was bedeutet Kdcsvc-Ereignis 209?
Fehlende AES-SHA1-Schlüssel an einem für AES konfigurierten Dienstkonto sind der Befund von Kdcsvc-Ereignis 209 auf entsprechend aktualisierten DCs. Kdcsvc-Ereignis 208 weist dagegen auf ein Client-Angebot ohne AES-SHA1 hin. Für die Auswertung sind jeweils der vollständige Meldungstext und der Update-Stand des ausgebenden DCs maßgeblich.
Die PowerShell-Abfragen lassen sich für wiederholte Tests um Filter für das betroffene Konto und das Zeitfenster ergänzen. Zum Schreiben solcher Auswertungen bietet die Kategorie PowerShell-Trainings weiterführende Schulungen. Mit den zugeordneten Ereignissen lassen sich anschließend die Fehler am Client, am Dienstkonto und an der Keytab unterscheiden.
Client-Limit, fehlende AES-Schlüssel oder unpassende Keytab?
Wenn der Client kein AES-SHA1 anbietet, behebt eine Kennwortänderung am Dienstkonto diesen Befund nicht. Zu untersuchen sind die wirksame Client-Richtlinie und die Kerberos-Implementierung der tatsächlich anfragenden Anwendung. Ein AES-fähiges Betriebssystem beweist noch keine AES-Unterstützung einer separat verwendeten Laufzeit.
Bei einem Benutzerkonto ohne AES-Schlüssel erzeugt ein AES-fähiger DC die entsprechenden Schlüssel im Zuge einer Kennwortänderung, sofern die Domäne AES unterstützt. Vorher müssen sämtliche Dienste bekannt sein, die dieselben Anmeldedaten verwenden. Für ein gMSA wird dagegen dessen verwalteter Kennwortmechanismus berücksichtigt, statt das Konto wie ein gewöhnliches Dienstbenutzerkonto zu behandeln.
Eine Anwendung kann trotz vorhandener AES-Kontoschlüssel eine Keytab laden, die nur RC4-Schlüssel enthält oder nicht mehr zum Kontokennwort passt. Mit MIT Kerberos zeigt klist -k -t -e /etc/security/app.keytab die enthaltenen Principals, Schlüsselversionen und Verschlüsselungsverfahren. Das ist ein MIT-Kerberos-Aufruf, nicht die Syntax des Windows-Werkzeugs klist.
| Befund | Ereignis oder Feld | Nächste Untersuchung |
|---|---|---|
| Der Client bietet kein AES-SHA1 an | Kdcsvc 208, angebotene Etypes | Welche Client-Richtlinie oder Laufzeit begrenzt das Angebot? |
| AES ist konfiguriert, die benötigten Kontoschlüssel fehlen | Kdcsvc 209, Available Keys des Dienstkontos | Welche Dienste und gespeicherten Anmeldedaten betrifft eine Kennwortänderung? |
| Der KDC stellt ein AES-Ticket aus, der Dienst lehnt es ab | 4769, Ticketcache und Anwendungsprotokoll | Stimmen die Dienstidentität, der Principal und das Schlüsselmaterial einschließlich Schlüsselversionsnummer überein? |
| Das Dienstticket verwendet weiterhin RC4 | 4769, Ticket Encryption Type 0x17 | Welche Kontoeinstellungen und KDC-Standardwerte gelten für das zum SPN gehörende Konto? |
Auch ohne KDC-Warnung kann die Anwendung ein ausgestelltes Ticket wegen einer unpassenden Keytab ablehnen. Deshalb umfasst der Pilot im nächsten Schritt sowohl die Korrektur als auch einen nachgewiesenen Kerberos-Zugriff auf den Dienst.
Den Pilotdienst korrigieren und die Anmeldung nachweisen
Zum Pilot gehören ein benannter Dienst, die dafür verantwortlichen Personen und sämtliche Anwendungen mit gemeinsam verwendeten Anmeldedaten. Bei fehlendem Client-Angebot wird die betroffene Richtlinie oder Laufzeit korrigiert. Bei fehlenden Kontoschlüsseln wird die Kennwortänderung mit allen betroffenen Diensten abgestimmt.
Nach einer Kennwortänderung müssen gespeicherte Dienstanmeldedaten und separat gepflegte Keytabs zum neuen Kontoschlüssel passen. Vor dem erneuten Test wird die AD-Replikation zwischen den beteiligten DCs berücksichtigt; die Anwendung muss außerdem die aktualisierte Keytab laden. Eine Datei mit AES-Einträgen genügt nicht, wenn die enthaltenen Schlüssel zu einer anderen Kontoversion gehören.
Ein erneuter Test benötigt ein frisch angefordertes Dienstticket. In einer isolierten Windows-Testsitzung zeigt die folgende Sequenz den Abruf für den Beispiel-SPN. klist purge entfernt alle Kerberos-Tickets dieser Anmeldesitzung und kann deshalb andere Zugriffe derselben Sitzung beeinträchtigen.
klist purge
klist get HTTP/app.example.net
klistDanach folgt der Zugriff auf die tatsächliche Anwendung mit der vorgesehenen Identität. Ein separat mit klist abgerufenes Ticket belegt noch nicht, dass die Anwendung es verwendet hat. Auch ein erfolgreicher Aufruf genügt wegen eines möglichen NTLM-Fallbacks nicht als Kerberos-Nachweis.
Zum Nachweis gehören das neu ausgestellte Dienstticket für den erwarteten SPN, die Ticket- und Sitzungsschlüsselverschlüsselung sowie ein Beleg für die Kerberos-Authentifizierung an der Anwendung. Dafür eignet sich beispielsweise ein zum Test gehörendes serverseitiges Anmeldeereignis 4624 mit dem Authentifizierungspaket Kerberos, sofern ein solches Ereignis erzeugt und protokolliert wird. Je nach Anwendung liefern auch deren eigene Authentifizierungsprotokolle den benötigten Beleg.
Starte die Umstellung weiterer Dienste erst, wenn für den Pilotdienst das neu ausgestellte AES-Ticket und die erfolgreiche Kerberos-Authentifizierung an der Anwendung gemeinsam dokumentiert sind.