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.
Before you start
What you will learn
- 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.
Requirements
- Administrative access to the domain controller. A CA (internal AD CS or trusted third-party) to issue the certificate.
- Active Directory Domain Services. A certificate meeting LDAPS requirements.
- Domain Administrator
Good to know
- 20 minutes
Quick answer
Obtain 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.
Certificates snap-in > NTDS Service Personal store > Import certificateStep-by-step tutorial
5 stepsVerify 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.
Do not install a CA directly on the domain controller. Use a separate CA server and import the certificate.
Request 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.reqEnterprise CA auto-enrollment is the simplest path. The default Domain Controller and Kerberos Authentication templates typically qualify for LDAPS.
Install 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.
AD DS prefers the NTDS store over the Local Machine store. This avoids ambiguity when multiple certificates exist in the Local Machine Personal store.
Open 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.
If clients connect from other subnets, network firewalls must also allow port 636.
Verify 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.exeIf the connection fails, verify the certificate properties and firewall. For Local Machine store installs, confirm the DC was restarted.
Verify LDAPS with ldp.exe
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.
- ldp.exe connects on port 636 with SSL and displays RootDSE information.
- ldp.exe fails to connect on port 636. The certificate doesn't meet requirements or the firewall blocks port 636.
- LDAPS is working. RootDSE appears in ldp.exe.
- Certificate or firewall issue.
Troubleshooting
ldp.exe won't connect on port 636
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
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
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.
