When a base Enterprise Active Directory Certificate Services (AD CS) server is installed, it comes with insecure defaults that can expose your environment to certificate-based attacks.
By default, the CA automatically publishes 11 certificate templates, several of which are vulnerable and can be abused for privilege escalation.
In addition, risky access control entries (ACLs) on the CA’s computer object and insecure registry settings such as SAN injection and unencrypted requests further increase the attack surface.
To build a secure foundation, these defaults must be remediated:
- Remove default templates to eliminate vulnerable enrollment paths.
- Harden registry settings to prevent SAN abuse and enforce secure request handling.
- Clean up account permissions and ACLs so unprivileged groups cannot take control of the CA host.
This guide walks through securing an Enterprise CA deployment step by step — from stripping out default templates, to locking down AD permissions, to applying registry hardening, and finally validating with Locksmith to ensure no issues remain.
🔑 Common Vulnerabilities in Default Templates
1. Overly Broad Enrollment Permissions (ESC1)
- Templates like User or Computer allow Authenticated Users or Domain Users to enroll.
- Attackers can request certificates that give them network logon or impersonation rights.
2. Client Authentication via User Templates (ESC2)
- If a User template allows client authentication and users can specify the SubjectAltName, an attacker can request a cert as any user, including domain admins.
3. Misuse of the ENROLLEE_SUPPLIES_SUBJECT Flag (ESC3)
- When subjects (usernames) are not validated, attackers can supply arbitrary identities → certs that let them impersonate privileged accounts.
4. Vulnerable Certificate Authorities Allowing Agent or Enrollment Agent Templates (ESC4)
- If Enrollment Agent templates are enabled, attackers can use them to issue certificates on behalf of other users.
5. NTLM/Weak Crypto Usage (ESC5)
- Templates still using SHA-1 or short RSA keys (1024-bit) allow downgrade attacks and are considered unsafe.
6. Dangerous EKUs (Extended Key Usages) (ESC6)
- Templates with both Client Authentication and Smartcard Logon EKUs can be abused for persistence and privilege escalation.
7. Weak or Legacy Crypto Providers (ESC7)
- Templates configured with outdated CSPs (Cryptographic Service Providers) can be abused or are incompatible with modern security baselines.
8. Misconfigured Certificate Authority Access (ESC8)
- Broadly accessible CA objects (permissions on the CA itself, not just templates) allow attackers to re-enable or misuse vulnerable templates.
⚠️ In Plain Terms
- The default templates often:
- Let too many people request certs.
- Allow impersonation of other users or services.
- Use weak or outdated crypto settings.
- Provide privilege escalation paths if not locked down.
Checking for Vulnerable CA Templates
After setting up our Active Directory Certificate Authority (AD CS) server (click here to view the setup), the next step is to secure it by removing all default issued templates. Before we do that, we’ll use the Locksmith tool to perform a baseline audit. This will allow us to verify our current configuration and confirm that several of the default templates are indeed vulnerable to the attacks described above.
Official Locksmith GitHub page and install instructions: https://github.com/jakehildreth/Locksmith
Locksmith Scan
Let’s begin by running Locksmith in audit mode. This will give us a clear view of which default templates are currently enabled and highlight any that are vulnerable.
CMD: Invoke-Locksmith -Mode 1
Result: (This is a large output, so I have just included some snippets)
Technique : ESC5
Object Name : SRV3
Risk : High
DistinguishedName : CN=SRV3,OU=SRV3,OU=BNBC-Servers,DC=BugNBuyCo,DC=local
objectClass : computer
Issue : S-1-5-32-548 has GenericAll elevated rights
on this computer object.
Technique : ESC15/EKUwu
Template Name : User
Risk : High
DistinguishedName : CN=User,CN=Certificate Templates,CN=Public Key
Services,CN=Services,CN=Configuration,DC=BugNBuyCo,DC=local
Enabled : True
EnabledOn : {BNBC-CA}
Issue : User uses AD CS Template Schema Version 1, and BUGNBUYCO\Domain Users
is allowed to enroll in this template.
If patches for CVE-2024-49019 have not been applied it may be possible to include
arbitrary Application Policies while enrolling in this template, including
Application Policies that permit Client Authentication or allow the creation
of Subordinate CAs.
📝 Overall Risk Summary
Two high-risk misconfigurations were found:
- ESC5: Over-privileged group rights on a critical computer object.
- ESC15/EKUwu: Insecure certificate template available to all users.
Both provide potential paths to privilege escalation or full AD compromise if not remediated.
🔒 Enterprise CA Hardening Steps
Remove Default Certificate Templates
- Open Certification Authority MMC → expand BNBC-CA.
- Go to Certificate Templates → Issued Certificates.
- Right-click each default template (User, Computer, Web Server, etc.) → Delete.
Right-click each template and choose Delete. This action only removes the template from being issued in the domain—it does not delete the template itself.
Confirm that no default templates remain
✅ Removes ESC1–ESC4 risks (overly permissive templates).
Remove Broad ACLs from SRV3$ (CA Host Object in AD)
- Remove Broad ACLs from SRV3 (CA Host Object in AD)
- Open Active Directory Users and Computers (ADUC).
- Enable Advanced Features (View → Advanced Features).
- Navigate to SRV3 → Properties → Security → Advanced.
- Remove Account Operators and any Unknown SIDs.
✅ Removes ESC5 (overly broad rights on CA host).
🔒 PowerShell Hardening Script (ESC6, ESC11, ESC16)
Once you’ve removed vulnerable certificate templates and tightened AD permissions, the next step is to harden the CA’s registry configuration. Several high-impact AD CS attack paths (ESC6, ESC11, ESC16) stem from insecure defaults at the CA level, not from templates.
This script will:
- Back up the CA’s registry configuration (so you can safely roll back if needed).
- Disable SAN injection (ESC6), which prevents attackers from requesting certificates with arbitrary Subject Alternative Names.
- Enforce encrypted certificate requests (ESC11), ensuring all cert requests are protected in transit.
- Enable the NTDS CA Security Extension (ESC16), closing a loophole that can otherwise allow privilege escalation.
- Restart the Certificate Services role to apply the changes.
After running it, re-scan with Locksmith to confirm these critical issues are remediated.
Script: Run as Administrator.
# --- Backup the CA Registry Key --- $CAName = "BNBC-CA" # Replace with your actual CA name $BackupPath = "C:\CA_Backup_$CAName.reg" Write-Host "Backing up CA registry key to $BackupPath..." reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName" $BackupPath /y # --- Disable SAN Injection (ESC6) --- # EditFlags → set to 0x10 (decimal 16) $PolicyPath = "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy" Write-Host "Setting EditFlags to 0x10 (disables SAN injection)..." Set-ItemProperty -Path $PolicyPath -Name EditFlags -Value 16 # --- Enforce Encrypted Requests (ESC11) --- $ValueName = "IF_ENFORCEENCRYPTICERTREQUEST" Write-Host "Enabling encrypted certificate requests ($ValueName = 1)..." New-ItemProperty -Path $PolicyPath -Name $ValueName -Value 1 -PropertyType DWord -Force # --- Enable NTDS CA Security Extension (ESC16) --- $CAConfigPath = "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName" $ExtName = "szOID_NTDS_CA_SECURITY_EXT" Write-Host "Ensuring $ExtName is enabled..." New-ItemProperty -Path $CAConfigPath -Name $ExtName -Value 1 -PropertyType DWord -Force # --- Restart CA Service --- Write-Host "Restarting Certificate Services..." Restart-Service certsvc Write-Host "CA hardening complete. Re-run Locksmith to verify."
✅ Removes ESC6, ESC11, ESC16 risks.
📝 Enabling Certification Authority Auditing
By default, an Enterprise CA does not log all of its critical events. Without auditing, attempts to abuse the CA may go unnoticed. Locksmith flags this as:
Technique : DETECT
Issue : Auditing is not fully enabled on SRV3.BugNBuyCo.local\BNBC-CA
Fix : certutil.exe -config ‘SRV3.BugNBuyCo.local\BNBC-CA’ -setreg CA\AuditFilter 127
✅ Steps to Enable Auditing
Log on to your CA server (SRV3).
Use an account with local administrator rights on the CA host.
Run the following command to enable full CA auditing:
certutil.exe -config "SRV3.BugNBuyCo.local\BNBC-CA" -setreg CA\AuditFilter 127
127 is a bitmask that enables all 7 CA audit categories:
Start and Stop of the CA service
- Pending Certificate Requests
- Issued Certificates
- Denied Certificates
- Revoked Certificates
- Changes to CA configuration
- Changes to CA security
Restart the Certificate Services role to apply the change:
Restart-Service certsvc -Force
Verify auditing is working:
- Open Event Viewer → Windows Logs → Security.
- Look for events such as 4886, 4887, 4888, 4890, 4891.
These indicate the CA is now auditing successfully.
🔎 Next Steps: Run Locksmith in Mode 1
Up to this point, we’ve:
- Removed default certificate templates.
- Cleaned dangerous ACLs on the CA host object.
- Hardened registry settings (ESC6, ESC11, ESC16).
- Enabled CA auditing (AuditFilter = 127).
Now it’s time to perform a deep validation scan with Locksmith.
✅ Run Locksmith in Mode 1
From an elevated PowerShell session:
Invoke-Locksmith -Mode 1
Output:
🔑 Summary: Clean Enterprise CA Deployment
We’ve now taken a default Enterprise CA installation (with insecure templates, broad ACLs, and weak registry settings) and hardened it step by step.
- Default templates removed → no more ESC1–ESC4 risks.
- Dangerous ACLs cleaned (Account Operators, orphaned SIDs) → no more ESC5 findings.
- Registry hardened (SAN injection disabled, encrypted requests enforced, NTDS extension enabled) → ESC6, ESC11, ESC16 resolved.
- Auditing enabled → full logging of CA activity.
- Locksmith Mode 1 scan → ✅ No ADCS issues were found.
🎯 What This Means
- Your BNBC-CA is now deployed in a clean, hardened state.
- Locksmith confirms that there are no known misconfigurations or exploitable defaults left.
- This server can now be treated as a Tier 0 asset and managed under strict controls.
🔄 Ongoing Practice
Each time you introduce a new certificate template (e.g., for LDAPS, Web Servers, or custom enrollment), re-run Locksmith:
Invoke-Locksmith -Mode 1
- This ensures you haven’t reintroduced a misconfiguration (like granting Authenticated Users enroll rights).
- Use Locksmith as your continuous validation tool for PKI changes.
✅ End Result: You now have a baseline-secure Enterprise CA and a repeatable process to verify new changes against best practices.