Les connexions via le serveur de stratégie réseau (NPS) échouent avec la raison suivante : "Authentication failed due to a user credentials mismatch. Soit le nom d'utilisateur fourni ne correspond pas à un compte utilisateur existant, soit le mot de passe était incorrect".

Supposons le scénario suivant :

Une connexion basée sur un certificat est effectuée avec des comptes d'utilisateur ou d'ordinateur pour les connecter à un réseau sans fil (IEEE 802.11 ou Wireless LAN) ou câblé (IEEE 802.3), ou une connexion d'accès à distance (par ex. DirectAccess, Routing and Remote Access (RAS), VPN toujours en ligne).
L'entreprise utilise comme serveur d'authentification, d'autorisation et de comptabilité (AAA) le Serveur de politiques de réseau (en anglais Network Policy Server NPS) de Microsoft.
La connexion au réseau n'est plus possible.
Le serveur de stratégie réseau consigne l'événement suivant lorsqu'une tentative de connexion est effectuée :

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.

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Microsoft a avec le correctif du 10 mai 2022, une modification du traitement des ouvertures de session basées sur des certificats contre Active Directory a été introduite.

L'autorité de certification inscrit une nouvelle extension de certificat dans les certificats émis, qui contient l'identifiant de sécurité (objectSid) du compte correspondant.
Les contrôleurs de domaine attendent la nouvelle extension de certificat dans les certificats émis, mais se trouvent dans un mode de compatibilité jusqu'au 09 mai 2023.
La bibliothèque SChannel n'applique plus que certaines méthodes considérées comme "sûres" pour remapper les identités issues de certificats sur les identités Active Directory.

Dans ce contexte, les causes possibles des échecs de connexion au serveur de stratégie réseau sont abordées ci-dessous.

Les liens

Avant d'expliquer les causes possibles, donnons d'abord un aperçu des composants impliqués.

Un utilisateur ou un ordinateur souhaite s'authentifier auprès d'un point d'accès. Un point d'accès peut être par exemple une passerelle VPN, un commutateur ou un point d'accès sans fil.
Le point d'accès transmet la demande d'authentification au serveur AAA (dans notre cas, le service de stratégie réseau).
Celui-ci vérifie à son tour le certificat utilisé, associe l'identité contenue dans le certificat à un objet Active Directory correspondant et transmet l'authentification à un contrôleur de domaine. Le client est alors en mesure d'effectuer une opération PKINIT (également connue sous le nom de Smartcard Logon) vis-à-vis du contrôleur de domaine.

Il convient de noter que dans cette construction, les certificats sont utilisés à différents endroits :

Auprès des utilisateurs ou des ordinateurs qui se connectent.
Sur le serveur de stratégie réseau.
Au niveau du contrôleur de domaine.

Sources d'erreur possibles

Le contenu du certificat n'est pas compatible

Le certificat client doit contenir un Subject Alternative Name qui représente l'identité du compte de connexion. Pour les comptes d'utilisateurs, il s'agit du userPrincipalName, pour les comptes d'ordinateurs, du dNSName.

Le certificat client nécessite également l'extension de certificat SID récemment introduite ou le certificat doit être ajouté aux identités alternatives du compte d'utilisateur ou d'ordinateur correspondant dans Active Directory.

