Enterprise ADCS Security Architecture: Auditing Misconfigurations (ESC1/ESC8), Enterprise Hardening & KQL Detection Engineering (2026 Edition)

Executive Summary & Mental Model (Step 0)

Active Directory Certificate Services (ADCS) is the Public Key Infrastructure (PKI) foundation for modern Windows Enterprise environments. It facilitates identity verification, machine authentication, Smart Card logons, Code Signing, and SSL/TLS encryption across Active Directory domains.

However, default installations and improper management of Enterprise Certificate Authorities (CAs) often introduce high-severity security vulnerabilities. Misconfigured certificate templates and insecure web enrollment endpoints (such as NTLM relay targets) can allow unauthorized elevation of privilege across domain boundaries.

This guide details the structural security mechanics of ADCS misconfigurations—specifically focusing on ESC1 (SAN-based authentication abuse) and ESC8 (NTLM HTTP Relay to ADCS enrollment endpoints)—alongside concrete audit protocols, hardening standards, and production-ready KQL (Kusto Query Language) detection rules for Microsoft Sentinel and Defender for Endpoint.

1. ADCS Security Architecture & Key Boundaries

Understanding ADCS risk requires mapping the critical lifecycle of an enterprise X.509 certificate within Active Directory:

1. Certificate Templates (pKIEnrollmentService & pKICertificateTemplate): Stored in the AD Configuration Naming Context (CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...). Templates define EKUs (Extended Key Usages), enrollment permissions, and subject name generation policies.
2. Extended Key Usages (EKUs): Key usages required for identity verification include:
   • Client Authentication (1.3.6.1.5.5.7.3.2)
   • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
   • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
   • Any Purpose (2.5.29.37.0)
3. Enterprise Certificate Authority (CA): The issuing server authorized to sign requested certificates based on AD policy permissions.

2. Technical Mechanics of Critical ADCS Misconfigurations

ESC1: Subject Alternative Name (SAN) Misconfiguration

Vulnerability Mechanics: ESC1 occurs when an Enterprise CA publishes a certificate template that satisfies three simultaneous conditions:

1. Client Authentication Permission: The template permits low-privileged users (e.g., Domain Users or Authenticated Users) to request certificates.
2. Authentication EKU Present: The template includes Extended Key Usages allowing authentication (Client Authentication, Smart Card Logon, PKINIT, or Any Purpose).
3. CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT Enabled: The template flag allows the requester to supply an arbitrary Subject Alternative Name (SAN) in the Certificate Signing Request (CSR).

Impact Analysis: When ENROLLEE_SUPPLIES_SUBJECT is enabled alongside authentication EKUs, an authenticated domain user can submit a CSR specifying the User Principal Name (UPN) of a Domain Admin or privileged account in the SAN extension. The resulting X.509 certificate allows kerberos/NTLM authentication as the specified privileged account.

ESC8: NTLM Relay to ADCS Web Enrollment HTTP Endpoints

Vulnerability Mechanics: ESC8 leverages insecure authentication mechanisms on default ADCS HTTP enrollment interfaces:

1. ADCS Web Enrollment (/certsrv/) or Certificate Enrollment Service (CES) endpoints rely on NTLM authentication over HTTP.
2. Extended Protection for Authentication (EPA) is disabled or not enforced on the IIS server hosting the ADCS web services.
3. SMB or HTTP NTLM authentication requests coerced from domain machines (via forced authentication techniques or WebDAV) can be relayed to the ADCS HTTP endpoint.

Impact Analysis: An attacker relaying machine account credentials to /certsrv/ can obtain a valid machine authentication certificate signed by the CA, resulting in persistent computer account impersonation.

3. Defensive Audit Protocols & Auditing

Auditing Certificate Templates via PowerShell

Security administrators can inspect Active Directory certificate templates directly using standard PowerShell cmdlets without relying on external tooling.

Inspecting Templates with ENROLLEE_SUPPLIES_SUBJECT

# Import Active Directory module
Import-Module ActiveDirectory

# Define Configuration NC Path
$configNC = (Get-ADRootDSE).configurationNamingContext
$templatesPath = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$configNC"

