Anmeldungen über den Netzwerkrichtlinienserver (engl. Network Policy Server, NPS) scheitern mit Grund "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."

Folgendes Szenario angenommen:

Es wird eine zertifikatbasierte Anmeldung mit Benutzer- oder Computerkonten vorgenommen, um diese an einem drahtlosen (IEEE 802.11 oder Wireless LAN) oder verkabelten Netzwerk (IEEE 802.3), oder eine Remote Access Verbindung (z.B. DirectAccess, Routing and Remote Access (RAS), Always on VPN) anzumelden.
Das Unternehmen verwendet als Server für Authentifizierung, Autorisierung und Accounting (AAA) den Netzwerkrichtlinienserver (engl. Network Policy Server NPS) von Microsoft.
Die Anmeldung am Netzwerk ist nicht mehr möglich.
Der Netzwerkrichtlinienserver protokolliert das folgende Ereignis, wenn ein Anmeldeversuch unternommen wird:

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.

Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verweigert. [...] Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.

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.

Microsoft hat mit dem Patch vom 10. Mai 2022 eine Veränderung an der Verarbeitung Zertifikatbasierter Anmeldungen gegen das Active Directory eingeführt.

Die Zertifizierungsstelle trägt eine neue Zertifikaterweiterung in ausgestellte Zertifikate ein, welche den Security Identifier (objectSid) des entsprechenden Kontos beinhaltet.
Domänencontroller erwarten die neue Zertifikaterweiterung in ausgestellten Zertifikaten, befinden sich aber bis zum 09. Mai 2023 in einem Kompatibilitätsmodus.
Die SChannel Bibliothek wendet nur noch bestimmte, als "sicher" eingestufte Methoden an, um Identitäten aus Zertifikaten zurück auf Active Directory Identitäten zu mappen.

Nachfolgend werden in diesem Zusammenhang mögliche Ursachen für fehlgeschlagene Anmeldungen am Netzwerkrichtlinienserver besprochen.

Die Zusammenhänge

Bevor wir die möglichen Ursache erläutern, verschaffen wir uns zunächst einen Überblick über die beteiligten Komponenten.

Ein Benutzer oder ein Computer möchte sich gegenüber einem Zugangspunkt authentisieren. Ein Zugangspunkt kann hierbei beispielsweise ein VPN-Gateway, ein Switch oder ein kabelloser Zugangspunkt sein.
Der Zugangspunkt reicht die Authentisierungs-Anfrage an den AAA-Server (in unserem Fall den Netzwerkrichtliniendienst) weiter.
Dieser wiederum prüft das verwendete Zertifikat, verbindet die im Zertifikat enthaltene Identität zu einem dazugehörigen Active Directory Objekt und leitet die Authentisierung an einen Domänencontroller weiter. Der Client ist nun in der Lage, einen PKINIT-Vorgang (auch bekannt als Smartcard Logon) gegenüber dem Domänencontroller durchzuführen.

Zu beachten ist hierbei, dass in diesem Konstrukt an verschiedenen Stellen Zertifikate eingesetzt werden:

Bei den anmeldenden Benutzern oder Computern.
Beim Netzwerkrichtlinienserver.
Beim Domänencontroller.

Mögliche Fehlerquellen

Zertifikatinhalt ist nicht kompatibel

Das Clientzertifikat muss einen Subject Alternative Name enthalten, welcher die Identität des verbindenden Kontos abbildet. Bei Benutzerkonten ist dies der userPrincipalName, bei Computerkonten der dNSName.

Das Clientzertifikat benötigt außerdem die neu eingeführte die SID-Zertifikaterweiterung oder das Zertifikat muss den alternativen Identitäten des dazugehörigen Benutzer- oder Computerkontos im Active Directory hinzugefügt sein.

Für Zertifikatanforderungen, welche nicht per Autoenrollment (beispielsweise wenn diese über ein Mobile Device Management wie AirWatch, MobileIron oder Intune beantragt werden) erfolgen, hat Microsoft bislang keine brauchbare Lösung, um sicherzustellen, dass die hier resultierende Zertifikate die neue Security Identifier Zertifikaterweiterung enthalten werden. Sie kann für solche Fälle jedoch bequem mit dem TameMyCerts Policy Modul für die Microsoft-Zertifizierungsstelle in die ausgestellten Zertifikate gebracht werden.

