StrongCertificateBindingEnforcement Explained: KB5014754 & Certificate Mapping Changes

On September 9, 2025, Microsoft permanently removed the ability to run domain controllers in Compatibility mode for certificate-based authentication. The StrongCertificateBindingEnforcement registry key no longer allows reverting to weak certificate mapping. If your certificates don’t have strong mappings to Active Directory accounts, certificate-based authentication breaks — smart cards stop working, Wi-Fi 802.1X fails, VPN certificates are rejected, and SCEP-enrolled devices lose network access.

This change (KB5014754) has been rolling out since May 2022, with multiple deadline extensions. The final enforcement is now permanent. Here’s what it means, how to check if you’re affected, and how to fix it.

What Changed and Why

The Vulnerability

Before KB5014754, Windows domain controllers used weak certificate mapping to determine which AD account a certificate belongs to. The mapping relied on the certificate’s Subject or SAN fields — which the certificate requestor could potentially control (especially with misconfigured templates — see ESC1).

An attacker who could obtain a certificate with a manipulated subject name could authenticate as any user in the domain. This is a certificate spoofing vulnerability that enables privilege escalation.

The Fix: Strong Certificate Mapping

Strong mapping requires an explicit, non-spoofable binding between the certificate and the AD account. Two methods qualify as “strong”:

What’s “Weak” (No Longer Accepted)

Timeline

How to Check If You’re Affected

Step 1: Check for Warning Events

Before enforcement, domain controllers log Event ID 39 (warning) when weak mappings are used:

# Check for weak mapping warnings on domain controllers
Get-WinEvent -LogName "System" -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kerberos-Key-Distribution-Center'] and EventID=39]]" |
  Select-Object -First 20 TimeCreated, Message

# Event 39 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"

If you see Event ID 39, those certificates will FAIL after enforcement.

Step 2: Check Certificate SID Extension

# Check if a certificate has the SID extension
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*server*" }
$cert.Extensions | Where-Object { $_.Oid.Value -eq "1.3.6.1.4.1.311.25.2" }

# If no output — the certificate lacks the SID extension (weak mapping)

Step 3: Check altSecurityIdentities Mappings

# Check explicit certificate mappings for a user
Get-ADUser -Identity "jsmith" -Properties altSecurityIdentities |
  Select-Object -ExpandProperty altSecurityIdentities

# Check for a computer
Get-ADComputer -Identity "WORKSTATION01" -Properties altSecurityIdentities |
  Select-Object -ExpandProperty altSecurityIdentities

# Strong mapping formats:
# X509:<SKI>abcdef1234...           (Subject Key Identifier)
# X509:<SHA1-PUKEY>abcdef1234...    (SHA1 of public key)
# X509:<I>DC=com,DC=contoso,CN=CA<SR>1234567890  (Issuer + Serial)
# X509:<S>CN=user@contoso.com       (Subject — WEAK, won't work)

Step 4: Check the Registry Key (Pre-September 2025)

# Check current enforcement mode (only relevant before Sep 2025)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" -Name "StrongCertificateBindingEnforcement" -ErrorAction SilentlyContinue

# Values:
# 0 = Disabled (not recommended — no security)
# 1 = Compatibility mode (weak mappings work but log warnings)
# 2 = Enforcement mode (weak mappings rejected)
# Key absent = default behavior (Enforcement since Feb 2025)

# After September 9, 2025: This key is IGNORED regardless of value

How to Fix: Implementing Strong Mapping

Option 1: Re-Enroll with SID Extension (Recommended)

The cleanest fix: re-issue certificates from a CA that includes the SID extension automatically. Windows Server 2022+ CAs and updated Windows Server 2016/2019 CAs (with KB5014754 installed) automatically add the SID extension to new certificates.

# Verify your CA adds the SID extension
# Issue a test certificate and check:
certutil -dump test-cert.cer | findstr "szOID_NTDS_CA_SECURITY_EXT"
# If present: 1.3.6.1.4.1.311.25.2 — SID extension is included

# Force re-enrollment for all auto-enrolled certificates:
# 1. Delete existing certificates from client stores
# 2. Run: certutil -pulse (triggers auto-enrollment)
# 3. Verify new cert has SID extension

For Intune/MDM-enrolled certificates:

Microsoft published guidance for implementing strong mapping in Intune SCEP profiles. The certificate profile must include the {{OnPremisesSecurityIdentifier}} variable in the URI SAN field:

URI: tag:microsoft.com,2022-09-14:sid:<{{OnPremisesSecurityIdentifier}}>

Option 2: Manual Explicit Mapping

For certificates that can’t be re-issued (third-party CAs, legacy devices), manually map the certificate to the AD account:

# Map by Issuer + Serial Number (strong)
$issuer = "DC=com,DC=contoso,CN=Contoso Issuing CA"
$serial = "6100000000a1b2c3d4e5f6"
Set-ADUser -Identity "jsmith" -Add @{
    altSecurityIdentities = "X509:<I>$issuer<SR>$serial"
}

# Map by Subject Key Identifier (strong)
$ski = "a84a6a63047dddbae6d139b7a64565eff3a8eca1"
Set-ADUser -Identity "jsmith" -Add @{
    altSecurityIdentities = "X509:<SKI>$ski"
}

# Map by SHA1 of public key (strong)
$sha1pubkey = "f3a8eca1a84a6a63047dddbae6d139b7a64565ef"
Set-ADUser -Identity "jsmith" -Add @{
    altSecurityIdentities = "X509:<SHA1-PUKEY>$sha1pubkey"
}

Option 3: Certificate Backdating (Temporary)

For certificates issued before May 10, 2022, a separate registry key allows them to bypass strong mapping requirements:

# CertificateBackdatingCompensation — allows old certs to use weak mapping
# ONLY for certificates issued BEFORE the KB5014754 date
# Registry: HKLM\SYSTEM\CurrentControlSet\Services\Kdc
# Value: CertificateBackdatingCompensation (REG_DWORD)
# Data: Number of days to backdate (e.g., 50 = certs issued 50+ days before patch)

# This is a TEMPORARY workaround — replace certificates as soon as possible

"The certificate for user <user> could not be mapped to an account.
The certificate was denied because it could not be strongly mapped to the account."

"A certificate was mapped to an account using weak mapping.
Certificate: <thumbprint>, Account: <user>, Mapping type: <type>"

# bulk-fix-certificate-mapping.ps1
# Adds explicit altSecurityIdentities mappings for all users with certificates

$users = Get-ADUser -Filter * -Properties Certificates, altSecurityIdentities

foreach ($user in $users) {
    foreach ($certBytes in $user.Certificates) {
        $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($certBytes)

        # Check if SID extension exists
        $sidExt = $cert.Extensions | Where-Object { $_.Oid.Value -eq "1.3.6.1.4.1.311.25.2" }

        if (-not $sidExt) {
            # No SID extension — add explicit mapping by Issuer+Serial
            $issuer = $cert.Issuer
            $serial = $cert.SerialNumber
            $mapping = "X509:<I>$issuer<SR>$serial"

            if ($user.altSecurityIdentities -notcontains $mapping) {
                Write-Output "Adding mapping for $($user.SamAccountName): $mapping"
                Set-ADUser -Identity $user -Add @{ altSecurityIdentities = $mapping }
            }
        }
    }
}