RC4 in Kerberos deaktivieren: prüfen, beheben, AES erzwingen

RC4-HMAC ist der Kerberos-Verschlüsselungstyp, der Kerberoasting billig macht: Ein RC4-Ticket ist mit dem ungesalzenen NT-Hash des Kontos verschlüsselt, sein Knacken kostet also etwa so viel wie das Knacken eines NTLM-Hashs, und ein Angreifer, der den NT-Hash bereits besitzt, kann RC4-Tickets fälschen, ohne das Kennwort zu kennen. AES-Tickets verwenden eine gesalzene, iterierte Schlüsselableitung und sind um Größenordnungen langsamer anzugreifen. Die meisten Domänen stellen noch für zumindest einige Konten RC4-Tickets aus – nicht weil etwas sie braucht, sondern weil niemand nachgewiesen hat, dass nichts sie braucht.

Dieser Leitfaden ist die Schritt-für-Schritt-Version des RC4-Abschnitts aus Kerberos-Härtung: wie der KDC tatsächlich einen Verschlüsselungstyp wählt, wie Sie die RC4-Nutzung messen, wie Sie Konten beheben, die kein AES können, und wie Sie ohne Ausfall erzwingen.

Wie der KDC einen Verschlüsselungstyp wählt

Drei Eingaben bestimmen den Ticketverschlüsselungstyp eines Diensttickets:

1. msDS-SupportedEncryptionTypes des Zielkontos (Bitflags: 0x4 RC4, 0x8 AES128, 0x10 AES256, 0x20 AES-Sitzungsschlüssel). Ist das Attribut gesetzt, verwendet der KDC den stärksten aufgeführten Typ, für den er einen Schlüssel hat.
2. DefaultDomainSupportedEncTypes auf dem KDC, verwendet, wenn das Attribut leer ist. Konten ohne gesetztes Attribut sind die Mehrheit, daher ist dieser Registrierungswert der eigentliche domänenweite Standard.
3. Die für das Konto gespeicherten Schlüssel. Ein im Attribut aufgeführter Typ nützt nichts, wenn das Konto keinen Schlüssel dafür hat.

Computerkonten befüllen msDS-SupportedEncryptionTypes selbst anhand der Clientrichtlinie. Benutzerbasierte Dienstkonten haben es fast nie gesetzt und folgen daher DefaultDomainSupportedEncTypes, was historisch RC4-Tickets bedeutete. Seit den Kerberos-Updates vom November 2022 (CVE-2022-37966) ist der für Konten ohne Attribut angenommene Standard 0x27 (DES, RC4 und AES-Sitzungsschlüssel): Das liefert AES-Sitzungsschlüssel, aber weiterhin RC4-Ticketverschlüsselung. Microsoft hat weitere Änderungen angekündigt, um DCs im Lauf des Jahres 2026 auf reine AES-Standards umzustellen. Prüfen Sie daher in den Versionshinweisen das Verhalten Ihres aktuellen Update-Stands, bevor Sie sich auf Standards verlassen.

Messen: herausfinden, wo RC4 verwendet wird

Die richtige Überwachung aktivieren

Auf DCs: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon, aktivieren Sie Audit Kerberos Authentication Service und Audit Kerberos Service Ticket Operations für Erfolg und Fehler. Das erzeugt die Ereignisse 4768 (TGT) und 4769 (Dienstticket), beide mit dem Feld TicketEncryptionType: 0x17 ist RC4, 0x11 AES128, 0x12 AES256. Neuere Windows-Server-Updates haben diesen Ereignissen Felder hinzugefügt, die die verfügbaren Schlüssel und unterstützten Typen des Kontos beschreiben – das erleichtert die nächsten Schritte, sofern Ihre DCs diese Updates haben.

# RC4-Diensttickets der letzten 24 Stunden, gruppiert nach Dienst und Client
$since = (Get-Date).AddHours(-24)
Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Security'; Id = 4769; StartTime = $since
    } -ErrorAction SilentlyContinue
} | ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TicketEncryptionType -eq '0x17') {
        [pscustomobject]@{ Service = $d.ServiceName; Client = $d.TargetUserName; Address = $d.IpAddress }
    }
} | Group-Object Service, Client, Address | Sort-Object Count -Descending |
    Select-Object Count, Name

Führen Sie dieselbe Abfrage für 4768 aus, um Clients zu finden, die RC4-TGTs anfordern. Leiten Sie diese Ereignisse für ein belastbares Fenster von 30 bis 90 Tagen an Ihr SIEM weiter; Get-WinEvent sieht auf ausgelasteten DCs nur, was das lokale Protokoll vorhält. Microsoft veröffentlicht außerdem Hilfsskripte im GitHub-Repository Kerberos-Crypto, die die Verschlüsselungsnutzung aus diesen Ereignissen zusammenfassen.

