Kerberos PKINIT and Certificate Mapping Guide: Strong Mapping Without Breaking Certificate Logon

Certificate logon is only as strong as the rule that decides which account a certificate belongs to, and for years that rule in Active Directory was weak enough to let one user's certificate log on as another. Microsoft's response, the strong certificate mapping changes in KB5014754, reached Full Enforcement in February 2025 and removed the compatibility fallback in September 2025, and estates that had relied on name-based mapping found smart card, Wi-Fi, VPN and device certificate logons failing. This guide explains how Kerberos PKINIT works, how domain controllers map certificates to accounts, what counts as a strong mapping, how to fix certificates and accounts that fail, and how to monitor the result. It is for identity engineers, PKI owners and the support teams who take the calls when certificate logon breaks. Smart card hardware, PIV and the choice between cards and FIDO2 are covered in the Smart Card and PIV/CAC Authentication Guide.

Key takeaways

• PKINIT replaces the password, not the account. RFC 4556 lets a client prove possession of a private key in the initial Kerberos exchange; the KDC must then decide which account that key belongs to.
• Mapping is the security boundary. UPN and name-based mappings trust whatever names the CA wrote into the certificate; the SID extension and issuer-plus-serial mappings bind the certificate to one specific account.
• Enforcement is no longer optional. Microsoft states that StrongCertificateBindingEnforcement is no longer supported after September 2025, so every certificate used for domain logon needs a SID extension or an explicit strong mapping.
• Offline and third-party certificates are the usual casualties. Certificates from offline templates, MDM-issued certificates, non-Microsoft CAs and certificates issued before May 2022 lack the SID extension unless someone added it.
• The Kdcsvc events tell you exactly what failed. Events 39, 40 and 41 on domain controllers distinguish a missing strong mapping, a certificate older than its account, and a SID that belongs to someone else.

How PKINIT works

RFC 4556, Public Key Cryptography for Initial Authentication in Kerberos, is a Proposed Standard published in June 2006 and later updated by RFC 6112, RFC 8062 and RFC 8636. It extends the Kerberos Authentication Service exchange so a client can authenticate with an X.509 certificate instead of a password-derived key.

1. Request: the client sends a PA-PK-AS-REQ pre-authentication element (padata type 16) containing a signed authentication pack and its certificate.
2. Validation: the KDC validates the certificate path to a trusted anchor, checks the signature, checks revocation and then binds the certificate to a client principal. That binding is the certificate mapping step this guide is about.
3. Reply: the KDC returns PA-PK-AS-REP (type 17). The reply key is delivered either through Diffie-Hellman key agreement (mandatory to implement) or encrypted to the client's public key.
4. Lifetime: the RFC states that a ticket issued through PKINIT cannot outlive the client's key pair.

Both sides need specific certificates. The RFC says the KDC certificate should carry the id-pkinit-KPKdc extended key usage (1.3.6.1.5.2.3.5) unless its SAN names the realm's ticket-granting service, and that KDCs may require id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) on client certificates while also accepting the Microsoft smart card logon EKU (1.3.6.1.4.1.311.20.2.2). In Windows, AD CS provides the Domain Controller, Domain Controller Authentication and Kerberos Authentication templates for KDC certificates.

Where PKINIT is used

How Active Directory maps a certificate to an account

Microsoft's smart card documentation describes the order: the KDC first uses the user principal name in the certificate's subjectAltName, and certificates without a SAN UPN are mapped through other methods, including the altSecurityIdentities attribute on the account. The first method that finds an account ends the search, and a certificate that maps to different accounts by different methods is a configuration error unless the client supplies a name hint (the X509HintsNeeded setting).

The problem is that UPN and name-based mapping trust what the CA wrote. If an attacker can get a certificate issued containing someone else's UPN or DNS name, the KDC maps it to that account. CVE-2022-26923, widely known as Certifried, showed this with machine accounts. KB5014754 fixed it in two ways:

• SID extension: since the May 2022 updates, enterprise CAs add a non-critical extension (OID 1.3.6.1.4.1.311.25.2) containing the requester's SID to certificates issued from online templates. The KDC compares it with the account's SID.
• Strong explicit mappings: administrators can write an altSecurityIdentities value that binds the account to a specific certificate using a format Microsoft classes as strong.

