PKINIT Failure and Schannel Authentication

Active Directory environments that rely on certificate-based authentication frequently run into two closely related but distinct failure modes: PKINIT errors during Kerberos pre-authentication and Schannel authentication failures during TLS-based binds and RPC operations. Both are rooted in how Windows validates X.509 certificates against trust chains, revocation data, and mapping rules, and both are frequent targets in real-world attack chains involving certificate abuse.

This guide walks through the mechanics of PKINIT and Schannel, the most common failure codes administrators encounter, the diagnostic commands used to isolate root cause, and the security implications that penetration testers and blue teams need to understand when these subsystems misbehave.

What Is PKINIT in Active Directory Kerberos Authentication

PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) is defined in RFC 4556 and implemented by Microsoft as an extension to the standard Kerberos AS-REQ/AS-REP exchange. Instead of proving knowledge of a password-derived key, the client proves possession of a private key tied to a certificate issued by an Active Directory Certificate Services (AD CS) enterprise CA.

PKINIT underpins several critical AD features:

• Smart card logon
• Windows Hello for Business certificate trust
• Passwordless authentication schemes
• Certificate-based authentication for federated scenarios

When PKINIT fails, users are typically locked out of interactive logon even though their account and password policies are otherwise healthy, which makes it one of the more disruptive authentication failures in an enterprise.

How the PKINIT Exchange Works

1. The client builds an AS-REQ containing a PA-PK-AS-REQ pre-authentication data structure signed with the user's private key.
2. The KDC validates the certificate chain up to a trusted root, checks the certificate against revocation data (CRL or OCSP), and verifies the certificate maps to the requesting account.
3. If validation succeeds, the KDC returns an AS-REP encrypted with a Diffie-Hellman derived session key or, in older configurations, the user's long-term key.
4. If validation fails at any step, the KDC returns a KRB-ERROR with a specific error code identifying the failure stage.

Understanding which error code you are dealing with is the fastest way to root cause a PKINIT failure.

Common PKINIT Error Codes and What They Actually Mean

Event Viewer on the domain controller is the first stop. Filter the Security log for Event ID 4768 (Kerberos TGT request) and inspect the Result Code and Certificate Information fields.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768} -MaxEvents 20 |
   Where-Object { $_.Message -match "Certificate" } |
   Select-Object TimeCreated, Id, @{n='Message';e={$_.Message}} |
   Format-List


[cta]

Diagnosing the NTAuth Store Problem

The single most common PKINIT failure in production environments is a missing or stale entry in the NTAuth certificate store. The KDC will not trust a certificate for authentication purposes unless the issuing CA is published to NTAuth, even if that CA is otherwise trusted in the Trusted Root store.

Check the current NTAuth store contents:

certutil -viewstore -enterprise NTAuth


[cta]

If the issuing CA is missing, publish it:

certutil -dspublish -f "C:\certs\IssuingCA.cer" NTAuthCA
certutil -dspublish -f "C:\certs\RootCA.cer" RootCA
gpupdate /force


[cta]

Replication of this change across the forest can take time. Force replication to speed up validation during troubleshooting:

repadmin /syncall /AdeP


[cta]

Validating Certificate EKU and SAN Requirements

For PKINIT to succeed, the client certificate must contain either the Smart Card Logon (1.3.6.1.4.1.311.20.2.2) or Client Authentication (1.3.6.1.5.5.7.3.2) EKU, and the Subject Alternative Name must contain a UPN entry that exactly matches the target account's userPrincipalName attribute.

Inspect a certificate's EKU and SAN fields directly:

$cert = Get-PfxCertificate -FilePath "C:\certs\user.pfx"
$cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Enhanced Key Usage" } |
   ForEach-Object { $_.Format($false) }

$cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } |
   ForEach-Object { $_.Format($true) }


[cta]

Cross-check against the AD account:

Get-ADUser -Identity jdoe -Properties userPrincipalName |
   Select-Object userPrincipalName


[cta]

If these two values do not match character for character, the KDC will reject the AS-REQ with KDC_ERR_WRONG_REALM even though the certificate is fully trusted and unexpired. This mismatch is also a well-documented pivot point in certificate-based privilege escalation research, since altering the SAN UPN on a requestable certificate template can allow an attacker to impersonate a higher-privileged account if the template is misconfigured to allow SAN specification by the requester.

Teams performing AD CS security assessments should map every certificate template against the criteria described in the community-maintained ESC1 through ESC8 misconfiguration classes before assuming PKINIT failures are purely operational. If you are building out a structured AD CS attack path assessment methodology, Redfox Cybersecurity Academy's Active Directory security track covers certificate template auditing in depth.

What Is Schannel and Why It Fails Independently of Kerberos

Schannel (Secure Channel) is the Windows SSPI security package responsible for TLS and SSL negotiation. It underlies LDAPS binds, RPC over TLS, IIS client certificate authentication, and any service that layers TLS on top of Windows authentication. Schannel failures are distinct from PKINIT failures because Schannel operates independently of the Kerberos protocol, even though both subsystems ultimately validate certificates against the same underlying CryptoAPI and CNG certificate stores.

Schannel errors surface primarily in two places:

• System Event Log, source Schannel, typically Event IDs 36870 to 36888
• Application-specific logs for services like IIS, ADFS, or LDAPS-consuming applications

Common Schannel Error Codes

Enabling Verbose Schannel Logging

By default, Schannel logging is minimal. For real diagnostic work, raise the event logging level:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
   -Name "EventLogging" -PropertyType DWord -Value 7 -Force


[cta]