Konten ohne AES-Schlüssel finden

AES-Schlüssel entstehen, wenn ein Kennwort auf einem DC mit Windows Server 2008 oder neuer in einer Domäne mit Funktionsebene 2008 oder höher gesetzt wird. Das Erstellungsdatum der Gruppe Read-only Domain Controllers (RID 521) ist ein verlässlicher Marker dafür, wann die Domäne für diese Ebene vorbereitet wurde. Jedes Konto, dessen Kennwort älter ist, hat keine AES-Schlüssel.

$domainSid = (Get-ADDomain).DomainSID.Value
$aesDate = (Get-ADGroup -Identity "$domainSid-521" -Properties whenCreated).whenCreated

Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet, ServicePrincipalName |
    Where-Object { $_.PasswordLastSet -lt $aesDate } |
    Select-Object SamAccountName, PasswordLastSet, @{n='HasSPN';e={[bool]$_.ServicePrincipalName}}

Beziehen Sie krbtgt und Vertrauenskonten in die Prüfung ein. Ein krbtgt-Kennwort, das älter als dieses Datum ist, ist für sich genommen ein Befund; rotieren Sie es mit dem Verfahren zur krbtgt-Rotation.

Explizite RC4-Einstellungen prüfen

# Konten mit explizit erlaubtem RC4 oder DES (eines der Bits 0x1, 0x2, 0x4)
Get-ADObject -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=7)' `
    -Properties msDS-SupportedEncryptionTypes, objectClass |
    Select-Object Name, objectClass, msDS-SupportedEncryptionTypes

# Vertrauensstellungen: TDOs ohne AES-Flags fallen auf RC4-Referral-Tickets zurück
Get-ADObject -Filter 'objectClass -eq "trustedDomain"' -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Prüfen: die Blocker beheben

Arbeiten Sie die Liste aus der Messphase ab:

• Konten ohne AES-Schlüssel: Setzen Sie das Kennwort zurück. Stimmen Sie sich bei Dienstkonten mit dem Anwendungsverantwortlichen ab oder migrieren Sie besser auf ein gMSA (siehe gMSA-Migration).
• Dienstkonten, die von Nicht-Windows-Systemen genutzt werden: Erzeugen Sie Keytabs mit AES neu, zum Beispiel ktpass /crypto AES256-SHA1 für die SPN-Zuordnung, und aktualisieren Sie permitted_enctypes in krb5.conf auf dem Client. Alte Keytabs, die nur RC4-Schlüssel enthalten, versagen, sobald RC4 entfernt ist.
• Appliances und Legacy-Software, die RC4 explizit anfordern: aktualisieren, umkonfigurieren oder eine befristete Ausnahme dokumentieren, indem Sie msDS-SupportedEncryptionTypes nur auf diesem einen Konto auf 0x1C (RC4 plus AES) setzen.
• Vertrauensstellungen: Aktivieren Sie AES auf beiden Seiten mit The other domain supports Kerberos AES Encryption in den Eigenschaften der Vertrauensstellung oder mit ksetup /setenctypeattr <trusted domain> AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.

Kennzeichnen Sie Dienstkonten explizit als AES-fähig, damit sie nicht mehr vom KDC-Standard abhängen:

# AES128 + AES256 auf Benutzerkonten mit SPNs
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    ForEach-Object { Set-ADUser $_ -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 } }

Den Rollout planen

Das Entfernen von RC4 ist risikoarm, wenn es langweilig verläuft: kleine Schritte, jeder umkehrbar, jeder gemessen. Ein Plan, der in den meisten mittelgroßen Domänen funktioniert:

1. Wochen 1 bis 4: nur messen. Überwachung aktiv, Ereignisse weitergeleitet, Bericht über Konten ohne AES-Schlüssel erstellt. Erstellen Sie eine Liste jedes Clients und Dienstes, der in einem RC4-Ereignis auftauchte, mit je einem Verantwortlichen.
2. Wochen 3 bis 8: Konten beheben. Kennwörter von Konten ohne AES-Schlüssel zurücksetzen, msDS-SupportedEncryptionTypes auf Dienstkonten auf 24 setzen, Keytabs neu erzeugen, AES auf Vertrauensstellungen aktivieren. Jede Korrektur sollte eine Zeile aus dem RC4-Bericht verschwinden lassen; tut sie das nicht, liegt die Ursache woanders.
3. Wochen 6 bis 10: Clientrichtlinie in Ringen. Pilot-Arbeitsplätze, dann alle Arbeitsplätze, dann Mitgliedsserver. Clients, die kein RC4 mehr anfordern, brauchen keinen KDC, der es verweigert – dieser Ring tut daher selten weh.
4. Nach zwei ruhigen Wochen: KDC. Setzen Sie DefaultDomainSupportedEncTypes und die Kerberos-Richtlinie auf den DCs, beginnend mit den DCs eines einzelnen Standorts, wenn Ihre Topologie das zulässt.
5. Fortlaufend: Ausnahmen. Jedes Konto, das RC4 behält, bekommt ein Ticket mit Verantwortlichem und Ablaufdatum und wird in einer Gruppe wie Kerberos-RC4-Exceptions geführt, damit die Ausnahme in AD sichtbar ist statt in einer Tabelle.

