Enable strong name-based mapping in government scenarios

If you work in smartcard federated authentication environments, here’s a much-anticipated security feature for you. Starting with the September 10, 2024 Windows security update, you can use strong name-based mapping on Windows Server 2019 and newer. This feature helps you with the hardening changes for certificate-based authentication on Windows domain controllers. 

 

What are weak and strong mappings in Active Directory? 

All certificate names must be correctly mapped onto the intended user account in Active Directory (AD). If there’s a likelihood that they aren’t, we call these mappings weak. Weak mappings give rise to security vulnerabilities and demand hardening measures such as Certificate-based authentication changes on Windows domain controllers.  

 

Following up on our May 2022 round of updates to address these vulnerabilities, we’re introducing a new feature called strong name-based mapping. You can now distinguish between “strong” and “weak” mappings within existing Alternative Security Identities (AltSecIDs) based on likelihood. With the new feature, you can allow some weak name-based mappings to be treated as strong name-based mappings. You just need to properly configure both the public key infrastructure (PKI) and the AD deployment. 

 

Key features and benefits of strong name-based mapping 

Strong name-based mapping has two main benefits: 

• Compliance with strong certificate mapping enforcement. Strong name-based mapping allows certain weak certificate mappings, such as Issuer/Subject AltSecID and User Principal Names (UPN) mappings, to be treated as strong mappings. This type of strong mapping is compatible with the enforcement mode of certificate-based authentication changes on Windows domain controllers.  
• Compatibility with government PKI deployments. Strong name-based mappings work by asking PKI deployments to attest certain security guarantees of certificates via object identifiers (OIDs) stamped on the certificate. It’s a common practice among government PKI and AD deployments.  

Security requirements for PKI deployments for strong name-based mapping 

Warning  

Unless you have a strong need for this type of deployment AND have a deep knowledge of how PKI deployments and AD authentication interact together, we DO NOT recommend deploying strong name-based mapping. We instead recommend that you following the guidance in KB5014754: Certificate-based authentication changes on Windows domain controllers.  

 

 

Fundamentally, strong name-based mapping deployment is your promise to Microsoft that your PKI is not susceptible to the attacks addressed by May 2022 and later updates. Namely, you take responsibility for the vulnerabilities that can arise from any unintentional mapping of the names in a certificate to multiple AD accounts. 

 

To prevent unintentional and unsafe mappings, we recommend that you take steps to strengthen your PKI and AD deployments. Some of these steps include:  

• Names used in either the Subject Name and/or the Subject Alternative Name of certificates MUST NOT contain names that are queried and/or built from AD. 
• Names used in either the Subject Name and/or the Subject Alternative Name of certificates MUST be both immutable and globally unique to the entire PKI deployment.  
• AD and PKI administrators must ensure that certificate issuance for logons is not automatic. Instead, ensure that strong manual checks are in place to prevent a certificate with an incorrect or clashing name from being issued.  

Failing to secure your PKI and AD deployments can degrade the security of your environment.  

 

If your PKI meets or exceeds these security requirements, you MUST add an OID in the Issuance Policy of the certificate to denote this compliance. This OID (or multiple OIDs) will be used further below in the strong name-based mapping configuration.  

 

Setup instructions 

To enable strong name-based mapping on Windows Server 2019 and later, you need to take the following steps: 

1. Enable the Group Policy (GPO) Setting on the Domain Controllers: 
   Computer Configuration > Administrative Template > System > KDC > “Allow name-based strong mappings for certificates”.  
2. Configure the GPO with the necessary tuples (more details below). 

This configuration relies on adding tuples to the GPO when strong name-based mapping is enabled. These tuples tell the Domain Controller which certificates meet the above security requirements by specifying both the Issuer certificate authority (CA) thumbprint and the OID(s) that denote that the PKI deployment is secured against the May 2022 vulnerabilities. Furthermore, the tuples also configure which “weak” name-based mappings can be upgraded to “strong” name-based mappings.  

 

The tuple is in the following format: 
 
<Issuer CA Certificate Thumbprint>;<OID(s)>;<IssuerSubject/UpnSuffix=()> 

1. Issuer CA Certificate Thumbprint: This is the certificate thumbprint of the Issuing CA. There can only be one Issuer CA Thumbprint in this field. If multiple Issuer CA Thumbprints are placed, it can prevent proper processing of the GPO policy. 
2. OID(s): This is a comma-separated list of OIDs that the PKI deployment has stamped on the certificate to attest that the security requirements against name collisions have been met. There can be multiple OIDs denoted in this field.  
3. IssuerSubject/UpnSuffix: This is a comma-separated list to denote what type of weak mapping should be treated as strong: 
   1. IssuerSubject: This string behaves as a tag to denote that the Issuer/SubjectName AltSecID can be upgraded from “weak” to “strong.” There can only be one IssuerSubject tag in this field.  
   2. UPNSuffix: This string denotes that certificate mappings can be upgraded form “weak” to “strong” wherever the UPN suffix of the SubjectName (that is, everything that comes after the @ symbol) matches the suffix in the tuple exactly. There can be multiple UPN suffixes in this field.  