Restart the affected service, reproduce the failure, then pull the System log:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'} -MaxEvents 25 |
   Select-Object TimeCreated, Id, Message |
   Format-List


[cta]

Testing LDAPS and Certificate Chains Directly

For LDAPS-specific Schannel issues, use ldp.exe or a direct OpenSSL handshake to isolate whether the failure is chain trust, hostname mismatch, or cipher negotiation.

openssl s_client -connect dc01.corp.local:636 -showcerts -servername dc01.corp.local


[cta]

Review the output for the verify return code. A value other than "0 (ok)" points directly at the failure category, such as "unable to get local issuer certificate" for a missing intermediate, or "certificate has expired" for lifecycle issues.

To validate the full chain offline against a known-good root bundle:

openssl verify -CAfile corp-root-bundle.pem -untrusted corp-intermediate.pem server-cert.pem


[cta]

For client certificate authentication failures against Schannel-backed services, confirm the private key ACL allows the service account read access:

certutil -repairstore my <CertThumbprint>
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\*" /T


[cta]

CRL and OCSP Availability Checks

Both PKINIT and Schannel depend heavily on revocation checking, and a huge percentage of "random" authentication failures in enterprise networks trace back to blocked or unreachable CRL Distribution Points. Validate reachability directly:

certutil -URL "http://pki.corp.local/CertEnroll/IssuingCA.crl"


[cta]

For a scripted sweep across every CDP and AIA URL referenced by a certificate:

certutil -verify -urlfetch server-cert.cer


[cta]

If revocation checks are timing out rather than failing cleanly, review firewall rules between domain controllers, member servers, and the CA infrastructure, and confirm HTTP-based CDPs are not being blocked by proxy inspection that breaks certificate retrieval.

Security Implications: Why This Matters Beyond Uptime

PKINIT and Schannel troubleshooting is not purely an operations exercise. Certificate-based authentication paths are a well-established attack surface in modern AD environments, and misconfigurations that cause "annoying" authentication failures often sit next to configurations that enable serious privilege escalation.

A few patterns worth calling out for security teams:

• Templates that allow enrollee-supplied SANs combined with Client Authentication EKU create a direct path to domain escalation if any low-privileged principal holds enrollment rights.
• Weak certificate mapping (UPN-only mapping without strong binding) on domain controllers can be abused when an attacker controls a certificate with a spoofed SAN, particularly on domain controllers not yet patched against the certificate mapping changes introduced in the 2022 to 2023 KB updates addressing CVE-2022-26931 and CVE-2022-26923.
• Schannel services accepting weak cipher suites or SSL 3.0/TLS 1.0 due to legacy compatibility settings expand the downgrade attack surface for any service exposed to untrusted network segments.

Auditing these paths requires the same command set used for troubleshooting, applied with an offensive security mindset. Pulling every certificate template's enrollment permissions and EKU configuration is a standard first step:

Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" `
   -Filter * -Properties * |
   Select-Object Name, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage


[cta]

Look specifically for msPKI-Certificate-Name-Flag values that include the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit, since this is the flag that permits a requester to define their own SAN, the core requirement for the most commonly exploited AD CS escalation path.

Teams building out a full AD CS assessment workflow, from template enumeration through domain controller certificate mapping validation, will find this pairs directly with the hands-on labs in Redfox Cybersecurity Academy's certificate services security curriculum, which walks through both the defensive hardening steps and the attacker's enumeration methodology side by side.

Hardening Checklist for PKINIT and Schannel Reliability

Once root cause is identified, the following hardening steps reduce recurrence:

For PKINIT:

• Enforce strong certificate mapping on all domain controllers per current Microsoft guidance
• Restrict enrollment permissions on any template with Client Authentication or Smart Card Logon EKU
• Disable enrollee-supplied subject for templates that do not explicitly require it
• Publish CA certificates to NTAuth promptly as part of the CA deployment runbook, not as a reactive fix

For Schannel:

• Standardize TLS 1.2 minimum, TLS 1.3 where application compatibility allows
• Remove legacy cipher suites from the SChannel cipher order using Group Policy or registry configuration
• Ensure CDP and AIA URLs are reachable from every network segment that performs certificate validation, including isolated management VLANs
• Monitor Schannel event IDs 36870 through 36888 centrally, rather than relying on users to report authentication failures

Building a Repeatable Diagnostic Workflow

For recurring environments, wrap the diagnostic commands above into a single triage script that pulls Event ID 4768 details, checks NTAuth store contents, validates CRL reachability, and dumps the current Schannel cipher suite order in one pass. This turns a 30 to 45 minute manual investigation into a two minute automated check, which matters significantly during an active outage affecting smart card logon across a large user base.

If your team is standardizing this kind of tooling across multiple client environments, structured labs and command references like those in Redfox Cybersecurity Academy's identity infrastructure track are built specifically around reducing that mean time to diagnosis.

Final Thoughts

PKINIT and Schannel failures both trace back to the same underlying discipline: certificate chain trust, correct EKU and SAN configuration, timely revocation data, and consistent clock synchronization across the domain. The difference is where each subsystem sits in the stack, with PKINIT governing Kerberos pre-authentication and Schannel governing TLS negotiation for everything layered on top of it.

Treat every PKINIT or Schannel error code as a specific, traceable failure rather than a generic authentication problem. The commands and checks in this guide, from NTAuth store validation to OpenSSL chain verification to certificate template auditing, give you a repeatable path from symptom to root cause, and a way to evaluate whether a given misconfiguration is purely operational or represents a genuine security exposure worth escalating to your AD CS hardening backlog.