KB5014754—Certificate-based authentication changes on Windows domain controllers

Summary

CVE-2022-26931 and CVE-2022-26923 address an elevation of privilege vulnerability that can occur when the Kerberos Distribution Center (KDC) is servicing a certificate-based authentication request. Before the May 10, 2022 security update, certificate-based authentication would not account for a dollar sign ($) at the end of a machine name. This allowed related certificates to be emulated (spoofed) in various ways. Additionally, conflicts between User Principal Names (UPN) and sAMAccountName introduced other emulation (spoofing) vulnerabilities that we also address with this security update.

Take action

To protect your environment, complete the following steps for certificate-based authentication:

Update all servers that run Active Directory Certificate Services and Windows domain controllers that service certificate-based authentication with the May 10, 2022 update (see Compatibility Mode). The May 10, 2022 update will provide audit events that identify certificates that are not compatible with Full Enforcement Mode.
If no audit event logs are created on domain controllers for one month after installing the update, proceed with enabling Full Enforcement Mode on all domain controllers. By May 9, 2023, all devices will be updated to Full Enforcement Mode. In this mode, if a certificate fails the strong (secure) mapping criteria (see Certificate mappings), authentication will be denied.

Audit events

The May 10, 2022 Windows update will add the following event logs.

No strong mapping

No strong certificate mappings could be found, and the certificate did not have the new security identifier (SID) extension that the KDC could validate.

Event Log	System
Event Type	Warning if the KDC is in Compatibility Mode Error if the KDC is in Enforcement Mode
Event Source	Kdcsvc
Event ID	39 41 (For Windows Server 2008 R2 SP1 and Windows Server 2008 SP2)
Event Text	The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong 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. User: <principal name> Certificate Subject: <Subject name in Certificate> Certificate Issuer: <Issuer Fully Qualified Domain Name (FQDN)> Certificate Serial Number: <Serial Number of Certificate> Certificate Thumbprint: <Thumbprint of Certificate>

Certificate predates account

The certificate was issued to the user before the user existed in Active Directory and no strong mapping could be found. This event is only logged when the KDC is in Compatibility Mode.

Event Log	System
Event Type	Error
Event Source	Kdcsvc
Event ID	40 48 (For Windows Server 2008 R2 SP1 and Windows Server 2008 SP2
Event Text	The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID). The certificate also predated the user it mapped to, so it was rejected. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more. User: <principal name> Certificate Subject: <Subject name in Certificate> Certificate Issuer: <Issuer FQDN> Certificate Serial Number: <Serial Number of Certificate> Certificate Thumbprint: <Thumbprint of Certificate> Certificate Issuance Time: <FILETIME of certificate> Account Creation Time: <FILETIME of principal object in AD>

User’s SID does not match Certificate SID

The SID contained in the new extension of the user’s certificate does not match the user’s SID, implying that the certificate was issued to another user.

Event Log	System
Event Type	Error
Event Source	Kdcsvc
Event ID	41 49 (For Windows Server 2008 R2 SP1 and Windows Server 2008 SP2)
Event Text	The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed. See https://go.microsoft.cm/fwlink/?linkid=2189925 to learn more. User: <principal name> User SID: <SID of the authenticating principal> Certificate Subject: <Subject name in Certificate> Certificate Issuer: <Issuer FQDN> Certificate Serial Number: <Serial Number of Certificate> Certificate Thumbprint: <Thumbprint of Certificate> Certificate SID: <SID found in the new Certificate Extension>

Certificate mappings

Domain administrators can manually map certificates to a user in Active Directory using the altSecurityIdentities attribute of the user’s Object. There are six supported values for this attribute, with three mappings considered weak (insecure) and the other three considered strong. In general, mapping types are considered strong if they are based on identifiers that you cannot reuse. Therefore, all mapping types based on usernames and email addresses are considered weak.

Mapping	Example	Type	Remarks
X509IssuerSubject	“X509:<I>IssuerName<S>SubjectName”	Weak
X509SubjectOnly	“X509:<S>SubjectName”	Weak
X509RFC822	“X509:<RFC822>user@contoso.com”	Weak	Email Address
X509IssuerSerialNumber	“X509:<I>IssuerName<SR>1234567890”	Strong	Recommended
X509SKI	“X509:<SKI>123456789abcdef”	Strong
X509SHA1PublicKey	“X509:<SHA1-PUKEY>123456789abcdef”	Strong

If customers cannot reissue certificates with the new SID extension, Microsoft recommends that you create a manual mapping using one of the strong mappings described above. You can do this by adding the appropriate mapping string to a user’s altSecurityIdentities attribute in Active Directory.

Note Certain fields, such as Issuer, Subject, and Serial Number, are reported in a “forward” format. You must reverse this format when you add the mapping string to the altSecurityIdentities attribute. For example, to add the X509IssuerSerialNumber mapping to a user, search the “Issuer” and “Serial Number” fields of the certificate that you want to map to the user. See the sample output below.

Issuer: CN=CONTOSO-DC-CA, DC=contoso, DC=com

SerialNumber: 2B0000000011AC0000000012

Then, update the user’s altSecurityIdentities attribute in Active Directory with the following string:

“X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B”

To update this attribute using Powershell, you might use the command below. Keep in mind that, by default, only domain administrators have the permission to update this attribute.

set-aduser ‘DomainUser’ -replace @{altSecurityIdentities= “X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B”}

