Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Hintergründe

Die gesamte Funktionsweise des Angriffs kann detailliert beim Entdecker der Sicherheitslücke nachgelesen werden.

Zertifikatbasierte Anmeldung wird nicht nur beim offensichtlichen bekannten "Smartcard Logon" eingesetzt, sondern auch beim Active Directory Clientzertifikat-Mapping des Internet Information Service (IIS).

Nicht nur Benutzerkonten können sich mit einem Zertifikat an der Domäne anmelden. Auch für Computerkonten ist dies möglich.

Bei Benutzerkonten wird das userPrincipalName Attribut des zugehörigen Active Directory Kontos in das ausgestellte Zertifikat eingetragen und vom Active Directory bei Anmeldung wieder auf das dazugehörige Objekt verbunden.

Bei Computerkonten ist die Funktionsweise prinzipiell die gleiche, jedoch wird hier das dNSHostName Attribut in das Zertifikat eingetragen und vom Active Directory bei Anmeldung ausgewertet.

Siehe auch Artikel "Zur Option "Build this from Active Directory information" bei Zertifikatvorlagen".

Der Angriff basiert darauf, dass der Besitzer eines Computerobjektes (derjenige, der die Maschine in die Domäne aufgenommen hat – dieses Recht hat in der Standardeinstellung jeder Benutzer) dessen dNSHostName Attribut eigenständig auf einen beliebigen Wert setzen kann. Kollisionen mit anderen Objekten (also ob der gleiche Wert bereits auf einem anderen Computerobjekt gesetzt ist), werden bei dNSHostName nicht erkannt.

Entsprechend ist es möglich, Zertifikate für Identitäten anderer Computer, auch Domänencontroller, zu beantragen, mit denen dann eine Identifikation unter der Identiät des gefälschten Computerobjektes möglich ist, was wiederum das Auslesen aller Anmeldedaten der Domäne zur Folge haben kann.

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Das Update

Die Änderungen sind detailliert im Microsoft Knowledge Base Artikel KB5014754 beschrieben.

Neue Zertifikaterweiterung

Das Update führt eine neue Zertifikaterweiterung namens szOID_NTDS_CA_SECURITY_EXT mit Objektidentifizierer (OID) 1.3.6.1.4.1.311.25.2 ein.

Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update.
KB5014754—Certificate-based authentication changes on Windows domain controllers (Microsoft Corporation)

Alle Zertifikate, die von "Online" Zertifikatvorlagen, also solche, bei denen der Identitätsanteil im Zertifikat durch das Active Directory gebildet wird, ausgestellt werden, beinhalten ab Zeitpunkt der Installation des Updates auf der Zertifizierungsstelle diese Zertifikaterweiterung.

Die Zertifikaterweiterung beinhaltet das objectSid ("Security Identifier") Active Directory Attribut des zugehörigen Kontos. Die Eintragung des Zertifikatattributs wird durch das Windows Default Policy Modul vorgenommen, welches ein entsprechende Update erhalten hat.

Mit dem Patch wurde somit eine neue Version des Windows Default Policy Moduls installiert, um die entsprechenden Änderungen bei der Zertifikatausstellung abzubilden.

Siehe Versionsummer vor dem Patch…

… und nach Installation des Patch.

Änderungen am Active Directory

Anstatt die grundlegende Problematik (Besitzer von Computerkonten können deren dNSHostName Attribut selbst verändern und es ist kein uniqueness Constraint auf dieses gesetzt) anzugehen, ist Microsoft ab sofort der Meinung, dass das dNSHostName Attribut nun nicht mehr als "starke" Verbindung zum entsprechenden Active Directory Konto zu bewerten ist.

Entweder soll die Verbindung zwischen Active Directory Konto und Zertifikat nun manuell über das altSecurityIdentities Attribut des Kontos erfolgen, oder ein Zertifikat muss die neue Zertifikaterweiterung mit dem entsprechenden Security Identifier des Kontos vorweisen.

Entsprechend werden bei der Verarbeitung von zertifikatbasierten Anmeldungen nach dem "alten" Schema nun neue Warnmeldungen (Ereignis mit ID 39 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center) protokolliert.

The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.

Es ist über den "StrongCertificateBindingEnforcement" Registry-Schlüssel (Typ DWORD) möglich, den neuen Verarbeitungs-Modus zu verwenden, bei welchem eine (nach Ansicht von Microsoft) "starke" Bindung hergestellt wird.

Der Schlüssel befindet sich an folgendem Ort:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Der Schlüssel kann folgende Werte annehmen:

