Understanding and Troubleshooting - Strong Certificate Name Mapping in Active Directory

Hello team, Manuel here. In recent years, Microsoft has introduced Strong Certificate Name Mapping (Strong Mapping) as a requirement for certificate-based authentication in Active Directory environments. These changes were driven by security improvements to address vulnerabilities such as CVE-2022-26931, CVE-2022-26923, and CVE-2022-34691, as well as broader efforts to harden Kerberos and PKI authentication.

Starting with the September cumulative updates which will be released on September 9, 2025, compatibility mode will no longer be supported. Any domain controllers (DCs) running in compatibility mode via the StrongCertificateBindingEnforcement registry setting must transition to enforcement mode. Organizations must act now to prepare, validate, and re-issue certificates as needed if they haven’t already.

This article provides a deep technical overview, common errors, troubleshooting scenarios, and guidance for enterprise and government deployments.

TL;DR (at a glance)

• If you don’t have Event ID 39,40, or 41 from the Kerberos Key Distribution Center in your System log, you’re probably ready for September, otherwise you’re likely to be in for a bumpy ride.
• If you use Enterprise CA + templates → Using templates that are built from AD with the Automatic SID OID extension added is simplest.
• If you use Supply in the Request / offline certs commonly found in SCEP implementations → SAN URI Mapping or Manual Mapping.
• If you’re in a government/federated smart-card scenario with strict PKI controls → Strong name mapping via Group Policy.
• Windows Server 2016 KDC does not support SAN URI strong mapping or Strong name mapping via Group Policy. Windows Server 2019 or higher operating system is required for these options.

Previous Guidance

There have been a few articles/posts released for these changes.  The first that covers the hardening changes themselves and their timeline is found at KB5014754: Certificate-based authentication changes on Windows domain controllers - Microsoft Support.

SAN URI capabilities for SCEP based solutions were introduced in Preview of SAN URI for Certificate Strong Mapping for KB5014754 | Microsoft Community Hub.  This was designed to ease the administrative burden in MDM environments. 

Strong Name Mapping via Group Policy, also known as Tuples, is documented at Enable strong name-based mapping in government scenarios | Microsoft Community Hub.  This was introduced to provide a way for group policy

Registry Behavior Changes

I know that we were talking about these changes frequently but here’s a short summary of the timeline this year.

After installing the February 2025 Cumulative updates, domain controllers behave as follows:

Registry Path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement

⚠️Important: Restart of the DC or KDC service is NOT required when applying this registry value.

Once the September 9, 2025 cumulative update is installed, the registry value will no longer be honored. Enforcement mode will be the only supported mode.  If you are still getting Event IDs 39, 40, and 41 from the Kerberos Key Distribution Center in your System log, you’re likely to have some issues once you patch your DCs, and you need to immediately investigate strong mapping solutions.

The Options for Strong Mapping

Automatic SID OID Extension

This option has been available since May 2022. It uses OID 1.3.6.1.4.1.311.25.2 to embed the requester’s SID directly in the certificate. If you’re leveraging an Enterprise CA with online templates (Build from This Active Directory Information), you’re already configuring certificates with this OID.
Build from This Active Directory Information option

 

 

 

 

 

 

 

 

 

 

 

 

Certificates Issued with Build from This Active Directory Information option, and how automatically populate the SID of the requester to the certificate.

 

 

Requirements:

• Microsoft Enterprise CA (AD domain member).
• Certificates issued from templates that automatically populate AD attributes.
• KB5014754 or later installed on both CA (for certificate issuance) and DC (for reading the new OID).
• Certificates that were issued prior to this patch being installed on the CA would have to be reissued to get it.
• Limitation: Not available for manually crafted requests where attributes are supplied in the CSR.

Explicit Manual Mapping

At this stage, you might be wondering how things work when using Supply in the Request templates. Beginning with the May 2022 update, Microsoft introduced categorizations of strengths for the options for explicit/manual mapping of a certificate to its corresponding Active Directory identity (this applies to both computer and user objects). Notably, we recommended explicit mappings be implemented by associating a certificate with an AD object by using the Issuer Name of the CA together with the Serial Number of the certificate that you want to assign.  That is our recommended Strong Mapping method.

The official documentation details all supported methods of explicit/manual mapping. Starting in February 2024, the Active Directory Users and Computers (ADUC) console defaults to using X509IssuerSerialNumber for manual mapping.

Active Directory User and Computer method (X509IssuerSerialNumber):

When a certificate must be strongly bound to a specific identity, you can use the ADUC console. Simply right-click the object, select “Name mappings…”, and ADUC will automatically convert the certificate properties into a strong mapping. The resulting data is written to the altSecurityIdentities attribute, ensuring the identity is strongly mapped.

Open ADUC and locate the identity

• Open Active Directory Users and Computers (ADUC).
• Navigate to the user or computer object that will own the certificate.
• Right-click the object ▸ Name Mappings… (matches your “Name Mappings…”).

Add the certificate and choose strong mapping