Der Rollback ist in jedem Schritt ein Registrierungswert oder eine GPO-Verknüpfung. Planen Sie in jedem KDC-Ring einen DC-Neustart ein, damit die Registrierungsänderung zuverlässig übernommen wird, und ebenso für den Rollback. Bestehende Tickets bleiben bis zu ihrem Ablauf gültig, sodass Probleme bis zur Ticketlebensdauer (standardmäßig 10 Stunden) brauchen können, um sichtbar zu werden. Halten Sie das Änderungsfenster lange genug offen, um sie zu sehen, und bündeln Sie die KDC-Änderung nicht in derselben Woche mit anderen Authentifizierungsänderungen wie der Erzwingung der LDAP-Signierung, sonst wissen Sie nicht, welche davon eine bestimmte Anwendung gebrochen hat.

Erzwingen

Erzwingen Sie auf zwei Ebenen, Ring für Ring.

KDC-Standard. Setzen Sie auf jedem DC den Wert, der für jedes Konto ohne explizites Attribut gilt:

# 0x18 = AES128 + AES256. 0x38 verwenden, um zusätzlich AES-Sitzungsschlüssel anzukündigen.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
    -Name 'DefaultDomainSupportedEncTypes' -Type DWord -Value 0x18

Verteilen Sie ihn über GPO-Einstellungen (Computer Configuration > Preferences > Windows Settings > Registry), verknüpft mit der OU Domain Controllers, damit jeder neue DC ihn erhält.

Kerberos-Richtlinie. Wenden Sie Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos (Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren) an, wobei nur AES128_HMAC_SHA1, AES256_HMAC_SHA1 und Future encryption types aktiviert sind. Die Einstellung schreibt SupportedEncryptionTypes unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Auf Mitgliedscomputern begrenzt sie, was der Client anfordert, und aktualisiert das Attribut des Computerkontos; auf DCs begrenzt sie, was der KDC ausstellt. Rollen Sie sie zuerst auf eine Pilot-OU mit Arbeitsplätzen und Servern aus, dann auf Tier 1 und zuletzt auf die DCs.

Überprüfen

Wiederholen Sie nach jedem Ring die 4769-Abfrage. Ziel sind null 0x17-Tickets außerhalb dokumentierter Ausnahmen.

# Auf einem DC: effektive Einstellungen bestätigen
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -Name DefaultDomainSupportedEncTypes
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
    -Name SupportedEncryptionTypes

# Auf einem Client: Tickets im Cache sollten AES-256-CTS-HMAC-SHA1-96 anzeigen
klist

Beobachten Sie außerdem 4768- und 4769-Fehler mit Ergebniscode 0xE (KDC_ERR_ETYPE_NOTSUPP): Jeder davon ist ein Client oder Dienst, der sich nicht mehr authentifizieren kann und Aufmerksamkeit braucht.

Was dabei bricht

• Konten ohne AES-Schlüssel, einschließlich alter Dienstkonten, deren Rücksetzung sich niemand getraut hat, erhalten keine Tickets mehr. Die Lösung ist eine Kennwortrücksetzung, die ihrerseits die Anwendung brechen kann, wenn das Kennwort irgendwo fest hinterlegt ist.
• Keytab-basierte Integrationen unter Linux, Java und auf Appliances (Web-SSO, SAP, Speicher) authentifizieren sich nicht mehr, bis die Keytabs mit AES-Schlüsseln neu erzeugt sind.
• Ältere NAS- und Samba-Versionen, die AES für Maschinen- oder Dienstkonten nicht unterstützen, sowie manche Legacy-Fachanwendungen, die RC4 fest vorgeben.
• Gesamtstrukturübergreifende und externe Vertrauensstellungen ohne aktiviertes AES auf dem Vertrauensobjekt brechen bei Referral-Tickets, sobald RC4 entfernt ist.
• Systeme aus der Ära Windows XP / Server 2003: Sie unterstützen AES überhaupt nicht. Es sollte sie nicht mehr geben, aber falls doch, authentifizieren sie sich nicht mehr.

Weiterführende Lektüre: der Bereich Kerberos & Authentifizierung, Abwehr von Kerberoasting dazu, warum AES bei Dienstkonten zählt, und NTLM einschränken, um die NT-Hash-Exposition zu schließen, die das Entfernen von RC4 nicht adressiert.