Introduction
On Part 2 of this post, I will show how to request a certificate for a domain controller to use LDAPS, we will see also why we should never use simple bind on clear text.
This post is intended to give you an action plan on how you can Enforce Require LDAP Signing on your production, please start by reading Part 1. https://azurecloudai.blog/2019/08/03/step-by-step-enforce-require-ldap-signing-on-domain-controllers-part-1/
Simple LDAP Bind in action
Before configuring LDAPS on DCs, let’s see why simple bind should always pass over SSL/TLS.
On MEM02 LDAP Admin tool is configured to use simple bind on clear text, using network monitor we will inspect traffic between MEM02 and DC01 when the connection happen.
As you can see on the screenshot below, simple bind using clear text is configured on LDAP Admin tool. I’m using the user Eric 😉.

Let’s see the traffic on Network Monitor.

As you can see on the screenshot, by sniffing the network traffic I can see the username and password in clear text.
Never use Simple bind on clear text.
Configuring LDAPS.
To configure LDAPS on the domain lab.dz, we need to install a certificate on domain controllers. Below an easy example on how to request and install the certificate on DC01.
Create an inf file on DC01 with the content below
; —————– DC01Request.inf —————–
[Version]
Signature=”$Windows NT$
[NewRequest]
Subject = “CN=dc01.lab.dz” ; replace with the FQDN of your DC
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
[RequestAttributes]
CertificateTemplate = KerberosAuthentication
SAN=”dns=dc01.lab.dz”
;———————————————–
Create a certificate request.
certreq –new DC01Request.inf DC01Request.req

DC01Request.req is generated.
Submit your request to your enterprise CA or third-party CA.
in my scenario I’m using Active Directory Certificate Services CA installed on MEM01.
Certreq -submit -config “mem01.lab.dz\lab-mem01-ca” DC01Request.reg DC01Request.cer

Install the certificate.
Certreq -accept DC01Request.cer

Certificate is deployed and LDAPS is available.
Let’s try a simple bind over SSL.

Connection Successful

After fixing the applications on MEM01 and MEM02 we can safely enforce Require LDAP Signing on domain controllers 😊.
Enforce Require LDAP Signing
Right click on default domain controller policy and configure the setting. Domain Controller: LDAP server signing requirements.

After enforcing the setting, LDAP Admin tool is unable to access the directory server using insecure LDAP Bind.
The screenshot below shows the error message when I try a Simple Bind on clear text.

Conclusion:
Enforcing Require LDAP signing will protect your password from transiting in clear text.
You have to start with an audit to detect all applications that are performing insecure binds before enforcing Require LDAP Signing. After finding the applications you have to configure the applications with one of the following.
- SASL bind that request signing.
- Simple bind over SSL/TLS.
You are ready to go 😉
Thanks for reading and Good Luck.
Interesting !
Great set of articles, well written!
Just have a question – if we need to go down the certificate path to secure the connections, and the local domain name ends in .local, is it possible to secure these DCs using a third party certificate but using a upn suffix that is supported externally via third party CAs? The idea to deploy an internal CA for many managed services customers to secure LDAP binding is bit of an overkill. Some people out there have said that upn suffix should work, but I’ve seen nothing authoritative on the matter from MS.