Note that when you reverse the SerialNumber, you must keep the byte order. This means that reversing the SerialNumber “A1B2C3” should result in the string “C3B2A1” and not “3C2B1A”. For more information, see HowTo: Map a user to a certificate via all the methods available in the altSecurityIdentities attribute.

Timeline for Windows Updates

Compatibility Mode

Once you have installed the May 10, 2022 Windows updates, devices will be in Compatibility Mode. If a certificate can be strongly mapped to a user, authentication will occur as expected. If a certificate can only be weakly mapped to a user, authentication will occur as expected. However, a warning will be logged unless the certificate is older than the user. If the certificate is older than the user, authentication will fail, and an error will be logged.

After you install the May 10, 2022 Windows updates, watch for any warnings that might appear after a month or more. If there are no warnings, we strongly recommend that you enable Full Enforcement Mode on all domain controllers using certificate-based authentication. You can use the KDC registry key to enable Full Enforcement Mode.

Full Enforcement Mode

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.

Disabled Mode

If certificate-based authentication relies on a weak mapping that you cannot move from the environment, you can place domain controllers in Disabled Mode using a registry key setting. Microsoft does not recommend this, and we will remove Disabled Mode on February 14, 2023.

Troubleshooting

Failure to sign in after installing CVE-2022-26931 and CVE-2022-26923 protections

Use the Kerberos Operational log on the relevant computer to determine which domain controller is failing the sign in. Go to Event Viewer > Applications and Services Logs\Microsoft \Windows\Security-Kerberos\Operational.
Look for relevant events in the System Event Log on the domain controller that the account is attempting to authenticate against.
If the certificate is older than the account, reissue the certificate or add a secure altSecurityIdentities mapping to the account (see Certificate mappings).
If the certificate contains a SID extension, verify that the SID matches the account.
If the certificate is being used to authenticate several different accounts, each account will need a separate altSecurityIdentities mapping.
If the certificate does not have a secure mapping to the account, add one or leave the domain in Compatibility Mode until one can be added.

Failure to authenticate using Transport Layer Security (TLS) certificate mapping

An example of TLS certificate mapping is using an IIS intranet web application.

After installing CVE-2022-26391 and CVE-2022-26923 protections, these scenarios use the Kerberos Certificate Service For User (S4U) protocol for certificate mapping and authentication by default.
In the Kerberos Certificate S4U protocol, the authentication request flows from the application server to the domain controller, not from the client to the domain controller. Therefore, relevant events will be on the application server.

Registry key information

After you install CVE-2022-26931 and CVE-2022-26923 protections in the Windows updates released between May 10, 2022 and May 9, 2023, the following registry keys will be available.

Key Distribution Center registry key

This registry key changes the enforcement mode of the KDC to Disabled Mode, Compatibility Mode, or Full Enforcement Mode.

Registry Subkey	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	StrongCertificateBindingEnforcement
Data Type	REG_DWORD
Data	1 – Checks if there is a strong certificate mapping. If yes, authentication is allowed. Otherwise, the KDC will check if the certificate has the new SID extension and validate it. If this extension is not present, authentication is allowed if the user account predates the certificate. 2 – Checks if there’s a strong certificate mapping. If yes, authentication is allowed. Otherwise, the KDC will check if the certificate has the new SID extension and validate it. If this extension is not present, authentication is denied. 0 – Disables strong certificate mapping check. Not recommended.
Restart Required?	No

SChannel registry key

When a server application requires client authentication, Schannel automatically attempts to map the certificate that the TLS client supplies to a user account. You can authenticate users who sign in with a client certificate by creating mappings that relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate, your server application automatically associates that user with the appropriate Windows user account.

Schannel will try to map each certificate mapping method you have enabled until one succeeds. Schannel tries to map the Service-For-User-To-Self (S4U2Self) mappings first. The Subject/Issuer, Issuer, and UPN certificate mappings are now considered weak and have been disabled by default. The bitmasked sum of the selected options determines the list of certificate mapping methods that are available.

The SChannel registry key default was 0x1F and is now 0x18. If you experience authentication failures with Schannel-based server applications, we suggest that you perform a test. Add or modify the CertificateMappingMethods registry key value on the domain controller and set it to 0x1F and see if that addresses the issue. Look in the System event logs on the domain controller for any errors listed in this article for more information. Keep in mind that changing the SChannel registry key value back to the previous default (0x1F) will revert to using weak certificate mapping methods.

Registry Subkey	HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel\
Value	CertificateMappingMethods
Data Type	DWORD
Data	0x0001 - Subject/Issuer certificate mapping (weak – Disabled by default) 0x0002 - Issuer certificate mapping (weak – Disabled by default) 0x0004 - UPN certificate mapping (weak – Disabled by default) 0x0008 - S4U2Self certificate mapping (strong) 0x0010 - S4U2Self explicit certificate mapping (strong)
Restart Required?	No

For additional resources and support, see Additional resources.

Enterprise Certificate Authorities

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. You can stop the addition of this extension by setting the 0x00080000 bit in the msPKI-Enrollment-Flag value of the corresponding template. For example, you run the following certutil command to exclude certificates of the user template from getting the new extension.

Sign in to a Certificate Authority server or a domain-joined Windows 10 client with enterprise administrator or the equivalent credentials.
Open a command prompt and choose to Run as administrator.
Run certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

Disabling the addition of this extension will remove the protection provided by the new extension. Consider doing this only after one of the following:

You confirm that the corresponding certificates are not acceptable for Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol authentications at KDC
The corresponding certificates have other strong certificate mappings configured

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.