Wert	Beschreibung
0	Anmeldungen mit Zertifikaten ohne SID-Attribut werden nicht protokolliert und zugelassen.
1	Anmeldungen mit Zertifikaten ohne SID-Attribut werden protokolliert und zugelassen. (Standardeinstellung)
2	Anmeldungen mit Zertifikaten ohne SID-Attribut werden protokolliert und nicht zugelassen.

Ändert man den Wert auf "2", werden entsprechende Anmeldungen abgelehnt und entsprechend auf dem Domänencontroller protokolliert.

Microsoft plant, den "neuen" Mechanismus exakt ein Jahr nach Release des Updates, also am 19. Mai 2023 hart zu erzwingen. Die entsprechende Logik ist bereits im Patch enthalten. Die im Artikel genannten Registry-Schlüssel werden ab dann nicht mehr verwendbar sein.

Update: Microsoft hat die Erzwingung auf den 14. November 2023 verschoben.

Erneutes Update: Offenbar gibt es schwerwiegendere Probleme, sodass Microsoft die Erzwingung erneut verschoben hat, dieses Mal auf den 11. Februar 2025. Spannend ist hier auch der Nebensatz "…oder später".

Wenn kein explizites Mapping von Zertifikat nach Konto gewünscht ist, also die neue Zertifikaterweiterung verwendet werden soll, müssen bis zum Stichtag alle Zertifikate neu ausgestellt werden.

Common Name reicht offenbar auch nicht mehr…

In einem Nebensatz erwähnt Microsoft des Weiteren, dass es seit dem Patch ab sofort auch erforderlich ist, die entsprechenden Zertifikat-Attribute userPrincipalName bzw. dNSName mit den Werten des entsprechend zugehörigen Active Directory Kontos zu befüllen, das alleinige Verwenden des commonName also nicht mehr ausreicht.

Diese Änderung betrifft Netzwerkrichtlinienserver (NPS) oder Webserver, welche eine Anmeldung mit Zertifikaten verarbeiten. Die zugrundeliegende Bibliothek wurde durch den Patch mit einem neuen Standardwert konfiguriert.

Dieser befindet sich im Wert "CertificateMappingMethods" unterhalb des folgenden Registrierungsschlüssels:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel

Dieser Wert kann wie folgt konfiguriert werden:

Bit	Einstellung	Methode	Einschätzung zur Stärke
1	0x0001	Subject/Issuer certificate mapping	schwach
2	0x0002	Issuer certificate mapping	schwach
3	0x0004	UPN certificate mapping	schwach
4	0x0008	S4U2Self certificate mapping	stark
5	0x0010	S4U2Self explicit certificate mapping	stark

Der alte Standardwert von 0x1F (0001 1111) hatte alle der genannten Methoden aktiviert. Der neue Standardwert 0x18 (0001 1000) aktiviert nur noch die beiden "starken" Methoden.

Hier gab es Verwirrung, da einige Blogger schreiben, es müsse unbedingt das userPrincpialName Attribut befüllt und entsprechend in der Zertifikatvorlage aktiviert sein. Dies verleitete einige Administratoren dazu, dies offenbar auch für Computer-Zertifikate zu aktivieren, was natürlich nicht notwendig ist. Vielmehr kommt es darauf an, was durch das Zertifikat identifiziert werden soll. Bei Computer-Zertifikaten muss ein Subject Alternative Name vom Typ "dNSName" vorhanden sein, bei Benutzer-Zertifikaten vom typ "userPrincipalName".

Umgang mit der neuen Situation

Offline-Zertifikatvorlagen wurden anscheinend vergessen

Ich habe die Änderung zum Anlass genommen, das PSCertificateEnrollment PowerShell Modul zu erweitern, sodass die neue Zertifikaterweiterung in einen "offline" Zertifikatantrag eingetragen werden kann.

Import-Module PSCertificateEnrollment
New-CertificateRequest -Subject "CN=test" -Sid "lol"

Wie sich zeigt, reicht das Windows Default Policy Modul bei Offline-Zertifikatvorlagen (also solchen, bei denen der Antragsteller den Identitätsinhalt des Zertifikats selbst bestimmen kann) die Zertifikaterweiterung mit beliebigem Inhalt an das ausgestellte Zertifikat durch.

Gelingt es einem Angreifer nun, Zugriff auf eine solche Zertifikatvorlage zu erhalten, ist die vermeintlich "starke" Bindung an ein Active Directory Objekt hinfällig (sofern man auf die neue Zertifikaterweiterung anstatt explizitem Mapping für die Authentisierung setzt).