Trade-off: issuer-and-serial mappings must be rewritten every time the certificate is renewed, while SKI and public key mappings survive renewal only if the key is reused. The SID extension needs no per-account maintenance, which is why getting it into certificates is the scalable fix.

The enforcement settings and timeline

• StrongCertificateBindingEnforcement (HKLM\SYSTEM\CurrentControlSet\Services\Kdc): 1 allowed a weak mapping if the account predated the certificate; 2 denies authentication unless a strong mapping or a valid SID extension exists. Treat it as historical: plan for 2 being the only behaviour.
• CertificateBackdatingCompensation (same key): tolerated certificates issued slightly before the account existed, for weak mappings in Compatibility mode only. Microsoft calls it a security check bypass and says it has no effect at Full Enforcement.
• Schannel CertificateMappingMethods (HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel): the default changed from 0x1F to 0x18, leaving only the strong S4U2Self methods enabled. Setting it back to 0x1F re-enables weak subject, issuer and UPN mappings for TLS client authentication and should be avoided.
• SID extension opt-out: setting the 0x00080000 bit in a template's msPKI-Enrollment-Flag stops the CA adding the SID extension. Microsoft warns this removes the protection; check that no template has it set.

Diagnosing failures with Kdcsvc events

Domain controllers log these events in the System log, source Kdcsvc. The older-OS equivalents are in brackets.

Alongside these, Security event 4768 on the DC records the certificate issuer, serial number and thumbprint for certificate-based TGT requests, which lets you correlate each logon with the CA database.

Bringing an estate into strong mapping

1. Collect evidence: forward Kdcsvc 39, 40 and 41 from every domain controller for at least a full certificate renewal cycle of your shortest-lived templates, and pair them with 4768 certificate fields.
2. Classify by issuance path: group failing certificates by template and CA. Typical groups are offline templates (subject supplied in the request), MDM connectors, third-party or government CAs, and legacy certificates issued before the SID extension existed.
3. Fix enterprise templates: for online templates, renewal alone adds the SID extension. Trigger re-enrolment rather than waiting for expiry for anything that fails.
4. Fix MDM profiles: Microsoft Intune documents adding a URI SAN with the variable {{OnPremisesSecurityIdentifier}}, which Intune renders as tag:microsoft.com,2022-09-14:sid:<SID>. It applies to user certificates and, for device certificates, only to Microsoft Entra hybrid joined Windows devices. Users and devices must be synchronised from AD.
5. Map third-party certificates explicitly: where you cannot change the issuing CA, write X509IssuerSerialNumber mappings into altSecurityIdentities from the card management system, and automate updates at reissue.
6. Remove weak fallbacks: confirm no template sets the SID opt-out flag, that CertificateMappingMethods is at its default on servers, and remove weak altSecurityIdentities values once strong ones exist.
7. Test in rings: pilot changes on a test forest or one site's domain controllers and a group of users, keep the help desk briefed, and keep a documented rollback (temporary explicit mapping for an affected user) rather than relaxing domain-wide settings, which is no longer possible after September 2025.

Decision guidance: if your certificates come from your own enterprise CA, get the SID extension in and avoid per-account mappings. If you depend on certificates you do not issue, such as government PIV cards, invest in automated altSecurityIdentities management. If you are deploying Windows Hello for Business today and do not need certificate scenarios, Microsoft recommends cloud Kerberos trust, which needs no certificates at all. Small organisations with a single CA used only for Wi-Fi may find it simpler to move Wi-Fi to device certificates issued from online templates than to maintain explicit mappings.

PKINIT outside Windows

MIT Kerberos documents its own mapping model. By default the KDC requires client certificates to carry the PKINIT EKU and the PKINIT SAN, an otherName (OID 1.3.6.1.5.2.2) holding the principal name. From release 1.16, an administrator can set a pkinit_cert_match string attribute on a principal to match on other certificate fields, and pkinit_eku_checking = none relaxes EKU checks. The KDC trusts client certificates through pkinit_anchors and presents its own pkinit_identity with the KPKdc EKU and a SAN naming krbtgt/REALM. From release 1.17, pkinit_require_freshness requires freshness tokens from non-anonymous clients. The same principle applies as in AD: keep the match rule as specific as possible and do not relax EKU checking globally.

