Weak Certificate Mappings in Active Directory: What KB5014754 Broke and How to Fix It

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 39, 40, 41 } -ErrorAction SilentlyContinue |
    Where-Object { $_.ProviderName -match 'Kdc|Kerberos-Key-Distribution-Center' } |
    Select-Object -First 100 |
    Format-List TimeCreated, Id, Message

What the finding means

When a user or computer logs on with a certificate, the domain controller has to work out which account the certificate belongs to. One way is an explicit mapping: a string stored in the account's altSecurityIdentities attribute that says "this certificate is me." Microsoft's KB5014754 lists six formats for that string and splits them down the middle:

The weak three match on a name. For a subject-only or email mapping, any CA your domain trusts for logon can issue a certificate with that name. An issuer and subject mapping is a little tighter, since it also pins the issuing CA. It still trusts a name that CA can put in any certificate it signs. The strong three bind to one specific certificate or its key, which a name can't be forged into.

This check reads altSecurityIdentities over LDAP on every user and computer account, domain controllers' own accounts included. It flags any value that starts with X509:<I>, X509:<S> or X509:<RFC822>, unless the value carries one of the strong tags: <SR>, <SKI> or <SHA1-PUKEY>. One weak mapping is enough to flag an account, even if it also has a strong one. Entries that aren't X509 mappings get ignored.

It doesn't look at the domain controller side at all. Whether your DCs would actually accept a weak mapping is a separate check (ESC10, covered below). The two split the problem cleanly. This one finds the accounts carrying forgeable mappings. ESC10 finds the domain controllers that would honor them.

Why weak certificate mappings are a problem now

A weak mapping causes trouble in one of two ways, depending on where the logon happens.

It's broken. Domain controllers with the September 2025 updates run in Full Enforcement. The StrongCertificateBindingEnforcement registry value that used to roll that back is no longer supported. Under Full Enforcement a certificate has to be strongly mapped. That means a strong explicit mapping, a key trust mapping, or the account's SID inside the certificate. A certificate that only lines up with a weak mapping gets denied. The domain controller logs event 39 when it happens.

It's a standing exposure. A weak mapping trusts a name. On an up-to-date domain controller, Kerberos won't honor a subject-only or email mapping on its own at all. An issuer and subject mapping is different. It can still be accepted through Schannel's name-based methods, or through a name-based mapping policy scoped to its CA. So how much a given weak mapping exposes depends on where the certificate gets used and how the domain controllers are set. Either way it's one more account whose logon leans on a name instead of a key.

How attackers use weak mappings

The idea is simple. A weak mapping says "any certificate with this name is this account." So an attacker looks for accounts with weak mappings, privileged ones first. Then they look for a way to get a certificate with a matching subject or email from a CA the domain trusts for logon. A template that lets the requester supply the subject is one way. An attribute they can change that ends up in a certificate is another.

Full Enforcement shut most of this down for Kerberos. That's why the breakage was so loud. What's left is Schannel configured with the old name-based methods, name-based mapping policies scoped too broadly, and domain controllers that are behind on updates. That's a narrower window than it used to be, but every weak mapping keeps it open for that account.

How we got here

Matching certificates to accounts by name was normal for years. Certifried (CVE-2022-26923) showed how far that could go. Certificates were tied to computer accounts by DNS name. A low-privilege user could point a computer account they controlled at a domain controller's DNS name. Then they could enroll for a certificate that logged on as that domain controller.

Microsoft's fix was KB5014754. Enterprise CAs started putting the account's SID into certificates as a security extension. Domain controllers started checking for a strong mapping. It rolled out slowly:

1. May 10, 2022: Compatibility mode. Domain controllers logged warnings but still allowed most weak logons.
2. April 11, 2023: the option to disable the check entirely went away.
3. February 11, 2025: Full Enforcement became the default. You could still roll back with a registry value.
4. September 9, 2025: the rollback stopped working. Full Enforcement is the only mode now.

People are still tripping over that last step. Intune issues SCEP and PKCS certificates from offline templates, which don't carry the SID by default. Any of those used to authenticate against a domain controller get denied under Full Enforcement until the SID is added. Microsoft added a fix on the Intune side, but someone has to turn it on. Smart cards from third-party CAs hit the same wall. The US federal PIV guidance on idmanagement.gov now treats subject-only and email mappings as deprecated. It only allows Issuer and Subject mappings through a specific domain controller policy.

Find weak certificate mappings in your domain

Find weak mappings