Darüber hinaus bin ich der Meinung, dass die Verwendung einer proprietären Zertifikaterweiterung hier sogar gefährlich sein kann, da dieser Identitätstyp von gängigen Lösungen nicht als Identität erkannt und in einer (sofern vorhanden) Datenbank erfasst würde.

Das TameMyCerts Policy Modul ist mittlerweile in der Lage die neue Zertifikaterweiterung in "offline" Zertifikatanforderungen zunächst erkennen und ablehnen zu können. Ebenfalls ist es möglich, die neue Zertifikaterweiterung in Zertifikate für "offline" Zertifikatanforderungen einzutragen, etwa wenn diese durch ein Mobile Device Management (MDM) System wie Intune, Workspace ONE oder MobileIron gestellt wurden.

Auch erstaunt es, dass eine Steuerung, ob diese Zertifikaterweiterung für offline-Zertifikatanforderungen verwendet werden darf, über den dafür vorgesehenen EnableEnrolleeRequestExtensionList Registry Schlüssel leider nicht möglich ist, da sie offenbar hart in das Policy Modul kodiert ist und entsprechend nicht in der Liste auftaucht (und dennoch aktiv ist).

Probleme mit dem Patch bei der Anmeldung am Netzwerkrichtlinienserver (engl. Network Policy Server, NPS) oder Internetinformationsdienste (engl. Internet Information Service, IIS)

Relativ schnell nach Installation des Patch zeigte sich, dass Unternehmen, die den Network Policy Service (NPS) einsetzen, um Remote Access (RAS) oder Network Access Control (NAC) Szenarien wie Anmeldungen am verkabelten oder drahtlosen Netzwerk mit Zertifikaten zu ermöglichen, sich mit einem Ausfall genau dieser Services befassen mussten.

Das Problem tritt in vergleichbarer Weise auch bei IIS Webservern auf, die Anmeldungen mit Clientzertifikaten verarbeiten.

Offenbar wurde seitens Microsoft übersehen, dass verschiedenste Anmeldungen im Active Directory auf dem gleichen Verfahren – so auch der NPS – basieren. Und dort wurde offenbar der "neue" Betriebsmodus bereits erzwungen. Auch der am 19. Mai 2022 nachgeschobene Patch für den Patch behebt das Problem offenbar nicht. Erst das Out-of-Band Update vom 27.05.2022 behebt das Problem offenbar.

Stand 05. August 2022 kann ich bestätigen, dass sich ein Domänencontroller mit Patchlevel Juli 2022 (StrongCertificateBindingEnforcement ist mit Wert 1 konfiguriert oder nicht gesetzt) und installierter Netzwerkrichtlinienserver-Rolle exakt wie dokumentiert verhält, sprich die RADIUS-Anmeldungen annimmt und auch dann genehmigt, wenn die SID-Zertifikaterweiterung im Zertifikate nicht vorhanden ist. Das Ereignis mit ID 39 wird als Warnung protokolliert.

Aktuell gibt es hier nur den Workaround, zuerst die Zertifizierungsstelle zu patchen, dann alle Zertifikate (mit der neuen Zertifikaterweiterung) neu auszustellen und anschließend die Domänencontroller zu patchen – was in der Praxis nicht praktikabel sein wird, da eine typische Zertifikaterneuerung durchaus mehrere Monate in Anspruch nehmen kann, bis sie flächendeckend erfolgt ist.

Eine Deinstallation des Patch kann auch nicht die Lösung sein, da man hierdurch gegen etliche Sicherheitslücken ungeschützt bleibt (auch wenn die US-Behörde CISA zwischenzeitlich vor der Installation der Patches gewarnt hat).

Angeblich funktioniert der Patch darüber hinaus auch nicht mit Ready-only Domänencontrollern (RODCs).

Was ist eigentlich mit gewollten offline-Szenarien?

Des Weiteren stellt sich mir die Frage, wie Microsoft gedenkt, mit Szenarien umzugehen, die offline-Zertifikatvorlagen gewollt nutzen. Nehmen wir als Beispiel mit einem Mobile Device Management (MDM) System (z.B. das Microsoft-eigene Intune/MEM oder VMwares AirWatch) verwaltete Endgeräte wie Smartphones. Diese können durchaus Zertifikate besitzen, welche für eine Anmeldung via RAS oder NAC verwendet werden (üblicherweise werden diese für die Identität Benutzer ausgestellt, welcher das Gerät verwendet).