• In Name Mappings, go to the X.509 Certificates tab → click Add…
• Browse to the exported .cer file and select it.
• In Add Certificate, confirm the parsed values for Subject, Issuer, and Serial
• Ensure both boxes are checked:
• Use Issuer for alternate security identity
• Use Serial Number for alternate security identity
  
• Click OK, then Close.

 

Verify the strong mapping was written

• Open the object’s Properties → Attribute Editor tab.
• Confirm altSecurityIdentities now contains an entry with the issuer and serial (your first screenshot).
• Example of what you’ll see (format varies by issuer DN length):

  X509:<I>DC=com,DC=contoso,CN=EntCA<SR>150000000000001af17557b8634e501500000053

Manually generating mapping values for explicit mapping

In most cases, the best option is to re-issue certificates with the new SID OID extension (1.3.6.1.4.1.311.25.2). However, if re-issuing is not possible, you can still achieve compliance by creating a manual strong mapping in Active Directory.

This works by adding a mapping string into the user’s or computer’s altSecurityIdentities attribute. The mapping tells Active Directory exactly which certificate belongs to which identity.

How it works

1. Take the Issuer and Serial Number fields from the certificate you want to map.
   Example from a cert:

o   Issuer: CN=CONTOSO-DC-CA, DC=contoso, DC=com

o   SerialNumber: 2B0000000011AC0000000012

1. Convert both values into the reverse format required by AD:
• The Issuer DN must be reversed (so CN=… , DC=contoso, DC=com becomes DC=com,DC=contoso,CN=…).
• The Serial Number must also be reversed by byte order (e.g., A1B2C3 → C3B2A1).
2. Build the final mapping string:
• X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B
3. Add that mapping string to the account’s altSecurityIdentities attribute.
   Example PowerShell:

• Set-ADUser 'DomainUser' -Replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"}

PowerShell Functions that you could use for automation:

Flip the Issuer (FQDN)

function Flip-FQDN {
    param([String] $FQDN)
    $arr = $FQDN.Split(',').Trim()
    [array]::Reverse($arr)
    return $arr -join ','
}

$originalFQDN = "CN=EntCA,DC=contoso,DC=com"
$flippedFQDN = Flip-FQDN -FQDN $originalFQDN
Write-Output "Flipped FQDN: $flippedFQDN"

 

Flip the Serial Number (byte order)

function Flip-ByteOrder {
    param([String] $byteString)
    if ($byteString.Length % 2 -ne 0) { throw "Error: byte string is expected to have even length" }
    $length = $byteString.Length
    $newstr = ''

    for ($i = $length - 1; $i -gt 0; $i -= 2) {
        $newstr += $byteString[$i - 1] + $byteString[$i]
    }
    return $newstr
}
$serialNumber = "5300000015504e638b5775f11a000000000015"
$flippedSerialNumber = Flip-ByteOrder -byteString $serialNumber
Write-Output "Flipped Serial Number: $flippedSerialNumber"

SAN URI Mapping

There is also the possibility of mapping a SID manually inside the certificate and associating it with a specific identity. This approach is highly useful in scenarios where offline certificates are required and deployed in large numbers, or where you want a more persistent binding. For more details, refer to Matthew’s blog post.

Preview of SAN URI for Certificate Strong Mapping for KB5014754 | Microsoft Community Hub

This capability was added to Intune in November 2024. Uses SAN tag format:tag:microsoft.com,2022-09-14:sid:<OnPremisesObjectSIDValue>

• Support:
• Windows Server 2019 and Newer versions (after March 12, 2024 patches).
• Not supported on Windows Server 2016, if the KDC is this Windows server needs to migrate his DCs to 2019 to make it work.
• Requires Intune configuration and testing.

For more information you can refer to the link: Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

Other third party MDMs have also incorporated this capability in their products as well and have their own Configuration documentation to support it.  Organizations should leverage these third parties’ support services for configuration guidance. 

Strong name mapping via Group Policy (Tuples)

This method is designed primarily for government and smart card federated authentication environments, where traditional strong mappings (SID OID, Issuer + Serial) may not be practical due to large numbers of externally issued certificates (Not built from AD).  This option has been available since January of 2025.

It lets you treat certain “weak” mappings (such as Issuer/Subject AltSecID or UPN mappings) as if they were strong mappings, provided your PKI meets specific security guarantees. When both conditions match (correct CA + correct Issuance Policy OID), the DC upgrades those weak mappings to strong mappings.

 

How to configure Strong Name-Based Mapping (Tuples)

Enable and configure:

1. Confirm that there are issuance policy OID(s) added to certs
   
2. GPO on DCs →
   Computer Configuration > Administrative Templates > System > KDC > Allow name-based strong mappings for certificates → Enable.
3. Add policy tuples (one per CA/thumbprint as needed):

