Active Directory Certificate Services: Pentest Priorities and Defensive Remediation

Source review: 13 September 2026. The procedures and tables below are proposed assessment practices. References support the technical behavior and source recommendations; they do not imply that a source mandates this exact scope or record format.

Active Directory Certificate Services (AD CS) issues and manages certificates used for authentication and secure communication. Certificate-template permissions and identity settings affect who can obtain a certificate and which identity it can represent. A review therefore needs to connect the issuing configuration with the systems that trust the public key infrastructure (PKI). 3 1

This article is a review guide for defenders and authorized security testers. It focuses on configuration evidence, trust relationships, and remediation decisions. It does not describe exploitation steps. The aim is to answer a simpler operational question: which parts of AD CS should be examined first, what would a meaningful finding look like, and how should the organization remove the underlying condition rather than merely suppress symptoms? 3 1

Start with the trust model, not the server list

An AD CS review should begin by mapping what the PKI is allowed to prove. Identify each certification authority (CA), whether it is enterprise or standalone, the issuing hierarchy, enrollment endpoints, certificate templates, registration authorities, and the systems that accept certificates for authentication, signing, encryption, or device access. Include subordinate CAs, offline roots, network device enrollment, smart-card or Windows Hello for Business dependencies, and any third-party application that validates certificates against the same hierarchy. 3 1

The important question is not only “Which CA is online?” It is “Who can obtain which kind of certificate, under which conditions, and what can a relying system do with it?” A certificate used only for a web-server name has a different risk profile from one accepted for domain authentication. A template that allows subject details to be supplied by the requester demands more scrutiny than one whose identity fields are populated from a controlled directory attribute. 3 1

Useful evidence includes CA configuration exports, published templates, template access control lists, enrollment-service settings, issued-certificate logs, CA backup procedures, and the certificate mappings configured on relying systems. Keep the review scoped: a template is not automatically dangerous merely because it has broad availability. Its intended use, approval controls, identity binding, and actual enrollment population determine the result. 3 1

Review certificate templates as authorization objects

Certificate templates define enrollment and configuration permissions that must be reviewed as authorization policy. Review every published template that can issue client-authentication-capable certificates, certificates for enrollment agents, CA-related certificates, or certificates with unusually broad intended usage. 1

For each template, establish four facts. First, which security principals can enroll, autoenroll, modify the template, or manage the CA that publishes it? Second, which extended key usages and application policies make the resulting certificate valuable to a relying party? Third, how is the subject and subject alternative name populated? Fourth, what approval, signature, renewal, and validity controls apply? 1

Risk rises when a low-privileged population can obtain a certificate that a high-value service will accept as another identity, especially when the template or CA policy permits requester-supplied identity data. The same is true when non-PKI administrators can change template settings, publication state, or CA configuration. These are distinct controls and should be reported separately. A restrictive enrollment list does not compensate for overly broad template-management rights, and approval requirements do not help if they are absent from a renewal path. 1

Document the effective permissions, including inherited entries and group nesting. “Authenticated Users” may be appropriate for a tightly bounded workstation certificate template; it deserves a separate design decision when the template supports client authentication. Also identify templates that are no longer used. Check whether dormant templates retain insecure settings after their original project has ended. 1

Inspect enrollment surfaces and CA administration

Enrollment endpoints expose policy to users and devices. Review web enrollment, certificate enrollment policy services, network device enrollment services, and any custom registration portal. Confirm whether legacy components remain enabled without a current business requirement. If they are confirmed unnecessary, recommend retiring them after dependency checks, a tested change and service-owner approval. Verify transport protection, authentication boundaries, service-account permissions, and how the endpoint selects or limits templates. 1

CA administration is a separate high-impact boundary. Identify accounts and groups able to administer the CA, approve requests, manage officer rights, alter enrollment agent restrictions, publish templates, or access CA private-key material and backups. Administrative access should be limited, attributable, and separated from routine domain administration where the operating model permits. A compromise of a broadly trusted CA can invalidate ordinary assumptions about account authentication. 1