Wird nun im Unternehmen im Backend der Network Policy Server (NPS) eingesetzt, stellt sich mir die Frage (sofern das NPS-Problem zwischenzeitlich durch einen Patch behoben werden sollte), was wohl am Datum der Erzwingung passieren wird, wenn Microsoft wie geplant die Erzwingung der neuen Zertifikaterweiterung aktiviert (die "Zeitbombe" ist ja schließlich bereits enthalten), und das ohne Möglichkeit der Abschaltung.

Network Policy Server denied access to a user. [...] Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

Werden alle MDM-Hersteller bis zu diesem Datum dafür Sorge getragen haben, dass ihre Produkte die neue Zertifikaterweiterung beantragen werden und dass ihre Kunden alle Zertifikate bis dahin erneuert haben werden?

Mittlerweile wird diese Annahme unter Anderen von der US-Regierung geteilt, ohne dass es hierfür eine Lösung gäbe:

Important Note: Microsoft plans to remove ‘Compatibility Mode’ and move all Windows Server devices to ‘Full Enforcement’ mode in May 2023. This change will break authentication if agencies have not created a strong mapping or added SIDs to certificates. CISA and the interagency working group are in active discussions with Microsoft for an improved path forward. At this time, CISA does not recommend agencies pursue migration to a strong mapping.
GUIDANCE ON APPLYING JUNE MICROSOFT PATCH TUESDAY UPDATE FOR CVE-2022-26925 (Cybersecurity & Infrastructure Security Agency)

Ironischerweise schreibt Microsoft selbst folgendes dazu:

Environments that have non-Microsoft CA deployments will not be protected using the new SID extension after installing the May 10, 2022 Windows update. Affected customers should work with the corresponding CA vendors to address this or should consider utilizing other strong certificate mappings described above.

Mit anderen Worten schlägt Microsoft vor, dass doch bitteschön andere Zertifizierungsstellen-Hersteller diese Zertifikaterweiterung in ihre Produkte aufnehmen sollen, ohne in ihrem eigentlichen für eine vollständige Lösung gesorgt zu haben.

Hier kann man durchaus von einer tickenden Zeitbombe sprechen.

Ich habe mit dem TameMyCerts Policy Modul für Microsoft-Zertifizierungsstelle mittlerweile eine mögliche Lösung für dieses Szenario geschaffen. Mit dem TameMyCerts Policy Modul ist es möglich, die durch das Mobile Device Management System in der Zertifikatanforderung beantragte Identität mit dem dazugehörigen Active Directory Konto zu verbinden und dessen SID in eine entsprechende Zertifikatanforderung im ausgestellten Zertifikat einzutragen. Kontaktieren Sie mich gerne, wenn Sie das Modul einsetzen möchten und Hilfe bei der Einrichtung benötigen.

Alternative Möglichkeiten für eine "starke" Bindung

Microsoft weist darauf hin, dass – sofern man keine Zertifikate mit der neuen Zertifikaterweiterung ausstellen kann oder möchte – auch manuell eine "starke" Bindung an ein Zertifikat über das altSecurityIdentities Attribut für Active Directory Objekte einrichten kann.

Dieser Schritt muss jedoch manuell oder mit einem Script erfolgen. Eine brauchbare Automatisierungslösung bietet Microsoft nicht an. Unklar ist hierbei auch, wie diese Liste dauerhaft gepflegt werden kann.

Deaktivieren der Erweiterung

Die Deaktivierung der neuen Zertifikaterweiterung kann dann Sinn machen, wenn eine zertifikatbasierte Anmeldung in der Umgebung ohnehin nicht vorgesehen ist.

Bitte diesen Schritt bitte nur mit Sinn und Verstand vornehmen, und nur wenn es einen triftigen Grund gibt. Die Änderung ist als "nicht kritisch" markiert und sollte daher keine negativen Auswirkungen z.B. in Hinsicht auf Anwendungskompatibilität haben.

Auf Ebene der jeweiligen Zertifikatvorlage kann die Erweiterung mit folgendem Befehl deaktiviert werden:

certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000

Das Flag heißt CT_FLAG_NO_SECURITY_EXTENSION, wird derzeit vom Betriebssystem aber noch nicht aufgelöst.

Added a new enrollment-attribute flag CT_FLAG_NO_SECURITY_EXTENSION to the msPKI-Enrollment-Flag Attribute table, that when applied, instructs the CA to not include the security extension szOID_NTDS_CA_SECURITY_EXT (OID:1.3.6.1.4.1.311.25.2), as specified in [MS-WCCE] sections 2.2.2.7.7.4 and 3.2.2.6.2.1.4.5.9, in the issued certificate. A behavior note is added to indicate that this enrollment flag is supported by the operating systems specified in [MSFT-CVE-2022-26931], each with its related KB article download installed.
Windows protocols: What’s New and Changed (Microsoft Corporation)

