Harden Active Directory Certificate Services before templates become privilege paths

Source facts: AD CS is identity and cryptographic infrastructure

Microsoft’s AD CS PKI design guidance calls for deliberate decisions about CA hierarchy, request approval, cryptography, names, validity, database, revocation, and Authority Information Access and Certificate Revocation List distribution points. It describes hardware security modules as a way to provide a protected hardware store for CA keys where the design calls for one.

Microsoft’s certificate-template management documentation explains that templates are stored in Active Directory, can be published to enterprise CAs, and include permissions and configuration that control enrollment and certificate purpose. Changes and deletion can affect all enterprise CAs or future issuance, which makes casual cleanup dangerous.

CISA’s joint guidance on living-off-the-land techniques identifies AD CS among high-value Microsoft identity infrastructure that should receive appropriate hardening. None of these sources makes one checklist safe for every PKI. Certificate use, application dependencies, offline roots, cryptographic policy, legal requirements, and supported Windows versions vary; qualified PKI expertise is required.

DSE recommendation: treat issuance paths like privileged code

Begin with a read-only PKI map: every CA and hierarchy relationship, operating system and role service, database and key location, HSM, service account, administrative group, enrollment endpoint, template and publishing CA, CRL and AIA URL, OCSP responder, trust distribution, backup, recovery owner, and dependent application. Protect the inventory because it reveals identity infrastructure.

Identify privilege-bearing templates. Review purposes and enhanced key usages, subject and subject-alternative-name construction, requester-supplied values, manager approval, authorized signatures, enrollment and autoenrollment permissions, private-key export, validity, renewal, and which CAs publish the template. Prioritize certificates usable for authentication or powerful signing.

Restrict control planes. Limit who can administer CAs, templates, configuration, service accounts, HSMs, backups, and enrollment agents. Review inherited and delegated ACLs. Separate routine certificate operations from domain-wide administration where the supported design permits.

Reduce exposed services. Inventory web enrollment, certificate enrollment web services, policy web services, NDES, RPC, SMB, HTTP, and relay-relevant paths. Remove services not required; for required endpoints, apply current Microsoft mitigations, channel protections, segmentation, and monitoring without breaking enrollment clients.

Protect signing keys and availability. Verify key protection, backup custody, offline components, database backup, configuration, CA certificates, key recovery where applicable, power, time, name resolution, and revocation publication. Test restoration in an isolated authorized environment rather than assuming a file copy is sufficient.

Monitor issuance and change. Enable supported auditing, centralize protected logs, and review template publication, ACL changes, CA configuration, enrollment-agent activity, unusual requesters, unexpected subject names, failed issuance, revocation, and service installation. Correlate with directory and endpoint telemetry.

Change with certificate impact analysis. Before disabling a template, service, algorithm, endpoint, or CA, identify issued certificates, renewal behavior, autoenrollment, applications, devices, and outage consequences. Pilot replacements, preserve rollback where safe, and verify revocation and trust paths from representative clients.

Do not publish a copied template merely because it has a safer-looking name; its effective permissions and fields matter. Do not assume an offline root protects an issuing CA or template with excessive authority. Conversely, do not revoke or remove certificates in bulk without understanding authentication, encryption, signature validation, and recovery impact.

The assessment should produce ranked issuance paths, owners, approved remediation, compensating controls, and retest evidence. AD CS hardening is complete only when the organization can explain who may cause which certificate to be issued, how that action is observed, and how trust and revocation continue through failure and recovery.

Stop a change if representative clients cannot build the chain, locate revocation information, renew before expiry, or use the certificate for its approved purpose. Preserve the prior template or endpoint only when the rollback is safe and authorized. A security improvement that silently breaks authentication, decryption, or signature validation needs controlled redesign—not an undocumented emergency exception.

Official references

Microsoft, PKI design considerations using Active Directory Certificate Services.

Microsoft, Manage certificate templates in Windows Server.

Cybersecurity and Infrastructure Security Agency, Identifying and Mitigating Living Off the Land Techniques.