Physical and logical protection of private keys deserves equal attention. Determine whether hardware-backed key protection is used where appropriate, who can initiate backup or restoration, how backups are encrypted, and whether recovery material is stored separately from the CA. Testers should verify documented safeguards and access boundaries without attempting to extract or use private keys. 4

Look for lifecycle failures that extend trust

Include changes made after initial deployment in the PKI review. Review certificate validity periods, renewal behavior, revocation publication, template versioning, and the process for retiring a template or CA. Check how each relying service responds to an account or role change; certificate validity alone does not establish that access remains possible. 4

Revocation is only protective when relying parties can obtain and enforce current revocation information. Review certificate revocation list (CRL) and authority information access publication locations, availability from relevant networks, update scheduling, monitoring, and client behavior during an outage. Do not infer that a CRL is effective simply because a URL exists in a certificate. Validate that relevant services can reach the published data and that operational teams can detect failed publication before the next scheduled review. 4

The inventory should also include issued certificates for privileged identities, enrollment agents, service accounts, and former systems. This is not a request to revoke everything; it is a way to establish a controlled response when a template setting, administrator account, or CA key is suspected to be compromised. 4

Detection that supports investigation

Include CA activity in the review and forward relevant CA audit events and enrollment-service logs to the central logging platform, then retain the context needed to interpret them: requestor, template, issued certificate serial number, approval actor, source system, and disposition. Pair these records with directory changes to templates, CA permissions, and group membership. 2

Alerting should focus on events that change authority: publication of a new template, changes to enrollment or management permissions, enrollment-agent activity, unexpected issuance for high-value templates, failed or delayed CRL publication, and CA backup or recovery actions. Thresholds should reflect the environment. A certificate-management team that legitimately issues large volumes needs different detection logic from a small internal PKI. 2

Run a recovery exercise that includes revocation, template withdrawal, and CA-key compromise communications. The exercise should establish decisions and ownership: who approves emergency revocation, how relying systems are notified, and how authentication dependencies are restored. A recovery plan that does not account for the services trusting the certificate hierarchy may turn a security response into an availability incident. 2

Practical template review record

This fictional review record turns the template and enrollment checks into an owner, a change, and observable retest evidence. It is a proposed working format; the configuration prerequisites come from Microsoft's certificate assessments. A configuration finding does not demonstrate impersonation. 1

Remediation sequence

Start by confirming the owners, usage and dependencies of published templates and enrollment services. If a component is confirmed unnecessary, recommend retiring it through an approved, tested change with a rollback plan. Then restrict template enrollment and management permissions to the smallest justified groups. Require directory-controlled identity fields for templates that support authentication, unless there is a documented business reason and compensating approval control for requester-supplied values. Limit high-value application policies to purpose-built templates, use approval or authorized-signature requirements where the workflow supports them, and review renewal paths separately. 1

Next, separate CA administration from ordinary operations, protect CA keys and backups, and implement a formal change process for templates and CA settings. Finally, make monitoring and recovery part of the service: validate revocation publication, centralize auditable events, and rehearse response procedures. 1

An effective retest compares the published template set, effective permissions, and issued-certificate population with the approved design. It should also check whether delegated groups, inherited permissions or other enrollment endpoints could reintroduce the condition, and record the tested scope, results and limitations. A retest does not guarantee that the condition cannot recur. 1

FAQ

Is AD CS only a concern for organizations using smart cards?

No. AD CS can support workstation, server, VPN, Wi-Fi, application, device, and user authentication. The review should follow the certificate’s relying parties, not a single enrollment use case. 3 1

Should every client-authentication template require manager approval?

Not necessarily. Approval can slow legitimate automation and is not a substitute for correct identity binding and access control. Apply it where the certificate’s authority and the enrollment workflow justify a human decision. 1

What is the most useful first remediation action?

Create an approved inventory of published templates and resolve missing ownership and usage information. Recommend disabling a template only after confirming it is unnecessary and testing its dependencies and rollback procedure with the service owner. This makes the remaining authorization decisions visible. 1

Internal links: Active Directory expertise · Kerberos coverage · Administrative separation

For planning the next steps, see NTLM Relay Attacks: Why Your Network Is an Open Door and Penetration Test Retest: Turn Findings into Verified Remediation.