In this post, we’re going to walk through setting up LDAPS the right way — not just enabling it, but doing so with a hardened certificate template that follows the principle of least privilege. By default, Domain Controllers will auto-enroll against the built-in Domain Controller template, but this template is too broad and grants enrollment rights to groups that don’t need them.
To fix this, we’ll create a custom DC-LDAPS template by duplicating the Kerberos Authentication template. Since duplicating and issuing new certificate templates requires Enterprise Admin rights, we’ll temporarily elevate our service account SRV3 into the Enterprise Admins group, perform the template creation and issuance, and then demote it back out of Enterprise Admins to maintain security hygiene.
Once the new template is published, Domain Controllers can auto-enroll for certificates that are purpose-built for LDAPS — restricted only to the accounts that truly need them.
Finally, we’ll validate the setup:
- confirm DCs received the new certificate,
- check that LSASS bound to the correct cert, and
- test secure LDAP connectivity on port 636 using Locksmith.
This approach gives us a hardened LDAPS deployment without leaving privileged accounts hanging around longer than necessary.
Creating the DC-LDAPS Template
Log onto the CA server using your temporary Enterprise Admin account — in my case, that’s the SRV3 server user where the CA role is installed.
Once signed in, open the Certification Authority console and navigate to Certificate Templates. If you’ve been following along with this series, this section should still be blank — because this will be the very first template we create.
See below for Previous Setups:
Secure Active Directory Enterprise CA Server Setup
Securing Active Directory CA: Baseline Checks and Template Cleanup
Right click the Certificate Templates folder and click “Manage“, this will bring up the templates menu.
Locate and right click on the “Kerberos Authentication” & select “Duplicate Template“.
Compatibility Tab
Since our Active Directory domain is running on Windows Server 2025, and all Domain Controllers are Server 2016 or newer, we can safely use modern template compatibility.
- Certification Authority = Windows Server 2016
- Certificate Recipient = Windows 10 / Windows Server 2016
This ensures the template is created as a Schema Version 4 template, which takes advantage of stronger cryptography and is fully supported by both our CA and all domain controllers in the environment.
General Tab
On the General tab give the template a meaningful name in this case I’m going to call it “DC-LDAPS” and select “Publish certificate in Active Directory“.
Extensions Tab
Click on “Application Polices” and click “Edit“.
🔒 Hardened EKU setup for DC-LDAPS
Keep:
- Server Authentication ✅ (required for LDAPS on 636)
Remove:
- Client Authentication ❌ not required, only widens cert use.
- KDC Authentication ❌ only used for Kerberos certs, not LDAPS.
- Smart Card Logon ❌ only for interactive logon with smart cards.
🔹 Why this is more secure
- A certificate with only Server Authentication can only be used by a Domain Controller to prove its identity as an LDAPS server.
- No chance it gets used for smart card logon, Kerberos PKINIT, or client-side mutual TLS.
- This limits the blast radius if the cert or private key were ever compromised.
✅ Recommendation for your DC-LDAPS template:
Server Authentication only → makes the certificate a single-purpose LDAPS cert, the most hardened option.
Subject Name Tab
Make sure the following are selected:
- Build from this Active Directory Information.
- DNS Name.
Security Tab – Users & Computers rights
Locking down the Security tab on a certificate template is critical because it defines who can request and auto-enroll certificates. By default, templates are often overly permissive (e.g., “Authenticated Users” can read/enroll), which increases the risk of unauthorized enrollment or abuse. If too many groups retain rights, a compromised account could obtain a powerful certificate that allows impersonation or secure service access. Restricting permissions to only the groups that truly need them — in this case, Domain Controllers for LDAPS and Enterprise Admins for management — enforces the principle of least privilege, reduces the attack surface, and ensures that sensitive certificates cannot be misissued or misused.
Authenticated Users
- ❌ Remove Everything
Reason: By default, “Authenticated Users” can read all templates, which is overly broad. Removing it reduces the risk of unintended enrollment visibility. Only specific groups (Domain Controllers, Enterprise Admins, etc.) should see/use this template
SRV3 User
- ❌ Remove Everything
Reason: The SRV3 account is only being temporarily elevated to Enterprise Admin for template creation. It should not retain long-term access to the template. Leaving these permissions in place increases the chance of accidental use or misconfiguration. Enterprise Admins already have full control.
Enterprise Read-only Domain Controllers
- ❌ Remove Everything
Reason: RODCs should not request or hold private keys used for LDAPS. Limiting them ensures only writable DCs can auto-enroll LDAPS certs.
Domain Admins
- ❌ Remove Everything
Reason: Domain Admins don’t need to enroll DC-LDAPS certificates. Their role is directory administration, not certificate management. Enforcing principle of least privilege avoids overexposure of high-privileged groups.
Domain Controllers
- ✅ Read
- ✅ Enroll
- ✅ Autoenroll
Reason: Domain Controllers are the intended recipients of this template. They must be able to auto-enroll LDAPS certificates for secure LDAP communication.
Enterprise Admins
✅ Full Control
✅ Read
✅ Write
✅ Enroll
✅ Autoenroll
Reason: Enterprise Admins own the CA hierarchy and certificate templates. They need full rights to manage, delegate, and troubleshoot certificate issuance.
Enterprise Domain Controllers
- ✅ Read
- ✅ Enroll
- ✅ Autoenroll
Reason: Enterprise Domain Controllers across the entire forest require LDAPS certificates for secure LDAP communications, just like local DCs. Granting Read + Enroll + Autoenroll ensures every DC in child domains can obtain and renew LDAPS certificates automatically, keeping authentication and directory lookups consistent across the forest.
SRV3$ (Computer Account of the CA Server in this case its SRV3$)
- ✅ Read
Reason: The CA server (SRV3$) must be able to read the template definition from Active Directory in order to process certificate requests. Without this, the CA cannot recognize or issue certificates based on the template.
Save the template by clicking “Apply” & “Ok” this will save the “DC-LDAPS” template.
Issue the Template & Create GPO
With the new DC-LDAPS template created, the next step is to issue (publish) it from the CA so that Domain Controllers can begin enrolling certificates based on it. Publishing makes the template available for use across the domain.
Once the template is issued, we’ll also configure a Group Policy Object (GPO) to instruct Domain Controllers to automatically enroll and renew their LDAPS certificates, ensuring the process is consistent and hands-off.
Issuing the new Template
In Certification Authority right click on “Certificate Templates” click “New -> Certificate Template to Issue“.
Select “DC-LDAPS” then “Ok“.
It will now appear under “Certificate Templates“.
Once you remove SRV3 from the Enterprise Admins group and log back in, you’ll notice a red cross next to the template. This simply indicates that the account no longer has sufficient rights to modify it. To make changes again, SRV3 would need to be re-added to Enterprise Admins. This restriction is by design — it helps secure the certificate template from unauthorized or accidental modification once it has been created and issued.
Creating the GPO
Since DC-LDAPS only applies to the Domain Controllers we will create this this GPO in the Domain Controllers OU.
Open Group Policy Management right click on the “Domain Controllers” OU and click “Create a GPO in this domain, and I Link it here”
Give your GPO a name in this case I’m calling it “BNBC GPO – LDAPS“.
Edit the GPO and got to the following setting “Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Auto-Enrollment”
✅ Configuration Model: Enabled
✅ Renew expired certs, update pending certs
✅ Update certificates that use certificate templates
Certificate Requests from Domain Controllers
Login to each domain controller and open elevated command prompt or PowerShell and run the following 3 commands
gpupdate /force certutil -pulse certutil -store my
Output:
We can see that the certificate has been issued and the Template is “DC-LADPS“.
Checking back on the CA Server we can also see that both DCs have now also got received the requested certs.
Testing LDAPS
From another domain joined computer run ldp.exe this will allow us to test the LDAPS connection. Click Connection then “Connect“.
Enter the following:
- Server: DC address
- Port: 636
- SSL: Enabled
If connected correctly then you should receive now issues.
Retest using Locksmith
As covered in the earlier post “Securing Active Directory CA: Baseline Checks and Template Cleanup”, we used the Locksmith tool to verify that our Certificate Authority had no outstanding vulnerabilities. Now that we’ve introduced a new certificate template, it’s important to re-run these checks to ensure we haven’t inadvertently reintroduced any weaknesses into the CA configuration.
To do this, open an elevated PowerShell session on the CA server and run the following command:
Invoke-Locksmith -Mode 1
Output:
The new LDAPS certificate template has been created successfully, and our checks confirm that no new security issues have been introduced.
🔑 Summary
In this walkthrough we created a hardened LDAPS certificate template to replace the overly permissive defaults. By duplicating the Kerberos Authentication template, stripping unnecessary EKUs, and tightening Security tab permissions, we ensured that only Domain Controllers can auto-enroll and use these certificates for secure LDAP communications.
Equally important is the follow-up: every time a new certificate template is introduced, we must verify that no new vulnerabilities have been reintroduced into the CA configuration. Tools like Locksmith help confirm that ownership, permissions, and policy settings remain aligned with least-privilege principles. This step protects against escalation paths (such as ESC1–ESC4) that attackers could abuse if a template is misconfigured.
By combining a secure LDAPS deployment with ongoing validation, we maintain both functionality (encrypted directory queries) and security (no hidden backdoors in the PKI infrastructure).