This reads altSecurityIdentities across the domain and keeps the entries that match on a subject or email, the same thing the finding looks for. It lists every account with an Issuer and Subject, Subject only or email mapping. It shows the mapping itself too. Run it as any domain user with the ActiveDirectory module installed.

Import-Module ActiveDirectory
Get-ADObject -LDAPFilter '(altSecurityIdentities=*)' -Properties altSecurityIdentities, sAMAccountName, objectClass |
    ForEach-Object {
        foreach ($m in $_.altSecurityIdentities) {
            if ($m -match '^X509:\s*<(I|S|RFC822)>' -and $m -notmatch '<SR>|<SKI>|<SHA1-PUKEY>') {
                [pscustomobject]@{
                    Account = $_.sAMAccountName
                    Type    = $_.objectClass
                    Mapping = $m
                }
            }
        }
    }

What to look for: every row is a finding, using the same rule as the check. Anything starting with X509:<I>, X509:<S> or X509:<RFC822> counts unless it carries a strong tag. That's why Issuer and Serial Number mappings, which also start with X509:<I>, drop out. Entries that start with Kerberos: aren't certificate mappings and don't show up. Look at privileged accounts and domain controllers first.

See what's failing right now

Domain controllers log a System event when they refuse a certificate that isn't strongly mapped. Chain, revocation and other failures log elsewhere. This pulls the most recent certificate mapping events from the local domain controller. Run it on each DC, or pull the events centrally.

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 39, 40, 41 } -ErrorAction SilentlyContinue |
    Where-Object { $_.ProviderName -match 'Kdc|Kerberos-Key-Distribution-Center' } |
    Select-Object -First 100 |
    Format-List TimeCreated, Id, Message

What to look for:

• 39: the certificate was valid but couldn't be strongly mapped. Under Full Enforcement this is an error and the logon was denied. The message names the account and the certificate.
• 41: the SID in the certificate doesn't match the account it mapped to. Denied.
• 40: only logged in Compatibility mode. A recent one means that domain controller is missing updates. Check TimeCreated, since old events stick around in the log.

Event 39 is the most useful one here. It tells you which accounts and certificates are breaking today, which is usually the fastest way to find out what each weak mapping was for.

Check how Schannel maps certificates

Schannel keeps its own mapping methods on each domain controller. This is where weak mappings can still work after Full Enforcement.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel' -Name CertificateMappingMethods -ErrorAction SilentlyContinue

What to look for: no output means the value isn't set and the default applies, which is 0x18, the two strong methods only. A value that includes 0x1 (Subject/Issuer), 0x2 (Issuer) or 0x4 (UPN) means someone turned weak mapping back on for TLS logons. Run it on every DC.

Check it with Insight Recon

The commands above are the manual way. Insight Recon's read-only Active Directory security assessment checks certificate mapping from several angles, along with 150+ other checks:

• Accounts with Weak Certificate Mappings (High): flags every user and computer account with an Issuer and Subject, Subject only or email mapping in altSecurityIdentities, even when it also has a strong one.
• Weak Certificate Mapping on Domain Controllers in ADCS (ESC10) (High): flags domain controllers with StrongCertificateBindingEnforcement set to disabled or compatibility mode, or with Schannel allowing UPN mapping.
• Weak Certificate Mapping Write Access in ADCS (ESC14) (High): flags privileged accounts where other principals can write altSecurityIdentities.
• Certificate Template Missing Security Extension (ESC9) (High) and Certificate Authority Disables SID Security Extension (ESC16) (Critical): catch the places where certificates get issued without the SID, which pushes logons back toward name-based mapping.

Insight Recon reads your configuration. It can't see your domain controller event logs. Pair it with event 39 to see what's actually failing.

Every finding comes with the attacker context and the remediation steps. Want to see what one looks like first? Here's a sample report.

How to fix weak certificate mappings

Work out what each mapping is for

Before you change anything, find the certificate behind each weak mapping. The subject or issuer in the mapping usually tells you which CA issued it. Event 39 on your domain controllers tells you which ones are failing right now. These are usually smart cards or certificates from a third-party CA. The subject or issuer in the mapping is your best clue to which system owns it.

Get the SID into the certificate

The cleanest fix is a certificate that carries the account's SID. Then it's strongly mapped without any explicit mapping at all.

