What is Active Directory Certificate Services

Active Directory Certificate Services, often shortened to AD CS or ADCS, is Microsoft’s public key infrastructure platform for issuing and managing certificates in Windows environments. The simplest way to think about AD CS is that AD CS allows an organization to issue trusted internal certificates for users, computers, services, devices, and applications. Those certificates may be used for many purposes, including authentication, encryption, signing, VPN, Wi-Fi, smart cards, web servers, device identity, and secure communication.

AD CS can be extremely useful. It can also become one of the most sensitive parts of an Active Directory environment. If certificate templates, enrollment permissions, certificate authorities, or certificate mapping controls are misconfigured, attackers may be able to request certificates that let them authenticate as other users, computers, or privileged identities.

What is a certificate?

A certificate is a digital identity document. It helps prove that a user, computer, service, or device is associated with a public key.

In an Active Directory environment, certificates may be used by:

Users
Computers
Domain controllers
Web servers
VPN systems
Wi-Fi authentication
Smart cards
Service accounts
Applications
Management platforms

A certificate usually includes information such as the subject, issuer, validity period, public key, intended usage, and other extensions. The private key associated with the certificate is critical. If someone controls the private key, they may be able to use the certificate for its intended purpose.

What is a certificate authority?

A certificate authority, or CA, is a system that issues certificates. In AD CS, an enterprise CA integrates with Active Directory. This allows certificate templates, enrollment permissions, and directory identity information to be used when issuing certificates.

A CA is trusted because other systems rely on it to say This certificate was issued by a trusted authority. That trust is powerful. If a CA is compromised or configured insecurely, attackers may be able to issue or obtain certificates that are trusted across the environment.

What is AD CS used for?

AD CS is commonly used for internal certificate needs.

Common use cases include:

Use Case	Example
User authentication	Smart card logon or certificate-based authentication
Computer authentication	Domain-joined devices authenticating to network services
Wi-Fi authentication	802.1X certificate-based access
VPN authentication	User or device certificates for remote access
Web server certificates	Internal HTTPS services
Code signing	Signing scripts or internal software
Email security	Signing or encrypting email
Device identity	Certificates for managed endpoints or appliances
Domain controller certificates	LDAPS and certificate-based authentication scenarios

AD CS often becomes deeply embedded in infrastructure. That is why security changes need to be tested carefully before being applied broadly.

Why AD CS matters for security

AD CS matters because certificates can act like credentials.

In some scenarios, a certificate can be used to authenticate as a user or computer account. That means certificate issuance is not just an administrative process. It can become an identity control. If a low-privilege user can request a certificate that allows authentication as another identity, the result can be privilege escalation. If an attacker can relay authentication to an AD CS enrollment endpoint and obtain a usable certificate, the result can be persistent access. If a certificate template allows dangerous subject or Subject Alternative Name values, the result can be impersonation. AD CS should be reviewed as part of Active Directory security, not treated as a separate infrastructure service.

Core AD CS components

AD CS environments vary, but several components are common.

Certificate Authority

The CA issues certificates. An enterprise CA integrates with Active Directory and can issue certificates based on published templates.

Root CA

The root CA is the top of the trust chain. In many environments, the root CA is offline and used only to sign subordinate CAs.

Issuing CA

An issuing CA issues certificates to users, computers, services, or devices. This is often the CA most administrators interact with day to day.

Certificate Template

A certificate template defines what kind of certificate can be issued, who can request it, what the certificate can be used for, and what information can appear in it. Microsoft notes that templates simplify CA administration by allowing administrators to issue certificates preconfigured for selected tasks.

Enrollment Permissions

Enrollment permissions control who can request certificates from a template.

Autoenrollment

Autoenrollment allows certificates to be automatically issued and renewed for users or computers based on policy and template permissions.

Web Enrollment

Web enrollment provides an HTTP-based way to request certificates. If misconfigured, web enrollment can become a significant relay target.

Certificate Revocation List

A certificate revocation list, or CRL, allows systems to determine whether a certificate has been revoked before its expiration date.

What is a certificate template?

A certificate template is one of the most important security objects in AD CS.

Templates define certificate behavior, including:

Who can enroll
Whether autoenrollment is allowed
What the certificate can be used for
Whether the requester can supply subject information
Whether approval is required
Whether private keys can be exported
How long the certificate is valid
Which cryptographic settings are used
Whether the certificate can be used for authentication

Certificate templates are managed through the Certificate Templates MMC snap-in and can be managed locally or remotely. From a security perspective, templates deserve careful review because a dangerous template can allow a low-privilege user to obtain a high-impact certificate.

Why authentication-capable templates are sensitive

Some certificates can be used for authentication.

Templates are especially sensitive when they include purposes such as:

Client Authentication
Smart Card Logon
PKINIT Client Authentication
Any Purpose
No EKU restriction in some scenarios

An authentication-capable certificate may allow the holder to authenticate as the identity represented in the certificate. This becomes dangerous when the template also allows broad enrollment or lets the requester control identity-related fields, such as subject or Subject Alternative Name values. A safe AD CS review should always identify which templates can issue authentication-capable certificates.

