AD authentication with certificates: PKINIT, NTAuth, and certificate mapping

1. Core mechanism

Lesson 11.03 explained how a certificate is obtained. This lesson explains how the resulting certificate is evaluated for authentication and separates issuance from identity binding.

Interfaces and specifications

• PKINIT uses a certificate and proof of private-key possession in the AS exchange. The private key stays with the client; it is not sent to the KDC.
• The traditional certificate path evaluates chain validation and domain-authentication trust separately from account mapping. Issuance approval does not replace these checks.
• NTAuth is directory trust scope for CAs accepted for domain authentication. It is not the general root-trust decision; Key Trust has separately documented behavior.
• altSecurityIdentities can define explicit certificate mappings on an account. Read the form, version and applicable policy together.
• Key Trust is a distinct public-key account lookup path. An AD-backed KDC confirms the same public key in msDS-KeyCredentialLink; this lesson performs no attribute write or key generation.
• Interpret Kdcsvc / System events by version: no strong mapping is modern39 or legacy41; SID mismatch is modern41 or legacy49. The legacy IDs apply to Windows Server2008 R2 SP1 /2008 SP2.

PKINIT changes the proof, not the account decision

Instead of a password-based initial proof, the client cryptographically demonstrates possession of the relevant private key. The public certificate and private key have different roles; file presence is not proof of possession.

The identity question remains: for which account is this proof accepted? A CA issuing a certificate does not answer it without account binding. The resource’s later decision based on account rights is also separate.

Traditional certificate path and Key Trust

On the traditional path, certificate-chain and domain-authentication trust are separate from mapping to an account. In this fixture, rejected chain trust stops that path before mapping. With no strong mapping, the current Enforcement profile rejects authentication.

With Key Trust, the KDC looks up an account by public key. An AD-backed KDC must confirm that key in msDS-KeyCredentialLink. When a trusted account key is found, MS-PKCA specifies ignoring chain-validation errors. This is a separate path tied to that key and account, not a general removal of trust checks for arbitrary certificates. A different account found through cname is a distinct name mismatch.

Public-key lookup is unsupported on Server2012 R2 and earlier KDC versions; check the deployment version. Key Trust is not a seventh altSecurityIdentities string form. Review key-record ownership, modification rights and account associations separately in defensive inventory.

The strong-mapping inventory extends beyond six forms

Among the six explicit altSecurityIdentities forms in KB5014754, X509IssuerSubject, X509SubjectOnly and X509RFC822 are weak; X509IssuerSerialNumber, X509SKI and X509SHA1PublicKey are strong. Transferable fields such as names or email must not be assumed to bind identity durably.

The broader MS-PKCA list also includes SID and Key Trust. For explicit Issuer+SID mapping, Product Behavior scopes support to Server2022/2025 and the applicable KB5060525/KB5060841 update boundary. Verify the product and servicing profile rather than assuming support on every DC.

MS-PKCA also documents a scoped exception for configured Issuer-OID-MappingType policy. The issuer, certificate policy OID and mapping type are assessed together. Record applicable policy instead of classifying a name-based mapping solely by its visible form. This comparison does not execute that special policy.

The same Event ID can mean different things by version

No strong mapping is modern event39, or event41 on legacy Windows Server2008 R2 SP1 /2008 SP2. It is a historical Compatibility warning or an Enforcement error. A certificate predating its account is the separate modern40 / legacy48 condition, documented only for Compatibility.

Modern event41 reports a mismatch between the certificate SID and mapped user SID; its legacy ID is49. Do not treat modern41’s User SID and Certificate SID fields as the legacy41 no-strong-mapping message schema. Interpret the DC version, Kdcsvc source, System channel and message together.

Bridge to the next mechanism

Applicable February2025 updates set the Enforcement transition, and the September9,2025 update ends support for returning to Compatibility through StrongCertificateBindingEnforcement. Do not assume legacy Compatibility behavior on a current DC. Compare revocation versus verifier observation in11.05, and hybrid trust paths in12.05.

State and data flow

1. The client presents a certificate and proof of private-key possession to the KDC; the private key stays with the client.
2. Separate the selected path: chain and NTAuth on the traditional certificate path; the trusted account key and AD record on Key Trust.
3. Assess strong mapping and SID consistency on the traditional path; key/account and cname consistency on Key Trust.
4. Trust rejection, absent strong mapping or a SID/name mismatch stops continuation in the fixture. Matching selected conditions does not replace other authentication checks.
5. Neither a TGT nor resource access is observed here. Authorization after authentication is a separate account-and-rights decision by the resource.

2. Exploitation

Broken trust assumption

The review asks which binding path is accepted for a certificate or account key and which trust assumptions support it. This lesson registers no account key, issues no certificate and performs no impersonation attempt.

Technical prerequisites

• The authentication path, DC version and applicable policy are identified.
• There is separate evidence for certificate-chain trust, account mapping or a Key Trust record; presence of one does not validate the others.
• Weak-mapping risk is scoped to historical Compatibility or applicable special-policy context. Weak-only acceptance is not assumed under current Enforcement.

Exploitation mechanism

The issue is not merely certificate cryptographic strength. Examine which account a reusable-name binding selects and whether applicable policy accepts it. Key Trust asks a different question: to which account is the key trusted, and who can change that record? Transferring checks between these paths creates an incomplete risk assessment.

Find the basis of binding