4.  <IssuerCAThumbprint>;<IssuancePolicyOID(s)>;<IssuerSubject/UPNSuffix=corp.contoso.com>

   Examples:
   

   FFE06....20E67;2.16.840.1.101.3.2.1.3.45;IssuerSubject
   EC526....D6556;2.16.840.1.101.3.2.1.3.45;UPNSuffix=corp.contoso.com
   7972D....B7736;2.16.840.1.101.3.2.1.3.45,2.16.840...3.44;UPNSuffix=corp.contoso.com,UPNSuffix=my.corp.contoso.com,IssuerSubject

   Note: You cannot repeat thumbprints. CA thumbprints with multiple UPN Suffixes or OIDs are listed once with OIDs and Suffixes/IssuerSubject separated by commas
5. If IssuerSubject was configured, then you still must populate the altsecurityidentities in this format:

   X509:<I>IssuerName<S>SubjectName

   Example:
   Issuing CA:

   CN=Contoso Issuing CA 1,DC=contoso,DC=com

   Subject:

   CN=Bob,OU=Employess,OU=PKI

   Altsecid attribute value on Bob’s account for this mapping method:

   X509:<I>DC=com,DC=contoso,CN=Contoso Issuing CA 1<S>OU=PKI,OU=Employees,CN=Bob

   
   (Due to this administrative overhead, we do not recommend IssuerSubject unless you need it, and the only reason to need it is if you have confirmed that software in you environment requires UseSubjectAltName set to 0 on your DCs)

Validate your configuration by ensuring that you do not have Event ID 313 in the Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational log.

⚠️ Use only when PKI and issuance processes truly meet the required guarantees

Another important note to add is that if you are using the GPO setting “Process even if the Group Policy objects have not changed” under “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing” you may have intermittent authentication failures for all users relying on tuples across the environment.  We recommend that you disable that policy or simply do not apply it.

Common pitfalls (and fixes)

• Compatibility mode “not working”
  • Move to enforcement now and complete strong mapping. Compatibility mode is going away.

• UseSubjectAltName = 0
  • Prevents UPNs in SAN from being used
  • Should only be used where required
  • Requires either explicit manual mappings or IssuerSubject Tuple configuration
• SAN-URI and Tuples are not supported on Server 2016. Windows Server 2019 or higher operating system is required for these options.
• Explicit Manual Mapping Gotchyas
  • Use sparingly
  • Reverse Issuer DN order and Serial byte order correctly.
  • Map to the correct object type (user cert → user; device cert → computer).
  • Avoid multiple conflicting mappings in altSecurityIdentities.
• Certificate Renewals
  • If using Issuer+Serial Explicit Manual mapping, a new serial means update the mapping.
  • If using Build from this Active Directory, we won’t need to renew it because AD is building the Strong Name Mapping from the SID requestor.
• Strong name-based mapping tuples
  • CA thumbprints must be unique across all entries per tuple; OIDs must be present on the cert.
  • UPNSuffix= must exactly match the SAN UPN suffix and requires SAN UPN (don’t set UseSubjectAltName=0).
  • Invalid tuple → Event 313 (KDC Operational log).
  • Do not use “Process even if the Group Policy objects have not changed” under the Group Policy object “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing”

• User migrations
  • SidHistory is not checked
  • Requires extra planning with options such as:
    • Users would need new certificates issued with the new SID signed into the certificate
    • Issuance policy could be added to the PKI to support tuples
    • Explicit manual mapping

• Consuming the System event logs for events and automatically mapping certificates to accounts is not recommended as it is a security bypass.

Events:

Event ID 39 — No strong mapping

Where: System (Warning in Compatibility mode, Error in Enforcement mode)

Meaning: The KDC saw a valid certificate but could not map it strongly (no explicit mapping, key trust, SID OID, or other strong method).

Fields typically included: User, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint.

Action: Implement a strong mapping (e.g., Option 1 SID OID, Option 2 Issuer+Serial, Option 3/4 SAN URI on WS2019+, or Option 5 tuples), then retest.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 41 (see below).

Event ID 40 — Certificate predates account (Compatibility mode only)

Where: System (Error)

Meaning: The certificate was issued before the AD account existed and no strong mapping could be found, so it was rejected.

Fields typically included: User, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint, Certificate Issuance Time, Account Creation Time.

Action: Reissue with a strong mapping (or adjust Certificate Backdating policy if appropriate). Use one of the strong methods, then retest.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 48.

Event ID 41 — User SID does not match Certificate SID

Where: System (Error)

Meaning: The SID embedded in the certificate’s extension does not match the AD account’s SID → authentication fails.

Fields typically included: User, User SID, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint, Certificate SID.

Action: Replace the certificate with one that carries the correct SID (Option 1), or use another strong mapping (Option 2/3/4/5) that matches the intended identity.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 49.

Event ID 313 — Invalid Certificate Strong Name Match Policy

Where: Kerberos-Key-Distribution-Center\Operational (Error)

Meaning: Something went wrong when trying to read the Strong name mapping via Group Policy (Tuple)

Fields typically included: Faulting line: X

Action: Ensure that CA thumbprint is unique, the right amount of characters, no special characters, disable the setting “Process even if the Group Policy objects have not changed” from “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing”