KB5014754: Certificate-based authentication changes on Windows domain controllers

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 through 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>

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>

The SID contained in the new extension of the users certificate does not match the users 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>

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.

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 message will be logged unless the certificate is older than the user. If the certificate is older than the user and Certificate Backdating registry key is not present or the range is outside the backdating compensation, authentication will fail, and an error message will be logged.  If the Certificate Backdating registry key is configured, it will log a warning message in the event log if the dates falls within the backdating compensation.

After you install the May 10, 2022 Windows updates, watch for any warning message that might appear after a month or more. If there are no warning messages, 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.

Unless updated to Audit mode or Enforcement mode by using the StrongCertificateBindingEnforcement registry key earlier, domain controllers will move to Full Enforcement mode when the February 2025 Windows security update is installed. Authentication will be denied if a certificate cannot be strongly mapped. The option to move back to Compatibility mode will remain until September 2025. After this date, the StrongCertificateBindingEnforcement registry key will no longer be supported

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 April 11, 2023.

Once you have installed the February 13, 2024 or later Windows updates on Server 2019 and above and supported clients with the RSAT optional feature installed, the certificate mapping in Active Directory Users & Computers will default to selecting strong mapping using the X509IssuerSerialNumber instead of weak mapping using the X509IssuerSubject. The setting can still be changed as desired.

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

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.

This registry key will be unsupported after installing updates for Windows released on or after September 2025.​​​​​​​

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 because this will disable all security enhancements. If you set this to 0, you must also set CertificateMappingMethods to 0x1F as described in the Schannel registry key section below for computer certificate-based authentication to succeed..
Restart Required?	No

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	HKEY_LOCAL_MACHINE\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 the "Additional resources" section.

After you install updates which address CVE-2022-26931 and CVE-2022-26923, authentication might fail in cases where the user certificates are older than the users creation time. This registry key allows successful authentication when you are using weak certificate mappings in your environment and the certificate time is before the user creation time within a set range. This registry key does not affect users or machines with strong certificate mappings, as the certificate time and user creation time are not checked with strong certificate mappings. This registry key does not have any effect when StrongCertificateBindingEnforcement is set to 2.

Using this registry key is a temporary workaround for environments that require it and must be done with caution. Using this registry key means the following for your environment:

• This registry key only works in Compatibility mode starting with updates released May 10, 2022. Authentication will be allowed within the backdating compensation offset but an event log warning will be logged for the weak binding.

• Enabling this registry key allows the authentication of user when the certificate time is before the user creation time within a set range as a weak mapping. Weak mappings will be unsupported after installing updates for Windows released on or after September 2025.

Registry Subkey	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	CertificateBackdatingCompensation
Data Type	REG_DWORD
Data	Values for workaround in approximate years: 50 years: 0x5E0C89C0 25 years: 0x2EFE0780 10 years: 0x12CC0300 5 years: 0x9660180 3 years: 0x5A39A80 1 year: 0x1E13380 Note If you know the lifetime of the certificates in your environment, set this registry key to slightly longer than the certificate lifetime.  If you do not know the certificate lifetimes for your environment, set this registry key to 50 years. Defaults to 10 minutes when this key is not present, which matches Active Directory Certificate Services (ADCS). The maximum value is 50 years (0x5E0C89C0). This key sets the time difference, in seconds, that the Key Distribution Center (KDC) will ignore between an authentication certificate issue time and account creation time for user/machine accounts. Important Only set this registry key if your environment requires it. Using this registry key is disabling a security check.
Restart Required?	No

You run the following certutil command to exclude certificates of the user template from getting the new extension.

1. Sign in to a Certificate Authority server or a domain-joined Windows 10 client with enterprise administrator or the equivalent credentials.

2. Open a command prompt and choose to Run as administrator.

3. 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:

1. You confirm that the corresponding certificates are not acceptable for Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol authentications at KDC

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

For additional resources and support, see the "Additional resources" section.

No, renewal is not required. The CA will ship in Compatibility mode. If you want a strong mapping using the ObjectSID extension, you will need a new certificate.

In the February 11, 2025 Windows update, devices that are not already in Enforcement (StrongCertificateBindingEnforcement registry value is set to 2), will be moved to Enforcement. If authentication is denied, you will see Event ID 39 (or Event ID 41 for Windows Server 2008 R2 SP1 and Windows Server 2008 SP2). You will have the option to set the registry key value back to 1 (Compatibility mode) at this stage.

In the September 10, 2025 Windows update, the StrongCertificateBindingEnforcement registry value will no longer be supported. ​​​​​​​