How to Configure LDAPS (LDAP over SSL) in Active Directory
Learn how to configure LDAPS (LDAP over SSL) in Active Directory Domain Services. Covers certificate requirements, the NTDS Personal store, firewall rules for port 636, and verifying the connection with ldp.exe.
- Difficulty
- Advanced
- Time required
- 20 minutes
- Steps
- 5
- Platform
- Active Directory Domain Services
- Last tested
- July 19, 2026
.webp)
Table of contents
Quick Answer
Go to the stepsObtain a certificate with the Server Authentication EKU, the DC's FQDN, and a trusted CA chain. Import it into the NTDS Service Personal store. AD DS automatically enables LDAPS with no restart. Open firewall port 636, then verify the connection with ldp.exe using SSL.
- Obtain a certificate meeting LDAPS requirements (Server Auth EKU, DC FQDN, private key).
- Import it into the NTDS Service Personal certificate store.
- AD DS auto-detects the certificate and enables LDAPS (no restart).
- Open firewall TCP port 636 (and 3269 for global catalog).
- Verify with ldp.exe: connect to DC on port 636 with SSL checked.
Certificates snap-in > NTDS Service Personal store > Import certificateExpected result: LDAPS accepts encrypted connections on port 636. ldp.exe connects successfully with SSL.
Key takeaways
- You'll learn how to enable LDAPS in Active Directory by installing a qualifying certificate on the domain controller and verifying the encrypted connection.
- LDAP over port 389 sends credentials in cleartext. Per Microsoft Learn, LDAPS encrypts this traffic over port 636. Many applications require LDAPS, and Microsoft's LDAP hardening makes encrypted connections increasingly mandatory.
- Install a certificate meeting the LDAPS requirements (Server Authentication EKU, DC FQDN, trusted CA, private key) into the NTDS Personal store. AD DS enables LDAPS automatically.
Introduction
By default, LDAP traffic transmits unencrypted over port 389, exposing authentication credentials and directory queries to interception. Per Microsoft Learn, LDAPS establishes an encrypted SSL/TLS tunnel over port 636, protecting this traffic.
Enabling LDAPS is straightforward: install a properly formatted certificate on the domain controller, and AD DS automatically accepts SSL connections. The certificate must meet specific requirements, including the Server Authentication EKU and the DC's FQDN in the Subject or SAN.
This tutorial covers the certificate requirements, requesting or importing the certificate, placing it in the NTDS Personal store, opening the firewall, and verifying LDAPS with ldp.exe. Many applications now require LDAPS, and Microsoft has been hardening LDAP channel binding and signing, making LDAPS increasingly necessary.
Who this is for: Active Directory administrators securing LDAP traffic for applications that require encrypted directory connections.
Before you start
- Access
- Administrative access to the domain controller. A CA (internal AD CS or trusted third-party) to issue the certificate.
- Required roles
- Domain Administrator
- Environment
- Active Directory Domain Services. A certificate meeting LDAPS requirements.
- Vendor
- Microsoft
- Last tested
- Administrator permissions required
20 minutes
Warning: Do not install a CA on the domain controller
Per Microsoft Learn, installing an Enterprise Root CA directly on a domain controller auto-enables LDAPS but is NOT a recommended practice. Use a separate CA server and import the certificate instead.
Note: Open firewall port 636
Per Microsoft Learn, firewall rules must allow inbound TCP port 636 for LDAPS (and TCP 3269 for global catalog LDAPS). Verify these before testing.
1Verify Certificate Requirements
Ensure your certificate meets the LDAPS requirements.
Per Microsoft Learn, the LDAPS certificate must meet these requirements:
- Enhanced Key Usage: includes Server Authentication (1.3.6.1.5.5.7.3.1).
- Subject: the DC's FQDN (e.g., dc01.contoso.com) in the Common Name (CN) or as a DNS entry in the Subject Alternative Name (SAN).
- Trusted CA: issued by a CA that both the DC and LDAPS clients trust.
- Private key: present and generated with the Schannel CSP.
Obtain this from your internal AD CS enterprise CA (via auto-enrollment or manual request) or a trusted third-party CA.
Expected result: You have a certificate that meets all LDAPS requirements.
Note
Do not install a CA directly on the domain controller. Use a separate CA server and import the certificate.
2Request the Certificate
Request a qualifying certificate for the domain controller.
AD CS Certificate Templates or certreq.exeIf using an enterprise CA, domain controllers may auto-enroll for a Kerberos/DC certificate that already qualifies. Otherwise, request one manually.
For a manual request, create a request .inf file specifying the DC FQDN and Server Authentication EKU, then run:
certreq -new request.inf request.req
certreq -submit request.req cert.cerSubmit the request to your CA and retrieve the issued certificate.
certreq -new request.inf request.reqExpected result: A certificate request is generated and submitted to the CA.
Note
Enterprise CA auto-enrollment is the simplest path. The default Domain Controller and Kerberos Authentication templates typically qualify for LDAPS.
3Install the Certificate in the NTDS Store
Install the certificate into the correct store to enable LDAPS.
certlm.msc or Certificates - Service (Active Directory Domain Services) > NTDS\PersonalImport the certificate into the NTDS Service Personal store (preferred over Local Machine).
Open an MMC, add the Certificates snap-in, and select Service account > Active Directory Domain Services. Expand NTDS\Personal. Right-click, select All Tasks > Import, and import your certificate.
Per Microsoft Learn, AD DS detects the new certificate and enables LDAPS automatically, without a restart.
Expected result: The certificate appears in the NTDS Service Personal store. LDAPS is enabled.
Note
AD DS prefers the NTDS store over the Local Machine store. This avoids ambiguity when multiple certificates exist in the Local Machine Personal store.
4Open the Firewall for Port 636
Allow LDAPS traffic through the firewall.
Windows Defender Firewall with Advanced Security > Inbound RulesPer Microsoft Learn, ensure firewall rules allow inbound connections on:
- TCP port 636 for LDAPS.
- TCP port 3269 for global catalog LDAPS (if this DC is a global catalog).
Check Windows Defender Firewall and any network firewalls between clients and the DC. The built-in AD DS firewall rules usually cover these, but verify they're enabled.
Expected result: Inbound connections on TCP port 636 (and 3269 for GC) are allowed.
Note
If clients connect from other subnets, network firewalls must also allow port 636.
5Verify with ldp.exe
Confirm LDAPS is functioning.
On the domain controller or a domain-joined client, open an elevated command prompt and run ldp.exe. In LDP:
- Select Connection > Connect.
- Server: enter the DC's FQDN.
- Port: 636.
- Check the SSL checkbox.
- Click OK.
Per Microsoft Learn, when the connection succeeds, RootDSE information appears in the right pane, confirming LDAPS works.
ldp.exeExpected result: ldp.exe connects on port 636 with SSL and displays RootDSE information.
Note
If the connection fails, verify the certificate properties and firewall. For Local Machine store installs, confirm the DC was restarted.
Verify LDAPS with ldp.exe
Verify installation
After installing the certificate, verify LDAPS is working. Per Microsoft Learn, open ldp.exe on the domain controller or a domain-joined client. Select Connection > Connect, enter the DC's FQDN, set Port to 636, and check the SSL box.
When the connection succeeds, RootDSE information appears in the right pane, confirming LDAPS is functioning. If the connection fails, verify the certificate properties match the requirements (Server Auth EKU, FQDN, trusted chain, private key) and check that the firewall allows port 636.
For Local Machine store installations, confirm the domain controller was restarted. For NTDS store installations, AD DS enables LDAPS automatically without a restart.
Normal result: ldp.exe connects on port 636 with SSL and displays RootDSE information.
Abnormal result: ldp.exe fails to connect on port 636. The certificate doesn't meet requirements or the firewall blocks port 636.
Successful LDAPS connection
ldp.exe port 636 SSL shows RootDSE
LDAPS is working. RootDSE appears in ldp.exe.
Connection failed
ldp.exe cannot connect on port 636
Certificate or firewall issue.
Troubleshooting
ldp.exe won't connect on port 636
Warning
Cause: The certificate is missing the Server Authentication EKU, the DC FQDN, or a private key.
Verify the certificate has the Server Authentication EKU (1.3.6.1.5.5.7.3.1), the DC's FQDN in the Subject or SAN, and an accessible private key. Reissue the certificate if any requirement is missing.
LDAPS not enabled after installing certificate
Note
Cause: The certificate was placed in the Local Machine store and the DC wasn't restarted.
Move the certificate to the NTDS Service Personal store, where AD DS enables LDAPS automatically without a restart. Or restart the DC if using the Local Machine store.
Clients can't establish LDAPS connections
Warning
Cause: Clients don't trust the CA that issued the DC certificate.
Distribute the issuing CA's root certificate to all LDAPS clients (via Group Policy for domain members). The client must trust the full certificate chain.
Frequently asked questions
What is the difference between LDAP and LDAPS?
LDAP transmits unencrypted over port 389. LDAPS establishes an encrypted SSL/TLS tunnel over port 636 (or 3269 for global catalog), protecting credentials and directory queries from interception.
What are the LDAPS certificate requirements?
Per Microsoft Learn, the certificate needs the Server Authentication EKU (1.3.6.1.5.5.7.3.1), the DC's FQDN in the Subject CN or SAN, a trusted CA chain, and an accessible private key generated with the Schannel CSP.
Do I need to restart the domain controller?
Per Microsoft Learn, no. AD DS detects a new certificate dropped into the NTDS Service Personal store and triggers an SSL certificate update without restarting. Only the Local Machine store method may need a restart.
Which certificate store should I use?
Per Microsoft Learn, the NTDS Service Personal store is preferred. AD DS looks there first, making it easier to control which certificate is used when multiple certificates exist in the Local Machine store.
How do I verify LDAPS is working?
Use ldp.exe: Connection > Connect, enter the DC FQDN, port 636, and select the SSL checkbox. If RootDSE information appears, LDAPS is working.
Conclusion
LDAPS encrypts LDAP traffic over port 636 using SSL/TLS. Per Microsoft Learn, installing a properly formatted certificate on the domain controller automatically enables LDAPS with no extra configuration.
The certificate must have the Server Authentication EKU, the DC's FQDN in the Subject or SAN, a trusted CA chain, and a private key. Import it into the NTDS Service Personal store (preferred over Local Machine). AD DS detects the new certificate and enables LDAPS without a restart. Verify with ldp.exe on port 636 with SSL enabled.
Install a certificate meeting the LDAPS requirements (Server Authentication EKU, DC FQDN, trusted CA, private key) into the NTDS Personal store. AD DS enables LDAPS automatically.
certlm.msc / NTDS Personal store, then verify with ldp.exe port 636 SSLSources2