A longer key does not repair incorrect account binding. Review issuer/trust scope and mapping basis for the traditional certificate path, and key provenance and administration scope for Key Trust separately.

Finding a trust record or account attribute does not establish misuse. Connect the selected path, change history and authentication evidence; do not turn unobserved outcomes into successful use.

3. Defense & Detection

Telemetry scope

• First identify the path: traditional certificate mapping or Key Trust. Record the DC version, update and policy scope.
• Inventory NTAuth/chain trust and SID/explicit mapping separately for the traditional path. For Key Trust, review account key records, provenance and modification rights.
• Do not merge39/41/49 by number: check the DC version and whether the message reports absent strong mapping or SID mismatch. Certificate predating the account is a separate40/48 condition.
• Include version/policy dependencies such as Issuer+SID and special Issuer-OID-MappingType policy. Attribute presence is not evidence that the KDC accepts the path.

Events and relevant fields

• 39 / legacy41 · Kdcsvc, System: no strong mapping. Compatibility warning; Enforcement error. Legacy scope: Server2008 R2 SP1 /2008 SP2.
• 41 / legacy49 · Kdcsvc, System: certificate SID differs from user SID. Keep this separate from legacy41’s no-strong-mapping meaning.
• 40 / legacy48 · Certificate predates the account; KB5014754 documents this as a Compatibility condition.
• 4768 · TGT request/issuance record. The Event ID alone is not PKINIT; inspect PreAuthType and certificate fields in the updated event version.

Separate path and evidence first

A certificate was issued, a mapping was found, authentication was accepted and a resource was accessed are four separate claims with different observation points. This worksheet compares bounded examples of the first decisions; it produces no TGT or resource result.

Do not interpret historical events as current DC behavior during compatibility review. Event message and version records distinguish the conditions sharing an event number.

Issued tickets and established sessions

Certificate revocation concerns fresh PKINIT attempts; by itself it does not establish that earlier TGTs, service tickets or application sessions ended. 11.05 separates fresh certificate attempts from earlier ticket and session observations.

Detection logic · XPath

*[System[(EventID=39) and Provider[@Name='Kdcsvc']]]

Query assumptions

• This XPath selects Kdcsvc Event39 in the DC System log; it does not collect all certificate-authentication failures.
• Check DC version and message separately. Do not assign the same meaning to legacy no-strong-mapping41 and modern SID-mismatch41.
• The synthetic XML is only an Event39 / Level3 Compatibility envelope. Event message fields have not been invented as EventData.

False positives

• A mapping problem alone is not proof of malicious activity. Review the account, issuer, update and event message together.
• No Event39 does not establish widespread strong mapping: certificate authentication may not have occurred, logs may be incomplete or the event number may differ by version.

Hardening

• Manage general trust separately from domain-authentication trust for the traditional certificate path; restrict the scope to required issuers.
• Validate the binding basis and applicable policy. Review Key Trust record administration separately from explicit certificate-mapping administration.
• Remediate weak-mapping dependencies and validate current Enforcement behavior. Do not plan a return to Compatibility through the retired StrongCertificateBindingEnforcement setting on September9,2025+ updates.
• Before changing policy, identify account and application dependencies on each binding path; do not equate authentication eligibility with resource permission.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Kdcsvc"/><EventID>39</EventID><Level>3</Level><Channel>System</Channel><Computer>DC01.outreason.example</Computer></System></Event>

Two reality checks

Assumption: A valid certificate chain automatically establishes the account identity.

In fact: Chain trust does not select account binding. Traditional certificate mapping and Key Trust have different binding bases; eligible binding still does not decide resource rights.

Assumption: Every altSecurityIdentities value is strong, and all KDC versions support identical paths.

In fact: KB5014754 classifies three of its six forms as weak. The broader MS-PKCA inventory also includes Key Trust and version-scoped Issuer+SID. Inspect the form together with DC version and special-policy scope.

Sources

• Microsoft · KB5014754: Certificate-based authentication changes on Windows domain controllers
  Audit event table, six altSecurityIdentities mappings, Compatibility/Enforcement behavior, and the September 9, 2025 retirement of StrongCertificateBindingEnforcement registry support.
• Microsoft Open Specifications · [MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol
  Protocol scope and overview for the Windows implementation of the PKINIT extension.
• IETF · RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos
  PKINIT flow and the table of PKINIT-specific KDC error codes.
• Microsoft · certutil
  Command reference for directory-based CA trust stores and certificate validation operations.
• Microsoft · Event 4768: A Kerberos authentication ticket (TGT) was requested
  Event versions and Pre-Authentication Type table; updated version includes PreAuthType and certificate fields. PA-PK-AS-REQ (16) is listed for smart-card authentication scenarios; the event ID alone should not be treated as the authentication method.
• MS-PKCA · Key Trust
  §3.1.5.2.1.4: public-key lookup, AD confirmation and conditional chain-error behavior.
• MS-PKCA · Mapping Strength
  §3.1.5.2.1.5: broader mapping inventory and scoped issuer/OID policy exception.
• MS-PKCA · Product Behavior
  Footnotes23/26/27: Key Trust version exclusion, Issuer+SID update scope and special-policy scope.
• RFC4120 · Kerberos ticket lifecycle
  §1.1 and §3.3.3.1; ticket lifetime and TGS/hot-list scope; not a Windows control recipe.
• MS-KILE · Check Account Policy for Every Session Ticket Request
  §3.3.5.7.1; conditional account-standing validation is not certificate-status checking.