Network Policy Server (NPS)

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."

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.
As a server for authentication, authorization and accounting (AAA), the company uses the Network Policy Server (NPS) from Microsoft.
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.

Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754)

With the May 10, 2022 patch, Microsoft is attempting to patch a vulnerability in the Active Directory in which the certificate-based enrollment (commonly known as PKINIT or also Smartcard Logon) to close.

The update changes both the behavior of the Certification Authority as well as the behavior of Active Directory when processing certificate-based logins.

About the "Build this from Active Directory information" option for certificate templates

When configuring a certificate template, one must decide on the intended certificate content, i.e., among other things, which identities are confirmed by the certificates and how they are mapped.

In the "Subject Name" tab of the certificate template configuration dialog, you can configure how the identity confirmed by the certificate is mapped.

Migration of an Active Directory integrated certification authority (Enterprise Certification Authority) to another server

Often a certification authority lives significantly longer than the server on which it was installed. Reasons for migrating the certification authority to a new server, i.e. while retaining the data, can be:

Defect or end of life of the server hardware
End of life of the server operating system
Change of the server name

The procedure for migration is described in detail below.

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.