# Query for templates where mPKI-Certificate-Name-Flag contains ENROLLEE_SUPPLIES_SUBJECT (0x00000001)
Get-ADObject -SearchBase $templatesPath -Filter * -Properties cn, displayName, "mPKI-Certificate-Name-Flag", "pKIExtendedKeyUsage" | ForEach-Object {
    $flag = $_."mPKI-Certificate-Name-Flag"
    if ($flag -and ($flag -band 1)) {
        [PSCustomObject]@{
            TemplateName = $_.cn
            DisplayName  = $_.displayName
            EKUs         = $_.pKIExtendedKeyUsage
            EnrolleeSuppliesSubject = $true
        }
    }
}

4. Enterprise Hardening & Remediation Protocol

To mitigate ESC1, ESC8, and related ADCS security risks, implement the following enterprise controls:

1. Remediate ESC1 Template Configurations

• Disable EnrolleeSuppliesSubject: Edit vulnerable templates via certtmpl.msc and uncheck "Supply in the request" under the Subject Name tab. Select "Build from this Active Directory information" instead.
• Restrict Enrollment Permissions: Remove broad enrollment rights (Domain Users, Authenticated Users) from sensitive templates.
• Require CA Officer Approval: Enable "Manager approval" on high-risk templates requiring custom subject names.

2. Remediate ESC8 HTTP Relaying

• Disable HTTP Web Enrollment (/certsrv): If legacy ASP web enrollment (/certsrv) is not strictly required, uninstall the Web Enrollment role service from the CA.
• Enable HTTPS and EPA: If Web Enrollment or CES must be retained:
  • Enforce HTTPS binding on all IIS Web Enrollment sites.
  • Enable Extended Protection for Authentication (EPA) in IIS for /certsrv/. Set EPA to Required.
  • Require SSL and enable client certificate authentication.

3. Implement Strong Certificate Binding

Configure Microsoft Active Directory Domain Controller registry keys to enforce strong certificate mapping (KB5014754 enforcement mode):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
"StrongCertificateBindingEnforcement"=dword:00000002

5. Enterprise KQL Detection Engineering

Deploy the following Kusto Query Language (KQL) rules within Microsoft Sentinel / Defender for Cloud Apps to monitor for suspicious certificate requests and authentication anomalies.

KQL Query 1: Suspicious Certificate Request with Explicit SAN (Event ID 4887)

Monitors Active Directory Certificate Services Audit Log (Event ID 4887: Approved certificate request) for SAN additions containing high-privilege account names.

// Detect ADCS Certificate Issuance with Custom Subject Alternative Name (SAN)
SecurityEvent
| where EventID == 4887
| where ServiceName == "CertSvc"
| extend Attributes = parse_xml(EventData).EventData.Data
| mv-expand Attributes
| where Attributes["@Name"] == "Attributes"
| extend AttributeText = tostring(Attributes["#text"])
| where AttributeText has "san:" or AttributeText has "CertificateTemplate:"
| project 
    TimeGenerated,
    Computer,
    SubjectUserName,
    SubjectDomainName,
    AttributeText,
    Activity
| order by TimeGenerated desc

KQL Query 2: Detecting Anomaly PKINIT Authenticaments (Event ID 4768)

Monitors Kerberos Authentication Service requests (AS-REQ) using PKINIT authentication certificate thumbprints where the requester identity differs from the certificate Subject.

// Monitor PKINIT Authentication Events for User Principal Name Anomalies
SecurityEvent
| where EventID == 4768 // Kerberos Authentication Ticket (TGT) Requested
| where TicketOptions has "0x40810000" or CertIssuerName != ""
| extend CertificateThumbprint = tostring(EventData.CertThumbprint)
| where isnotempty(CertificateThumbprint)
| project 
    TimeGenerated,
    TargetUserName,
    TargetDomainName,
    ClientIPAddress,
    CertIssuerName,
    CertSerialNumber,
    CertificateThumbprint

Summary Checklist for PKI Governance

Authored by Syed Zada Abrar | SentinelReign Cybersecurity Research Division