Why enrollment permissions matter

Enrollment permissions decide who can request certificates from a template. Broad permissions are not always bad. Some templates are intended for many users or computers. The risk depends on what the certificate can do. A low-risk template with broad enrollment may be acceptable. A high-impact authentication template with broad enrollment may be dangerous.

Review enrollment permissions carefully for groups such as:

Domain Users
Authenticated Users
Domain Computers
Everyone
Large application groups
Help desk groups
Non-PKI administrator groups

The key question to answer is who can request this certificate, and what can they do with it after they receive it?

Common AD CS security risks

AD CS security risk usually comes from combinations of settings.

Common risk areas include:

Broad enrollment on authentication-capable templates
Templates where requesters can supply subject information
Templates where requesters can supply Subject Alternative Name values
Templates with Any Purpose EKU
Templates with no EKU restriction
Exportable private keys
Weak template ACLs
Weak CA permissions
Enrollment agent misuse
Insecure web enrollment endpoints
Weak certificate mapping
Long-lived certificates
Poor monitoring of certificate issuance
Old templates that no one owns

A single setting may not be dangerous by itself. The risk usually comes from how template purpose, enrollment rights, subject control, approval requirements, and authentication behavior combine.

AD CS and NTLM relay

AD CS became a major focus for many defenders because of NTLM relay paths against certificate enrollment endpoints. If AD CS web enrollment or related HTTP enrollment services accept NTLM authentication without sufficient protections, attackers may be able to relay authentication to the enrollment endpoint and request a certificate.

Microsoft published guidance for mitigating NTLM relay attacks against AD CS. Microsoft recommends protections such as Extended Protection for Authentication, disabling NTLM on AD CS web enrollment servers where possible, and removing vulnerable enrollment services if they are not needed.

This is one reason AD CS security often overlaps with NTLM relay, LDAP signing, LDAP channel binding, SMB signing, and Extended Protection for Authentication.

AD CS and certificate-based authentication changes

Certificate-based authentication has also received attention because of changes to how Windows domain controllers handle certificate mapping. Microsoft’s KB5014754 covers certificate-based authentication changes on Windows domain controllers and is important reference material for environments that use certificates for authentication. This matters because certificate mapping determines how a certificate is associated with an Active Directory identity.

Weak or legacy mappings can create impersonation risk. Strong mapping helps ensure that certificates authenticate as the correct account.

What are ESC findings?

You may see AD CS escalation paths described as ESC findings. ESC findings are commonly used to describe known AD CS misconfiguration patterns that can lead to privilege escalation. They are not a Microsoft product feature. They are a way the security community often groups AD CS attack paths.

Common ESC-style risks involve:

Dangerous certificate template settings
Broad enrollment permissions
Weak template ACLs
Weak CA permissions
Enrollment agent abuse
NTLM relay to web enrollment
Weak certificate mapping
Misconfigured issuance requirements

For defenders, the important point is not memorizing every label. The important point is understanding whether a certificate configuration allows an attacker to obtain a certificate that can authenticate as a more privileged identity.

Why AD CS is often overlooked

AD CS is often overlooked because it sits between infrastructure, identity, security, and application teams.

Common reasons it gets missed include:

PKI was deployed years ago and rarely reviewed.
Certificate templates were copied and modified without security review.
Enrollment permissions were granted broadly for convenience.
Web enrollment was enabled for legacy workflows and forgotten.
Application teams depend on certificates but do not own PKI risk.
Security teams focus on accounts and groups but not certificates.
Administrators do not always understand certificate authentication paths.
Certificate issuance is treated as operational plumbing instead of identity security.

This creates a gap. AD CS may be trusted by the domain, but not reviewed with the same rigor as domain controllers or privileged groups.

What defenders should review first

A practical AD CS review should start with the highest-impact areas.

1. Identify all enterprise CAs

Know which CAs exist, which are issuing certificates, and which are still trusted.

2. Identify published templates

Published templates are available for issuance from a CA. Review which templates are actually active.

3. Find authentication-capable templates

Look for templates that can issue certificates usable for authentication.

4. Review enrollment permissions

Focus on who can request certificates from high-impact templates.

5. Review subject and SAN control

Templates where requesters can supply identity information deserve special attention.

6. Review template ACLs

Identify who can modify templates. Weak template permissions can turn a safe template into a dangerous one.

7. Review CA permissions

Identify who can manage the CA, issue certificates, approve requests, or change CA configuration.

8. Review web enrollment

Determine whether web enrollment services exist, whether they are needed, and whether they are protected against NTLM relay.

9. Review certificate mapping

Understand how certificates map to users and computers for authentication.

10. Monitor certificate activity

Certificate issuance and template changes should be visible to defenders.

PowerShell: Find enterprise certificate authorities

You can use certutil to identify enterprise CAs published in Active Directory:

certutil -config - -ping

You can also review enterprise CA objects in Active Directory:

Get-ADObject `
  -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" `
  -LDAPFilter "(objectClass=pKIEnrollmentService)" `
  -Properties dNSHostName, certificateTemplates |
  Select-Object Name, dNSHostName, certificateTemplates

Replace the domain components with the correct distinguished name for your environment.

PowerShell: Find certificate templates

Certificate templates are stored in the Configuration partition.

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag |
  Select-Object Name, displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag

This gives you a starting point for reviewing template settings.

PowerShell: Find templates with client authentication EKU

Client Authentication is one of the most important EKUs to review.

$ClientAuthEku = "1.3.6.1.5.5.7.3.2"

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage |
  Where-Object { $_.pKIExtendedKeyUsage -contains $ClientAuthEku } |
  Select-Object Name, displayName, pKIExtendedKeyUsage

Treat this as a review list, not an automatic finding. Some client authentication templates are expected. The question is whether permissions and subject controls are safe.

PowerShell: Review template permissions

Template ACLs should be reviewed because users with write access may be able to modify a template into a dangerous state.

$TemplateDn = "CN=TemplateName,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com"

Get-Acl "AD:\$TemplateDn" |
  Select-Object -ExpandProperty Access |
  Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited

Pay attention to rights such as:

GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty

These permissions may allow unauthorized modification of certificate template behavior.

PowerShell: Check for AD CS web enrollment roles

On a CA server, review whether web enrollment-related role services are installed.

Get-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-Svc, ADCS-Enroll-Web-Pol

Relevant services include:

ADCS-Web-Enrollment
ADCS-Enroll-Web-Svc
ADCS-Enroll-Web-Pol

If these are installed, review whether they are needed and whether they are protected against NTLM relay.

GUI: Review certificate templates

You can review templates using the Certificate Templates MMC snap-in (certtmpl.msc).

Review each high-impact template for:

Intended purpose
Enrollment permissions
Autoenrollment permissions
Subject name settings
Application policies
Issuance requirements
Private key export settings
Validity period
Template ACLs

Focus first on templates that support authentication.

GUI: Review CA configuration

You can review CA configuration using the Certification Authority console (certsrv.msc).

Review:

Published templates
Pending requests
Issued certificates
Failed requests
Revoked certificates
CA security permissions
CA properties
Enrollment agent restrictions
Auditing configuration

CA administration should be limited to trusted PKI administrators.

Detection opportunities

AD CS monitoring should include both configuration changes and certificate issuance activity.

Useful activity to monitor includes:

Certificate template changes
CA configuration changes
CA permission changes
Certificate issuance from authentication-capable templates
Failed or denied certificate requests
Enrollment agent usage
Web enrollment activity
Changes to certificate mapping attributes
Unusual certificate requests from unexpected systems
Certificate requests involving privileged identities
New or modified templates published to CAs

AD CS is not always noisy, so meaningful changes should be investigated carefully.

Common mistakes

Treating AD CS as only infrastructure

AD CS is identity infrastructure. Certificates can authenticate users, computers, and services.

Ignoring certificate templates

Templates define certificate behavior. Dangerous templates are one of the most common AD CS risk areas.

Leaving broad enrollment on powerful templates

Broad enrollment may be acceptable for low-impact templates, but it is dangerous on authentication-capable templates with weak controls.

Allowing requesters to supply identity fields

Templates that allow requesters to supply subject or SAN values should be reviewed carefully, especially if the certificate can be used for authentication.

Forgetting about web enrollment

AD CS web enrollment can introduce NTLM relay exposure if it is not hardened.

Not monitoring certificate issuance

A certificate request can be security-sensitive. Issuance from authentication-capable templates should be visible.

Assuming expired projects mean safe templates

Old templates may remain published and usable even after the original business need is gone.

Ignoring private key export

Exportable private keys can make certificate theft and reuse easier.

Practical recommendation

A practical first AD CS review should include:

Identify all enterprise CAs.
Identify all published templates.
Find authentication-capable templates.
Review enrollment permissions.
Review templates where requesters can supply subject or SAN values.
Review templates with Any Purpose or no EKU restrictions.
Review template ACLs for excessive write permissions.
Review CA permissions.
Identify web enrollment endpoints.
Harden web enrollment against NTLM relay.
Review certificate mapping behavior.
Monitor certificate issuance and template changes.
Remove unused templates from issuing CAs.
Document template owners and approved use cases.

Do not start by changing everything at once. Start by identifying the templates and CAs that create the most risk, then prioritize fixes that reduce impersonation, relay, and privilege escalation paths.

Summary

Active Directory Certificate Services is Microsoft’s PKI platform for issuing and managing certificates in Windows environments. It is commonly used for authentication, encryption, signing, VPN, Wi-Fi, smart cards, web servers, and device identity. AD CS is powerful because certificates can act as credentials. Misconfigured templates, broad enrollment permissions, weak CA permissions, insecure web enrollment, or weak certificate mapping can create serious privilege escalation paths.

Defenders should treat AD CS as part of Active Directory security. The most important starting points are enterprise CAs, published templates, authentication-capable certificates, enrollment permissions, template ACLs, web enrollment exposure, and certificate-based authentication mapping. A secure AD CS environment is not just one where certificates are issued successfully. It is one where certificate issuance is controlled, monitored, justified, and resistant to abuse.