Pour les demandes de certificats qui ne sont pas effectuées par auto-enrollment (par exemple lorsqu'elles sont demandées via un Mobile Device Management comme AirWatch, MobileIron ou Intune), Microsoft n'a jusqu'à présent pas de solution utilisable pour garantir que les certificats qui en résultent contiennent la nouvelle extension Security Identifier Certificate. Elle peut toutefois, dans de tels cas, facilement avec le module TameMyCerts Policy pour l'autorité de certification Microsoft être apportées aux certificats délivrés.

La méthode de mappage des certificats n'est pas configurée de manière appropriée

Cette modification concerne non seulement les connexions au serveur de stratégie réseau (NPS), mais aussi celles aux serveurs web IIS qui utilisent des certificats.

Grâce à la Correctif du 10 mai 2022 pour Windows Server (KB5014754) la bibliothèque SChannel sous-jacente a été configurée avec une nouvelle valeur par défaut pour l'attribution de l'identité dans le certificat au compte Active Directory correspondant.

Il se trouve dans la valeur "CertificateMappingMethods" sous la clé de registre suivante :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel

Par défaut, cette valeur n'existe pas. Dans ce cas, "0x1F" a été adopté jusqu'au patch de mai 2022, puis "0x18". Il s'agit ici d'un masque de bits qui peut être configuré comme suit :

Bit	Réglage	Méthode	Évaluation de la force
1	0x0001	Subject/Issuer certificat mapping	faible
2	0x0002	Mappage du certificat d'émetteur	faible
3	0x0004	Cartographie des certificats UPN	faible
4	0x0008	S4U2Self mapping des certificats	fort
5	0x0010	S4U2Self explicit certificate mapping	fort

Les éventuelles modifications sont effectuées sur les contrôleurs de domaine (et non sur le serveur de stratégie réseau). Une modification nécessite un redémarrage du service "KDC" sur le contrôleur de domaine.

L'ancienne valeur par défaut de 0x1F (binaire 0001 1111) avait activé toutes les méthodes mentionnées.

La nouvelle valeur par défaut 0x18 (0001 1000) n'active toutefois plus que les deux méthodes "fortes".

Il est également important de comprendre que les méthodes sont traitées dans l'ordre. Si, par exemple, le premier bit (Subject/Issuer mapping) est activé (et si le Subject Disinguished Name est correctement rempli dans le certificat), cette méthode est préférée à une méthode "sûre" qui pourrait également être activée. Dans ce cas, aucune inscription basée sur S4U2Self n'est effectuée et le StrongCertificateBindingEnforcement n'a donc aucun effet sur les contrôleurs de domaine.

Si l'extension du certificat Security Identifier est manquante

Si le certificat utilisé par le client connecté ne dispose pas de la nouvelle extension de certificat Security Identifier (ou s'il n'y a pas d'attribution explicite via le altSecurityIdentities du compte), le contrôleur de domaine qui a traité l'ouverture de session reçoit un événement appelé No 39 de la source Centre de distribution de clés Kerberos sont consignées :

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.

L'événement n° 39 de la source Microsoft-Kerberos-Key-Distribution-Center ne se produirait en cas d'erreur de connexion que si l'authentification parvenait à passer jusqu'ici (voir la section précédente sur la cartographie des certificats sur le serveur de stratégie réseau.

L'événement peut être de type "avertissement" ou de type "erreur", mais seul le type "erreur" indique que l'inscription a été refusée en raison de l'extension du certificat Security Identifier.

Le correctif du 10 mai 2022 a introduit une nouvelle valeur de registre appelée "StrongCertificateBindingEnforcement" (type DWORD).

La valeur se trouve à l'emplacement suivant sur les contrôleurs de domaine :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Valeur	Description
0	Les inscriptions avec des certificats sans attribut SID seront pas protocolées et autorisées.
1	Les connexions avec des certificats sans attribut SID sont consignées et autorisées. (paramètre par défaut)
2	Les connexions avec des certificats sans attribut SID sont consignées et pas admis.

Une modification nécessite un redémarrage du service "KDC" sur le contrôleur de domaine.

Par défaut, cette valeur n'existe pas (dans ce cas, la valeur 1 est acceptée). Si l'on modifie la valeur à "2", les inscriptions correspondantes sont refusées et consignées en conséquence sur le contrôleur de domaine.

Microsoft a l'intentionLe Conseil d'administration a décidé de fixer cette valeur à "2" au 09 mai 2023, ce qui signifie qu'aucune autre forme d'inscription ne sera acceptée à partir de cette date.

Si un certificat ne peut pas être mis en correspondance de manière stricte, l'authentification sera refusée.
KB5014754 : Changements d'authentification basés sur les certificats sur les contrôleurs de domaine Windows

Cas particulier des contrôleurs de domaine en lecture seule

L'événement n° 39 de la source Microsoft-Kerberos-Key-Distribution-Center n'est pas consigné dans ce cas.

Pour une inscription basée sur S4U2Self, comme c'est le cas depuis le patch et au plus tard au date prévue par Microsoft pour imposer est obligatoire, un contrôleur de domaine en lecture seule a besoin d'une réplique du mot de passe du compte.

Le NPS peut authentifier la connexion au service de routage et d'accès à distance (RRAS) uniquement pour les comptes qui sont répliqués vers le RODC.
Applications compatibles avec les RODC dans Windows Server

Ainsi, le compte en question doit s'être authentifié au moins une fois sur chaque contrôleur de domaine en lecture seule utilisable par le serveur de stratégie réseau pour pouvoir être utilisé pour l'ouverture de session basée sur un certificat. Sinon, le mot de passe doit être synchronisé au préalable.

Cette modification remet fortement en question l'objectif des contrôleurs de domaine en lecture seule, car le but d'un RODC était précisément de devoir conserver le moins de mots de passe possible. Dans une entreprise avec des sites répartis, on serait donc obligé de répliquer tous les mots de passe sur tous les RODC pour qu'une authentification avec IEEE 802.1X soit utilisable de manière fiable.

Conclusion

Les conditions suivantes doivent être remplies pour un fonctionnement correct et surtout pour la sécurité future en ce qui concerne l'authentification forte imposée par Microsoft :

Les certificats clients doivent contenir un Subject Alternative Name avec l'identité du compte qui se connecte (userPrincipalName ou dNSName).
Les certificats clients doivent contenir la nouvelle extension de certificat Security Identifier.
Aucune modification ne doit être apportée à la valeur par défaut (0x18) de "CertificateMappingMethods".
"StrongCertificateBindingEnforcement" devrait déjà être réglé sur "2".
Les éventuels contrôleurs de domaine en lecture seule nécessitent des répliques des mots de passe des comptes qui doivent s'authentifier sur le site correspondant avec un serveur de stratégie réseau.

Bien entendu, l'autorité de certification qui délivre les certificats clients doit également être membre de NTAuthCertificates. Cependant, il est intéressant de noter que pour la connexion EAP via le serveur de stratégie réseau, il ne semble pas nécessaire que les contrôleurs de domaine disposent de certificats valides.

Autres journaux d'événements pertinents

Le contrôleur de domaine utilisé par le serveur de stratégie réseau peut être déterminé à partir de son journal d'événements :

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

Sur les clients connectés, le code d'erreur 0x8009030C est signalé dans l'événement n° 12013 de la source Microsoft-Windows-Wired-Autoconfig ou Microsoft-Windows-WLAN-Autoconfig :

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

Les codes d'erreur sont indiqués dans le fichier d'en-tête eaphosterror.h décrites.

Liens complémentaires :

Sources externes

KB5014754-Changements d'authentification basés sur les certificats sur les contrôleurs de domaine Windows (Microsoft Corporation)
Les protocoles Windows : Ce qui est nouveau et ce qui a changé (Microsoft Corporation)
May 2022 - Vous pouvez voir des échecs d'authentification sur le serveur ou le client pour les services (Microsoft Corporation)
Dépannage avancé de l'authentification 802.1X (Microsoft Corporation)
Collecte de données pour le dépannage de l'authentification 802.1X (Microsoft Corporation)
Week-end Scripter : Utiliser PowerShell pour synchroniser les mots de passe délégués des administrateurs (Microsoft Corporation)
Constantes d'erreur et d'information liées à l'EAP (Microsoft Corporation)
Applications compatibles avec les RODC dans Windows Server (Microsoft Corporation, lien vers l'archive)