Methode für Zertifikat-Mapping ist nicht passend konfiguriert

Diese Änderung betrifft neben Anmeldungen am Netzwerkrichtlinienserver (NPS) auch solche an IIS Webservern, welche Zertifikaten verwendet werden.

Durch den Patch für Windows Server vom 10. Mai 2022 (KB5014754) wurde die zugrundeliegende SChannel Bibliothek mit einem neuen Standardwert für die Zuordnung der Identität im Zertifikat zum dazugehörigen Active Directory Konto konfiguriert.

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

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel

In der Standardeinstellung ist der Wert nicht vorhanden. In diesem Fall wurde bis zum Patch vom Mai 2022 "0x1F" angenommen, danach "0x18". Hierbei handelt es sich um eine Bitmaske, welche wie folgt konfiguriert werden kann:

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

Eventuelle Änderungen werden auf den Domänencontrollern (nicht auf dem Netzwerkrichtlinienserver) durchgeführt. Eine Änderung erfordert einen Neustart des "KDC" Dienstes auf dem Domänencontroller.

Der alte Standardwert von 0x1F (Binär 0001 1111) hatte alle der genannten Methoden aktiviert.

Der neue Standardwert 0x18 (0001 1000) aktiviert jedoch nur noch die beiden "starken" Methoden.

Wichtig zum Verständnis ist auch, dass die Methoden in Reihenfolge abgearbeitet werden. Ist somit beispielsweise das erste Bit (Subject/Issuer mapping) aktiviert (und ist der Subject Disinguished Name im Zertifikat korrekt befüllt), wird diese Methode vor einer vielleicht auch aktivierten "sicheren" Methode vorgezogen. In diesem Fall wird somit auch keine S4U2Self basierte Anmeldung vorgenommen, entsprechend entfaltet das StrongCertificateBindingEnforcement auf den Domänencontrollern auch keine Wirkung.

Wenn die Security Identifier Zertifikaterweiterung fehlt

Verfügt das vom verbindenden Client verwendete Zertifikat nicht über die neue Security Identifier Zertifkaterweiterung (oder ist keine explizite Zuordnung ber das altSecurityIdentities Attribut des Kontos konfiguriert) wird auf dem Domänencontroller, der die Anmeldung verarbeitet hat, ein Ereignis mit Nr. 39 der Quelle 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.