• Enterprise CA, online templates: certificates issued since the CA got the May 2022 update already include the SID extension. Older certificates don't. Reissue them to get it. Two things stop the SID going in even on a new one: a template with the no-security-extension flag (ESC9) and a CA that disables the extension globally (ESC16). Fix those first.
• Intune SCEP: add a URI to the subject alternative name with the value {{OnPremisesSecurityIdentifier}}. Intune fills in the SID as tag:microsoft.com,2022-09-14:sid:<SID>. Your domain controllers need to be Windows Server 2019 or later to honor a SID from a SAN URI. See Microsoft's SCEP profile guidance.
• Intune PKCS: the SID comes from the Intune Certificate Connector instead of the profile. Update the connector to 6.2406.0.1001 or later. Then set EnableSidSecurityExtension to 1 under HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector and restart the PFX connector services. It applies to new and renewing certificates.

Switch to an Issuer and Serial Number mapping

Where you can't get the SID into the certificate, like a third-party smart card, replace the weak mapping with the strong Issuer and Serial Number format. The serial goes in reversed byte order. The .NET GetSerialNumber() method already returns it that way. If the account has an Issuer and Subject mapping, you can keep its issuer part and swap the subject for the serial:

# Serial number in the reversed byte order altSecurityIdentities expects
$cert   = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\certs\jdoe.cer')
$serial = ($cert.GetSerialNumber() | ForEach-Object { $_.ToString('X2') }) -join ''

# Keep the issuer from the existing weak mapping and replace the subject with the serial
$weak   = 'X509:<I>DC=com,DC=contoso,CN=Contoso-Issuing-CA<S>DC=com,DC=contoso,CN=Users,CN=Jane Doe'
$strong = ($weak -replace '<S>.*$', '') + "<SR>$serial"

Set-ADUser -Identity jdoe -Add @{ altSecurityIdentities = $strong }

Use Set-ADComputer for computer accounts. Subject-only and email mappings don't have an issuer to reuse. Build those by hand in the same format. This only works when the issuer in the old mapping really is the issuer of the certificate you loaded. A reissued card can come from a different CA. Remember too that a serial number belongs to one certificate. When the certificate renews, the mapping has to be updated, which is one more reason to get the SID in where you can.

Remove the weak mapping

Removing a weak mapping is safe only once the certificate can still find its account another way. The SID in a certificate confirms the account, but it doesn't locate it. If the certificate has no UPN or DNS name in its subject alternative name, and no strong explicit mapping, the weak entry is the only thing pointing the domain controller at the account. Pull it then and the logon breaks. So make sure a strong explicit mapping, or a SID-bearing certificate that still has a matching name, is already in place. Then test a real logon.

Set-ADUser -Identity jdoe -Remove @{ altSecurityIdentities = $weak }

Leaving a weak mapping in place next to a strong one doesn't break anything today. It just keeps the name-based way in open for that account. The finding stays until it's gone.

Close the other doors

• Schannel: make sure CertificateMappingMethods on your domain controllers is unset or 0x18, with no Subject/Issuer, Issuer or UPN bits.
• Write access: review who can edit altSecurityIdentities on privileged accounts. Anyone with that right can map their own certificate to the account.
• Templates and CAs: make sure templates used for logon include the SID extension and that no CA has it turned off globally.
• Federal PIV setups: if you rely on the Allow name-based strong mappings for certificates policy, keep each policy tuple scoped to the exact issuing CA and certificate policy.

Tie every certificate to one account

KB5014754 spent three years warning about this. The warnings are over. A certificate logon now works only if the domain controller can tie the certificate to exactly one account. Find the mappings that match on a name and get the SID into those certificates or switch them to a strong mapping. Then lock down who can change them.

Validation checklist

• Have you listed every account with an Issuer and Subject, Subject only or email mapping?
• Are your domain controllers clear of event 39 and 41 for certificates you expect to work?
• Do your Intune SCEP and PKCS certificates carry the SID?
• Is Schannel on every DC limited to the strong mapping methods?
• Is write access to altSecurityIdentities on privileged accounts locked down?

A no on any of these means some certificate logon in your domain still depends on a name.

Compliance mapping

Weak certificate mappings are an authentication problem first. They line up with the control frameworks the same way your other credential hardening does.

FAQ

References

• Microsoft Support: KB5014754, certificate-based authentication changes on Windows domain controllers
• Microsoft Security Update Guide: CVE-2022-26923
• Microsoft Learn: SCEP certificate profiles in Intune, including strong mapping
• idmanagement.gov: Configure smart card logon on Windows domains
• MITRE ATT&CK: T1649, Steal or Forge Authentication Certificates