Enable strong name-based mapping in government scenarios

If you work in a smart card federated authentication environment, here’s a very anticipated security feature for you: Starting with the September 10, 2024 Windows security updates, strong name-based mapping is available on Windows Server 2019 and later. This feature helps handle the hardening changes to certificate-based authentication on Windows domain controllers.

What are weak and strong mappings in Active Directory?

All certificate names must map correctly to the intended user account in Active Directory (AD). If there is a possibility that they will not map, the mapping is called weak. Weak mappings create security vulnerabilities and require the following hardening measures: Change certificate-based authentication on Windows domain controllers.

As a follow-up to the May 2022 update round that addressed these vulnerabilities, We are introducing new features Strong name-based mapping. You can now distinguish between “strong” and “weak” mappings within an existing Alternate Security ID (AltSecID), based on the possibility. This new feature allows you to treat some weak name-based mappings as strong name-based mappings. All you need to do is properly configure your Public Key Infrastructure (PKI) and AD deployment.

Key features and benefits of strong name-based mapping

Strong name-based mapping has two main advantages:

• Complies with strong certificate mapping enforcement. Strong name-based mapping allows certain weak certificate mappings, such as Issuer/Subject AltSecID and User Principal Name (UPN) mappings, to be treated as strong mappings. This type of strong mapping is Change certificate-based authentication on Windows domain controllers.
• Compatibility with government PKI deployments. Strong name-based mapping works by requiring PKI deployments to prove certain security claims made by a certificate via the object identifier (OID) stamped on the certificate. This is a common practice in government PKI and AD deployments.

Security requirements for PKI deployments for strong name-based mapping

warning

We do not recommend deploying strong name-based mapping unless you have strong requirements for this type of deployment and have in-depth knowledge of how PKI deployments and AD authentication interact. Instead, we recommend following these guidelines: KB5014754: Changes to certificate-based authentication on Windows domain controllers.

Fundamentally, deploying strong name-based mapping is a promise from Microsoft that your PKI is not vulnerable to attacks that will be addressed in updates after May 2022. That means you are responsible for vulnerabilities that could arise from inadvertently mapping a certificate name to multiple AD accounts.

To prevent unintentional and insecure mapping, we recommend taking steps to harden your PKI and AD deployment. Some of these steps include:

• The names used in the certificate’s subject name and/or subject alternative names must not contain names queried or created in AD.
• The names used in the certificate’s subject name and/or subject alternative names must be immutable and globally unique across the entire PKI deployment.
• AD and PKI administrators should ensure that certificate issuance for logon is not automatic. Instead, ensure that there is strong manual checks in place to prevent certificates with incorrect or conflicting names from being issued.

Failure to secure your PKI and AD deployments can weaken the security of your environment.

If your PKI meets or exceeds these security requirements, you should indicate this compliance by adding an OID to the certificate issuance policy. This OID (or multiple OIDs) will be used further down in the strong name-based mapping configuration.

Installation Instructions

To enable strong name-based mapping on Windows Server 2019 and later, you must perform the following steps:

1. Activate Group Policy (GPO) settings on domain controllers:
   Computer Configuration > Administrative Templates > System > KDC > “Allow name-based strong mapping for certificates”.
2. Configure the GPO with the required tuples (see details below).

This configuration relies on adding tuples to the GPO when strong name-based mapping is enabled. These tuples inform domain controllers which certificates meet the above security requirements by specifying both the issuer certificate authority (CA) thumbprint and an OID that indicates that the PKI deployment is protected against the May 2022 vulnerability. The tuples also configure which “weak” name-based mappings can be upgraded to “strong” name-based mappings.

The format of a tuple is:

;;

1. Issuer CA certificate fingerprint: This is the certificate fingerprint of the issuing CA. There can only be one issuing CA fingerprint in this field. If multiple issuing CA fingerprints are placed, the GPO policy may not be processed properly.
2. OID(s): This is a comma-separated list of OIDs that are stamped on certificates to prove that the PKI deployment has met security requirements for name collisions. Multiple OIDs can appear in this field.
3. Issuer Title/UpnSuffix: This is a comma-separated list indicating which types of weak mappings should be treated as strong mappings.
   1. IssuerSubject: This string acts as a tag to indicate 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 indicates that the certificate mapping can be upgraded from “weak” to “strong” if the UPN suffix in the SubjectName (i.e. everything 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 as follows: For a certificate whose issuer is X There it is any OID(s) whyUpgrade any Weak mapping aspirate With “strong”. This logic is summarized in the diagram.

Flowchart illustrating the logic of configuring a strong name-based mapping. The chart starts with a decision diamond that asks if the certificate’s issuer certificate thumbprint matches the specified thumbprint. If it does, it checks to see if the certificate has the specified OID. If both conditions are met, it allows strong mapping to the certificate based on the issuer/subject name AltSecID or UPNSuffix, depending on the configuration.

There are two important configuration details required for UPN suffix mapping to work:

• The certificate must contain the user’s UPN in the SAN.
• Mapping via UPN is not disabled. UseSubjectAltName.

How to use and understand policy tuples: Exercise

Policy Tuple Example 1

This policy tuple allows strong mapping via Issuer/SubjectName AltSecID.

fe40a3146d935dc248504d2dcd960d15c4542e6e; 2.16.840.1.101.3.2.1.3.45;Issuer Title

1. For certificates with an issuer certificate fingerprint fe40a3146d935dc248504d2dcd960d15c4542e6eand
2. The certificate has an OID 2.16.840.1.101.3.2.1.3.45,
3. Allows strong mapping when certificates are mapped via Issuer/SubjectName AltSecID.

This tuple allows a certificate login that passes checks (1) and (2) issued to user Bob, provided that the issuer/subject name AltSecID for the certificate is correctly configured on Bob’s AD object.

Policy Tuple Example 2

This policy tuple allows strong mapping via a specified UPNSuffix.

fe40a3146d935dc248504d2dcd960d15c4542e6e; 2.16.840.1.101.3.2.1.3.45;UPNSuffix=corp.contoso.com

1. For certificates with an issuer certificate fingerprint fe40a3146d935dc248504d2dcd960d15c4542e6eand
2. The certificate has an OID 2.16.840.1.101.3.2.1.3.45,
3. Allows strong mapping if the certificate is mapped via UPNSuffix, which should be “corp.contoso.com”.

This tuple allows a certificate login that passes checks (1) and (2) issued to user Bob, provided that the issuer/subject name AltSecID for the certificate is correctly configured on Bob’s AD object.

Policy Tuple Example 3

This policy tuple allows for strong mappings via 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 with an issuer certificate fingerprint fe40a3146d935dc248504d2dcd960d15c4542e6eand
2. The certificate has one 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. Allows strong name-based mapping if the certificate is mapped via one 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”.

Change event log

Two event log updates will help AD administrators better troubleshoot strong name-based mapping scenarios. These will be available in the September 10, 2024 update and later.

Current event log update

The current event log now includes the policy OID found in the certificate used for authentication. This fixes the Key Distribution Center (KDC) event introduced by: After May 10, 2022 Update.

New event log

Additionally, a new event is provided that can be logged when a Strong Name-Based Mapping GPO encounters problems processing policy tuples. These events are tracked via Event ID 311.

Are you ready to improve your Windows Server security?

We are excited to bring this feature to your government scenarios. If it meets your security requirements and recommendations, consider strong name-based mapping for your Active Directory and PKI deployments on Windows Server 2019 and later. If you have any questions or need assistance, our support team is here to help.

Keep the conversation going. Find best practices. Bookmark it. Public Sector Technology CommunityThen follow us Public Sector Blog Check out the latest information.