Logins via the Network Policy Server (NPS) fail with the reason "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."

Assume the following scenario:

A certificate-based login is performed with user or computer accounts to connect them to a wireless (IEEE 802.11 or Wireless LAN) or wired network (IEEE 802.3), or a remote access connection (e.g. DirectAccess, Routing and Remote Access (RAS), Always on VPN) to register.
The company uses Microsoft's Network Policy Server (NPS) as its Authentication, Authorization and Accounting (AAA) server.
Logging on to the network is no longer possible.
The network policy server logs the following event when a login attempt is made:

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.

The network policy server has denied access to a user. [...] Authentication error due to mismatch of user credentials. The specified username is not associated with an existing user account, or the password was incorrect.

Microsoft has with the patch of May 10, 2022, a change to the processing of certificate-based logins against the Active Directory introduced.

The certification authority enters a new certificate extension in issued certificates, which contains the security identifier (objectSid) of the corresponding account.
Domain controllers expect the new certificate extension in issued certificates, but are in a compatibility mode until May 09, 2023.
The SChannel library now only applies certain methods classified as "secure" to map identities from certificates back to Active Directory identities.

In this context, possible causes of failed logins to the network policy server are discussed below.

The connections

Before we explain the possible cause, let's first get an overview of the components involved.

A user or a computer wants to authenticate itself to an access point. An access point here can be, for example, a VPN gateway, a switch, or a wireless access point.
The access point passes the authentication request to the AAA server (in our case, the network policy service).
This in turn checks the certificate used, associates the identity contained in the certificate with an associated Active Directory object, and forwards the authentication to a domain controller. The client is now able to perform a PKINIT operation (also known as smartcard logon) against the domain controller.

It should be noted here that certificates are used at various points in this construct:

For the logging in users or computers.
At the network policy server.
At the domain controller.

Possible sources of error

Certificate content is not compatible

The client certificate must contain a Subject Alternative Name that represents the identity of the connecting account. For user accounts this is the userPrincipalName, for computer accounts it is the dNSName.

The client certificate also requires the newly introduced the SID certificate extension or the certificate must be added to the alternate identities of the associated user or computer account in Active Directory.

For certificate requests that are not made via autoenrollment (for example, if they are requested via a mobile device management such as AirWatch, MobileIron or Intune), Microsoft does not yet have a viable solution to ensure that the resulting certificates will contain the new Security Identifier certificate extension. However, it can be conveniently used for such cases with the TameMyCerts Policy Module for the Microsoft Certification Authority be brought into the certificates issued.

Method for certificate mapping is not configured appropriately

This change affects not only logins to the Network Policy Server (NPS), but also those to IIS web servers that use certificates.

Through the Patch for Windows Server dated May 10, 2022 (KB5014754) the underlying SChannel library was configured with a new default value for mapping the identity in the certificate to the associated Active Directory account.

It is located in the CertificateMappingMethods value below the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\SecurityProviders\Schannel

The value is not present in the default setting. In this case, "0x1F" was assumed up to the May 2022 patch, and "0x18" thereafter. This is a bit mask which can be configured as follows:

Bit	Setting	Method	Strength assessment
1	0x0001	Subject/Issuer certificate mapping	weak
2	0x0002	Issuer certificate mapping	weak
3	0x0004	UPN certificate mapping	weak
4	0x0008	S4U2Self certificate mapping	strong
5	0x0010	S4U2Self explicit certificate mapping	strong

Any changes are made on the domain controllers (not on the network policy server). A change requires a restart of the "KDC" service on the domain controller.

The old default value of 0x1F (Binary 0001 1111) had all of the above methods enabled.

However, the new default value 0x18 (0001 1000) only activates the two "strong" methods.

It is also important to understand that the methods are processed in order. If, for example, the first bit (Subject/Issuer mapping) is activated (and the Subject Disinguished Name in the certificate is filled correctly), this method is preferred over a "secure" method that may also be activated. In this case, no S4U2Self-based logon is performed, and the StrongCertificateBindingEnforcement has no effect on the domain controllers.

If the Security Identifier certificate extension is missing

If the certificate used by the connecting client does not have the new Security Identifier certificate extension (or if there is no explicit mapping to the certificate), then the certificate is not used. altSecurityIdentities attribute of the account configured), an event is generated on the domain controller that processed the logon with No. 39 of the source Kerberos Key Distribution Center logged:

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.

The event with the number 39 of the source Microsoft-Kerberos-Key-Distribution-Center would occur in case of a login failure only if the authentication gets through to here at all (see previous section on certificate mapping on the network policy server.

The event can be of type "Warning" and of type "Error", but only the type "Error" indicates that the login was rejected due to the Security Identifier certificate extension.

The May 10, 2022 patch introduced a new registry value called StrongCertificateBindingEnforcement (type DWORD).

The value is located on the domain controllers in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Value	Description
0	Logins with certificates without SID attribute will be not logged and approved.
1	Logins with certificates without SID attribute are logged and allowed. (Default setting)
2	Logins with certificates without SID attribute are logged and not approved.

A change requires a restart of the "KDC" service on the domain controller.

By default, the value is not present (in this case, the value 1 is assumed). If you change the value to "2", corresponding logins are rejected and logged accordingly on the domain controller.

Microsoft Intendsto set this value hard to "2" as of 09 May 2023, i.e. no other forms of registration will be accepted as of this date.

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

Special case read-only domain controller

The event with the number 39 of the source Microsoft-Kerberos-Key-Distribution-Center does not occur in this case.

For a S4U2Self based login, as it has been since the patch and at the latest to the date planned by Microsoft to enforce is mandatory, a read-only domain controller requires a replica of the account's password.

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

Thus, the account in question must have authenticated at least once on each read-only domain controller that can be used by the network policy server before it can be used for certificate-based logon. Alternatively, the password must be synchronized in advance.

This change strongly questions the purpose of read-only domain controllers, since it was exactly the purpose of an RODC to have to keep as few passwords as possible. In a company with distributed locations, one would therefore be forced to replicate all passwords on all RODCs so that authentication with IEEE 802.1X could be used reliably.

Conclusion

The following conditions should be met for proper functioning and, above all, for future security with regard to the enforcement of strong authentication by Microsoft:

The client certificates should contain a Subject Alternative Name with the identity of the logon account (userPrincipalName or dNSName).
The client certificates should contain the new Security Identifier certificate extension.
No changes should be made to the default value (0x18) of CertificateMappingMethods.
"StrongCertificateBindingEnforcement" should already be set to "2".
Any read-only domain controllers require replicas of the accounts' passwords.

Of course, the certificate authority issuing the client certificates must also be a member of NTAuthCertificates. Interestingly, however, EAP logon via the network policy server does not seem to require domain controllers to have valid certificates.

Other relevant event logs

Which domain controller is used by the network policy server can be determined from its event log:

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

On the connected clients, the error code 0x8009030C is reported in the event with no. 12013 of the source Microsoft-Windows-Wired-Autoconfig or 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

The error codes are described in the eaphosterror.h header file.

Logins via the Network Policy Server (NPS) fail with reason "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."