Das Ereignis mit der Nr. 39 der Quelle Microsoft-Kerberos-Key-Distribution-Center würde bei einem Anmeldefehler nur auftreten, wenn die Authentisierung überhaupt bis hierhin durchkommt (siehe vorheriger Abschnitt zum Thema Zertifikat-Mapping auf dem Netzwerkrichtlinienserver.

Das Ereignis kann vom Typ "Warnung" und vom Typ "Fehler" sein, jedoch deutet nur der Typ "Fehler" darauf hin, dass die Anmeldung aufgrund der Security Identifier Zertifikaterweiterung abgelehnt wurde.

Durch den Patch vom 10. Mai 2022 wurde ein neuer Registrierungs-Wert namens "StrongCertificateBindingEnforcement" (Typ DWORD) eingeführt.

Der Wert befindet sich auf den Domänencontrollern an folgendem Ort:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

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.

Eine Änderung erfordert einen Neustart des "KDC" Dienstes auf dem Domänencontroller.

In der Standardeinstellung ist der Wert nicht vorhanden (in diesem Fall wird der Wert 1 angenommen). Ändert man den Wert auf "2", werden entsprechende Anmeldungen abgelehnt und entsprechend auf dem Domänencontroller protokolliert.

Microsoft beabsichtigt, diesen Wert zum 09. Mai 2023 hart auf "2" zu setzen, d.h. es werden ab diesem Datum keine anderen Anmeldeformen mehr akzeptiert.

Unless updated to this mode earlier, we will update all devices to Full Enforcement mode by May 9, 2023. If a certificate cannot be strongly mapped, authentication will be denied.
KB5014754: Certificate-based authentication changes on Windows domain controllers

Sonderfall Read-only Domänencontroller

Das Ereignis mit der Nr. 39 der Quelle Microsoft-Kerberos-Key-Distribution-Center tritt in diesem Fall nicht protokolliert.

Für eine S4U2Self basierte Anmeldung, wie sie seit dem Patch und spätestens zum von Microsoft geplanten Datum zur Erzwingung zwingend benötigt wird, benötigt ein Read-only Domänencontroller ein Replikat des Passwortes des Kontos.

The NPS can authenticate the Routing and Remote Access Service (RRAS) connection only for accounts that are replicated to the RODC.
Applications that are compatible with RODCs in Windows Server

Somit muss sich das betreffende Konto mindestens einmal auf jedem vom Netzwerkrichtlinienserver verwendbaren Read-only Domänencontroller authentisiert haben, damit es für die zertifikatbasierte Anmeldung verwendet werden kann. Alternativ muss das Passwort vorab synchronisiert werden.

Diese Änderung stellt den Zweck von Read-Only Domain Controllern stark in Frage, da es ja genau der Sinn eines RODC war, so wenige Passwörter wie möglich vorhalten zu müssen. In einem Unternehmen mit verteilten Standorten wäre man also gezwungen, alle Passwörter auf alle RODCs zu replizieren, damit eine Authentisierung mit IEEE 802.1X zuverlässig nutzbar wäre.

Fazit

Für eine einwandfreie Funktion und vor Allem für Zukunftssicherheit in Hinsicht auf die Erzwingung der starken Authentisierung durch Microsoft sollten folgende Bedingungen erfüllt sein:

Die Client-Zertifikate sollten einen Subject Alternative Name mit der Identität des anmeldenden Kontos (userPrincipalName bzw. dNSName) enthalten.
Die Client-Zertifikate sollten die neue Security Identifier Zertifikaterweiterung enthalten.
Es sollte keine Änderungen am Standardwert (0x18) von "CertificateMappingMethods" vorgenommen werden.
"StrongCertificateBindingEnforcement" sollte bereits auf "2" gesetzt werden.
Eventuell vorhandene Read-only Domänencontroller benötigen Replikate der Passwörter der Konten, welche sich am entsprechenden Standort mit einem Netzwerkrichtlinienserver authentisieren sollen.

Natürlich muss die Zertifizierungsstelle, welche die Clientzertifikate ausstellt, auch Mitglied in NTAuthCertificates sein. Interessanterweise scheint es bei der EAP-Anmeldung über den Netzwerkrichtlinienserver jedoch nicht erforderlich zu sein, dass Domänencontroller über gültige Zertifikate verfügen.

Weitere relevante Ereignisprotokolle

Welcher Domänencontroller vom Netzwerkrichtlinienserver verwendet wird, kann aus dessen Ereignisprotokoll ermittelt werden:

A LDAP connection with domain controller DC01.intra.adcslabor.de for domain INTRA is established.

Auf den verbindenen Clients wird im Ereignis mit Nr. 12013 der Quelle Microsoft-Windows-Wired-Autoconfig bzw. Microsoft-Windows-WLAN-Autoconfig der Fehlercode 0x8009030C gemeldet:

EAP Reason: 0x8009030C
EAP Root cause String: The authentication failed because the user certificate required for this network on this computer is invalid

Die Fehlercodes sind in der Headerdatei eaphosterror.h beschrieben.

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)
Advanced troubleshooting 802.1X authentication (Microsoft Corporation)
Data collection for troubleshooting 802.1X authentication (Microsoft Corporation)
Weekend Scripter: Use PowerShell to Synchronize Delegated Admin Passwords (Microsoft Corporation)
EAP Related Error and Information Constants (Microsoft Corporation)
Applications that are compatible with RODCs in Windows Server (Microsoft Corporation, Archivlink)