UPDATED
-
12/8/22: Changed Full Enforcement Mode date from May 9, 2023 to November 14, 2023, or later
-
1/26/23: Changed removal of Disabled mode from February 14, 2023 to April 11, 2023
Summary
CVE-2022-34691, 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 theMay 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) andsAMAccountNameintroduced 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 November 14, 2023, or later,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 addsthe following event logs.
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 SIDcontained 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> |
Certificate mappings
Domain administrators can manually map certificates to a user in Active Directory using the altSecurityIdentities attribute of the users Object. There are six supported values for thisattribute, 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, we recommendthat you create a manual mapping by using one of the strong mappings described above. You can do this by adding the appropriate mapping string to a users 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
ImportantThe Enablement Phase starts with the February 14, 2023 updates for Windows, which will ignore the Disabled mode registry key setting.
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 messagethat 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 this mode earlier, we will update all devices to Full Enforcement mode by November 14, 2023, or later. If a certificate cannot be strongly mapped, authentication will be denied.
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.
Troubleshooting
-
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.
Registry key information
After you install CVE-2022-26931 and CVE-2022-26923 protections in the Windows updates released between May 10, 2022 and November 14, 2023, or later, the following registry keys are available.
This registry key changes the enforcement mode of the KDC to Disabled mode, Compatibility mode, or Full Enforcement mode.
Important
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 inCompatibility modestarting with updates released May 10, 2022.
-
This registry key will be unsupported after installing updates for Windows released on November 14, 2023, or later, which will enableFull 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 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 TLSclient 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 November 14, 2023, or later, which will enable Full Enforcement mode.
| Registry Subkey | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc |
| Value | CertificateBackdatingCompensation |
| Data Type | REG_DWORD |
| Data | Values for workaround in approximate years:
NoteIf 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. ImportantOnly set this registry key if your environment requires it. Using this registry key is disabling a security check. |
| Restart Required? | No |
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.
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 -dstemplateuser 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 the "Additional resources" section.
Frequently asked questions
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:
-
Transport Layer Security (TLS) registry settings
-
IIS Client Certificate Mapping Authentication <iisClientCertificateMappingAuthentication>
-
Configuring One-to-One Client Certificate Mappings
-
Many-To-One Mappings <manyToOneMappings>
-
Securing Public Key Infrastructure (PKI)
-
Active Directory Certificate Services: Enterprise CA Architecture - TechNet Articles - United States (English) - TechNet Wiki
