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.
For additional resources and support, see Additional resources.
Frequently asked questions
Q1 Once the CA is updated, must all client authentication certificates be renewed?
A1 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.
Additional resources
For more information about TLS client certificate mapping, see the following articles: