Event-ID 14,4771: Benutzer können sich nach November-Update nicht anmelden

Sie findet sich unter Computer­konfiguration => Richtlinien => Windows-Einstellungen => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen.

Admins solcher Umgebungen melden nun, dass Benutzer oder Group Managed Service Accounts (gMSA) sich nach dem November-Update nicht mehr anmelden können. Im Eventlog des Domain-Controllers findet sich der Eintrag mit der ID 14:

While processing an AS request for target service krbtgt, the account (…) did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1).

Update: Microsoft bietet nun ein Out-of-Band-Update für dieses Problem an:

• Windows Server 2022: KB5021656
• Windows Server 2019: KB5021655
• Windows Server 2016: KB5021654

Betroffen sind Konten, denen die Algorithmen für die Kerberos-Verschlüsselung über das Attribut msDS-supportedEncryptionTypes direkt zugewiesen wurden, aber bei denen sich RC4 nicht unter den konfigurierten Verfahren befindet.

Nachdem RC4 bereits systemweit deaktiviert ist, würde man davon ausgehen, dass diese Verschlüsselung problemlos auch aus dem zuständigen Attribut der Konten entfernt werden kann.

Der Microsoft-Mitarbeiter Steve Syfuhs erklärte auf Twitter jedoch, dass Bit 3 in msDS-supportedEncryptionTypes nicht nur RC4 aktiviert, sondern noch eine zusätzliche Bedeutung hat.

Demnach dient es zusätzlich als Signal dafür, ob die bevorzugte Verschlüsselung verwendet werden sollte oder eine Liste mit Legacy-Verfahren.

Ein ähnlicher Konflikt entsteht offenbar, wenn über msDS-supportedEncryptionTypes nur die Bits 4 und 5 für AES 128 sowie AES 256 gesetzt sind und gleichzeitig die Einstellungen für die AES-Verschlüsselung in einem Konto aktiviert wurden.

Betroffene Konten finden

Konten, die explizit für AES, aber nicht RC4 konfiguriert wurden, kann man so finden:

Get-ADObject -Filter "msDS-supportedEncryptionTypes -band 0x18 `
-and -not msDS-supportedEncryptionTypes -band 0x4"

Eine Lösungsmöglichkeit bestünde mithin darin, die Gruppenrichtlinie Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren zu deaktivieren. Durch das November-Update wird RC4 ohnehin nicht mehr verwendet, solange man es nicht explizit für ein Konto aktiviert hat.

Liegt ein Konflikt mit den AES-Einstellungen aus der obigen Abbildung vor, dann kann man diese entfernen. Zusätzlich könnte ein Wechsel des Passworts erforderlich sein.

RC4-Bit setzen

Alternativ könnte man die Gruppenrichtlinie belassen und bei den betroffenen Konten, bei denen die Verschlüsselung über msDS-supportedEncryptionTypes auf bestimmte Verfahren festgelegt wurde, zusätzlich RC4 aktivieren:

Get-ADObject -Filter "msDS-supportedEncryptionTypes -band 0x18 ` -and -not msDS-supportedEncryptionTypes -band 0x4" ` -Properties msDS-SupportedEncryptionTypes | foreach {   $NewEncTyp = $_.'msDS-SupportedEncryptionTypes' + 0x4   Set-ADObject -Identity $_ -replace @{'msDS-SupportedEncryptionTypes'=$NewEncTyp}   }

Zusammenfassung

Tiefgreifende Systemänderungen haben oft unvorhersehbare Nebeneffekte, die in diesem Fall die Authentifizierung betreffen und entsprechend unangenehm sein können. Das Deaktivieren von RC4 bedarf normalerweise einiger Vorarbeiten und Tests, erfolgte aber nun aufgrund der aufgetretenen Schwachstelle zumindest partiell im Hauruck-Verfahren.

Als nachteilig erweist sich jetzt, dass Microsoft das RC4-Bit in msDS-supportedEncryptionTypes für eine zusätzliche Bedeutung "missbrauchte".

Eine offizielle Lösung für das Problem gibt es bis dato nicht. Die obigen Vorschläge sind Anregungen für Workarounds, die auf meiner Interpretation der Tweets von Steve Syfuhs basieren.