The logic of the tuple is the following. For certificates whose Issuer is X that has any of the OID(s) Y, upgrade any of the weak mappings C to “strong.” This logic is summarized in the diagram. 

 

Flow chart illustrating the logic of strong name-based mapping configuration. The chart starts with a decision diamond asking if the certificate's Issuer Certificate Thumbprint matches the specified thumbprint. If yes, it proceeds to check if the certificate has any of the specified OIDs. If both conditions are met, it allows a strong mapping for the certificate based on either Issuer/SubjectName AltSecID or UPNSuffix, depending on the configuration.

 

Two important configuration details are required for UPN Suffix mapping to work: 

• Certificates must have the UPN of the user in the SAN. 
• Mapping via UPNs has not been disabled via UseSubjectAltName. 

 

How to use and understand policy tuples: a walkthrough 

 

Policy tuple example 1 

Use this policy tuple to allow a strong mapping via Issuer/SubjectName AltSecID. 

fe40a3146d935dc248504d2dcd960d15c4542e6e; 2.16.840.1.101.3.2.1.3.45;IssuerSubject 

 

1. For certificates whose Issuer Certificate Thumbprint is fe40a3146d935dc248504d2dcd960d15c4542e6e, and 
2. The certificate has the OID 2.16.840.1.101.3.2.1.3.45, 
3. Allow a strong mapping if the certificate is mapped via Issuer/SubjectName AltSecID. 

This tuple would allow a certificate logon which passes checks (1) and (2) issued to the user Bob, if the AD object for Bob has the Issuer/SubjectName AltSecID correctly configured for the certificate.  

 

Policy tuple example 2 

Use this policy tuple to allow a strong mapping via a specified UPNSuffix. 

fe40a3146d935dc248504d2dcd960d15c4542e6e; 2.16.840.1.101.3.2.1.3.45;UPNSuffix=corp.contoso.com 

 

1. For certificates whose Issuer Certificate Thumbprint is fe40a3146d935dc248504d2dcd960d15c4542e6e, and 
2. The certificate has the OID 2.16.840.1.101.3.2.1.3.45, 
3. Allow a strong mapping if the certificate is mapped via UPNSuffix, which should be “corp.contoso.com.”  

This tuple would allow a certificate logon which passes checks (1) and (2) issued to the user Bob, if the AD object for Bob has the Issuer/SubjectName AltSecID correctly configured for the certificate.  

 

Policy tuple example 3 

Use this policy tuple to allow a strong mapping via any of the approved specifications. 

fe40a3146d935dc248504d2dcd960d15c4542e6e; 2.16.840.1.101.3.2.1.3.45, 2.16.840.1.101.3.2.1.3.44;UPNSuffix=corp.contoso.com,UPNSuffix=my.corp.contoso.com,IssuerSubject 

 

1. For certificates whose Issuer Certificate Thumbprint is fe40a3146d935dc248504d2dcd960d15c4542e6e, and 
2. The certificate has ANY of the following OIDs: 
   1. 2.16.840.1.101.3.2.1.3.45 
   2. 2.16.840.1.101.3.2.1.3.44 
3. Allow a strong name-based mapping if the certificate is mapped via either of the following: 
   1. The user account in AD has a valid Issuer/SubjectName AltSecID mapping 
   2. UPNSuffix, where the suffix is “corp.contoso.com” 
   3. UPNSuffix, where the suffix is “my.corp.contoso.com” 

Event Log changes 

Two Event Log updates are here to help you as an AD administrator better troubleshoot strong name-based mapping scenarios. These are available to you with the September 10, 2024 and later updates. 

 

Updates to current event logs 

The current event logs now include policy OIDs found on the certificate used for authentication. This modifies the Key Distribution Center (KDC) events introduced by the May 10, 2022 and later updates.  

 

New event logs 

Additionally, a new event is available to log when the strong name-based mapping GPO encounters an issue processing the policy tuples. Track these events through Event ID 311. 

 

Event Log	Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational
Event Type	Error
Event Source	Kerberos-Key-Distribution-Center
Event ID	311
Event Text	The Key Distribution Center (KDC) encountered invalid certificate strong name match policy.    Faulting line: <line number>

 

Ready to improve Windows Server security? 

We’re excited to bring this feature to your government scenario. Consider strong name-based mappings on Active Directory and PKI deployments in Windows Server 2019 or later if you meet the security requirements and recommendations. If you have any questions or need assistance, our support team is here to help. 

 

 

Continue the conversation. Find best practices. Bookmark the Public Sector Tech Community, then follow us on the Public Sector Blog for updates.