Auf Zertifizierungsstellen-Ebene kann die Erweiterung ebenfalls deaktiviert werden. Somit trägt die entsprechend konfigurierte Zertifizierungsstelle die Erweiterung in keines der veröffentlichten Zertifikate ein. Mit folgendem Befehl kann die Einstellung vorgenommen werden:

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2

Fazit/Bewertung

Der Patch wirkt sehr überhastet:

Das eigentliche Problem, dass ein Compterkonto einige seiner eigenen Attribute beliebig setzen kann, wird offenbar nicht adressiert.
Die neue Zertifikaterweiterung wird bei "offline" Zertifikatvorlagen nicht überprüft, entsprechend kann nicht wirklich die Rede von einer "starken" Bindung an das Active Directoy Objekt die Rede sein. Sie ist im Windows Default Policy Modul hart einkodiert und taucht nicht in den eigentlich dafür vorgesehenen Registrierungsschlüsseln des Policy Moduls für Offline-Zertifikatanforderungen auf, d.h. man ist hier zu seinem eigenen Design inkonsistent und baut offenbar hierdurch sogar einen neuen Bug ein. Dies entspricht aber effektiv dem Grad der Pflege, den das Produkt derzeit noch von Microsoft erwarten kann, nämlich gerade nur das allernötigste mit dem geringstmöglichen Aufwand umzusetzen.
Mit Einführung des Updates hat Microsoft eine offenbar nicht enden wollende Kette an neuen Problemen geschaffen (besteht hier eventuell ein Problem mit der Qualitätskontrolle)?
Offenbar hat Microsoft auch vergessen, dass es in der PKI auch noch eine Welt abseits des Active Directory gibt, hier aber nicht Sorge getragen, dass alle betroffenen Zertifikate bis zum Stichtag über die neue Zertifikaterweiterung verfügen können.

Darüber hinaus sind essentielle Themen weiterhin nicht angegangen worden. Beispielsweise werden Extended Key Usages von Domänencontrollern in der Standardeinstellung immer noch nicht geprüft.

Meine Empfehlung lautet daher weiterhin, die (wenn sie ohnehin nicht verwendet wird) Smartcard-Anmeldung und artverwandte Fälle komplett zu verhindern und alle Zertifizierungsstellen (bei denen dies gefahrlos möglich ist) aus NTAuthCertificates zu entfernen, welche keine Zertifikate für die entsprechenden Anmeldemechanismen ausstellen sollen. Der Network Policy Service sollte man meiner Meinung nach nicht mehr einsetzen, da er aufgrund seiner Abhängigkeit vom Active Directory verschiedenste Sicherheits- und wie man sieht nun auch Verfügbarkeitsprobleme schafft.

Generell ist ein starkes Stück, eine derart weitreichende Änderung einzuführen, ohne die Auswirkungen abschätzen zu können oder sich wenigstens mit den wichtigsten Partnern im Vorfeld abzustimmen. Eine (für PKI Lebenszyklen) derart kurze Vorlaufzeit von gerade einmal einem Jahr kann eigentlich schon als fahrlässig bezeichnet werden.

Weiterführende Links:

Externe Quellen

KB5014754—Certificate-based authentication changes on Windows domain controllers (Microsoft Corporation)
Windows protocols: What’s New and Changed (Microsoft Corporation)
May 2022 – You might see authentication failures on the server or client for services (Microsoft Corporation)
Windows Kerberos Elevation of Privilege Vulnerability (CVE 2022 26931) (Microsoft Corporation)
HowTo: Map a user to a certificate via all the methods available in the altSecurityIdentities attribute (Microsoft Corporation)
GUIDANCE ON APPLYING JUNE MICROSOFT PATCH TUESDAY UPDATE FOR CVE-2022-26925 (Cybersecurity & Infrastructure Security Agency)
Certifried: Active Directory Domain Privilege Escalation (CVE-2022–26923) (Oliver Lyak)
May 19, 2022—KB5015013 (OS Build 20348.709) Out-of-band (Microsoft Corporation)
CISA warns not to install May Windows updates on domain controllers (Bleepingcomputer)
NPS stopped working after May 2022 updates (Diskussion auf Microsoft TechNet)
AD Authentication Issues 2022-05 May Patches / Mapping Certificates to AD Objects (Robin Beismann)