Linux hosts joined to AD through SSSD rely on AD's mapping when users log on with smart cards. See the SSSD and Linux Active Directory Integration Guide.

Prerequisites that cause silent failures

• NTAuth: the KDC checks that the certificate's issuer is in the domain's NTAuth store. A CA removed from NTAuth stops logon for all its certificates; a CA wrongly added can mint logon certificates for anyone it can name.
• Revocation reachability: Microsoft documents that domain sign-in requires HTTP CRL distribution points on both the KDC root and the logon certificate and a valid published CRL, even if empty. The KDC also always attempts OCSP.
• KDC certificates: every domain controller needs a current KDC certificate from a trusted CA; expired DC certificates break all PKINIT at that DC.
• EKU policy: the Group Policy setting "Allow certificates with no extended key usage certificate attribute" relaxes the KDC's EKU requirement. Leave it disabled unless a documented card type requires it.
• Clock and validity: client enumeration hides certificates that are not yet valid or expired, which often presents as "no certificate found" rather than a mapping error.

See the Certificate Revocation Guide for CRL and OCSP design.

Detection and measurement

Monitor the mapping layer, not just success and failure:

• Kdcsvc 41: treat as a security alert until explained; a SID mismatch is either an account lifecycle error or an attempt to use another account's certificate.
• Kdcsvc 39 and 40 trend: should fall to zero; any new source after clean-up points to a new issuance path.
• 4768 certificate fields: PKINIT logons from issuers outside the expected list, and serials absent from your CA database.
• Directory changes: writes to altSecurityIdentities and msDS-KeyCredentialLink on privileged accounts (event 5136 with SACLs configured).

Metrics that show the programme is working:

• Share of certificate logons using a SID extension or strong explicit mapping (target 100%).
• Count of accounts with weak altSecurityIdentities values remaining (target zero).
• Kdcsvc 39, 40 and 41 events per week, by template and CA.
• Domain controllers with a valid KDC certificate expiring in more than 30 days (target 100%).
• CAs in NTAuth with a named owner and a documented purpose (target 100%).

Framework mapping

Common failure patterns

• Waiting for the deadline: teams that set Compatibility mode in 2022 and never read the events met Full Enforcement as an outage.
• Fixing by relaxing: re-enabling weak Schannel mapping methods or setting the SID opt-out flag on a template to stop the calls, which reopens the vulnerability.
• Forgetting offline templates: templates where the requester supplies the subject never receive the SID extension, and they are usually the riskiest templates anyway.
• Static explicit mappings: X509IssuerSerialNumber values written once and never updated at reissue, causing a second wave of failures a year later.
• Ignoring event 41: treating SID mismatches as noise, when they are exactly the condition the fix was built to catch.
• Unowned CAs in NTAuth: old or third-party CAs still trusted for domain logon long after their purpose ended.

Practitioner checklist

• Confirm every domain controller holds a valid KDC certificate and that Kdcsvc events are forwarded to the SIEM.
• Report Kdcsvc 39, 40 and 41 by template, CA and account, and work the list to zero.
• Re-enrol certificates from online templates issued before May 2022 so they carry the SID extension.
• Add {{OnPremisesSecurityIdentifier}} as a URI SAN to Intune SCEP and PKCS profiles used for domain authentication.
• Automate X509IssuerSerialNumber or X509SKI mappings for certificates from CAs you do not control.
• Check that no template sets the SID extension opt-out flag and that Schannel CertificateMappingMethods remains at 0x18.
• Review NTAuth membership and remove CAs that no longer need to issue logon certificates.
• Alert on Kdcsvc 41 and on changes to altSecurityIdentities on privileged accounts.
• Evaluate cloud Kerberos trust for Windows Hello for Business where certificate scenarios are not required.

Standards and references

• IETF: RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• Microsoft: KB5014754 Certificate-based authentication changes on Windows domain controllers
• Microsoft Learn: Certificate requirements and enumeration
• Microsoft Learn: Create and assign SCEP certificate profiles in Intune
• Microsoft Learn: Windows Hello for Business deployment guide
• MIT Kerberos: PKINIT configuration
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Smart Card and PIV/CAC Authentication Guide · AD CS Security Guide · Kerberos Security Guide · MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide