Introduction:
One of the security settings that Microsoft recommend applying on domain controllers is to Require LDAP Signing. Requiring LDAP signing is one policy setting that can be applied on a few seconds using group policy, but what is the impact of applying this setting in your production environment? In most customer environments I visited, the Require LDAP signing is not enforced because customers are scared about what can happen. In this post I will explain the setting and set a clear action plan to safely apply the recommendation.
LAB Scenario:
domain name: lab.dz.
| Server Name | IP Address | Role |
| DC01 | 10.0.0.4 | Domain Controller |
| DC02 | 10.0.0.5 | Domain Controller |
| MEM01 | 10.0.0.10 | Member Server |
| MEM02 | 10.0.0.20 | Member Server |
Our mission is to enforce the setting Require LDAP Signing on the domain lab.dz. 😉
Understanding the policy setting.
Domain Controller: LDAP Server signing requirements.
To understand how this setting affect domain controllers we need to understand first LDAP Bind operations.
LDAP bind operations are used to authenticate clients to the directory server (clients could be users or application behind users). LDAP bind requests provide the ability to use either simple authentication or SASL authentication.
Simple Bind: Authentication happen using user name and password, password is transmitted in clear text.
SASL Bind: SASL Extensible Framework make possible to plug almost any kind of authentication to LDAP (Negotiate, Kerberos, NTLM and Digest). For more information about LDAP Bind operations please refer to this Link.
Let’s see the explanation on the policy setting.
The table below explain how the domain controller will act on different scenarios when enforcing Require LDAP Signing.
| Scenario | Action |
| Client Attempt Simple bind on clear text (non-SSL/TLS-encryption) | Domain controller reject the simple bind |
| Client Attempt Simple bind over SSL/TLS | Domain controller accept the simple bind |
| Client Attempt SASL bind and does not request signing | Domain controller reject SASL bind |
| Client Attempt SASL bind and request signing | Domain controller accept SASL bind |
Now as we understand the setting, the next step is how we should proceed to enforce require LDAP signing on production environment.
Confirming that our domain controllers are not configured to Require LDAP signing.
By looking for event 2886 on the Directory Service log we confirm that DC01 and DC02 are not configured to require LDAP signing. We found the event on both DCs.
Below the message on event 2886.
From Event 2886 we can get two important information.
- DCs are not configured with the Microsoft recommendation (Yellow paragraph).
- if unsigned SASL binds or simple bind occur on a DC, the DC will log an event every 24 hours, the event indicate how many such bind occurred. (Blue paragraph)
Actually the event is 2887, by checking on DC01 and DC02 we can see 2887 events on both DCs
As you can see on event 2887 from DC01, 10 simple binds performed without SSL/TLS.
At this moment we know that if we enforce Require LDAP Signing setting, we will break some applications ☹. Our next challenge is to find where these binds are coming from.
Finding Servers that are using insecure binds.
We need to increase LDAP Interface logging to be able to find from which servers these binds are coming. On both domain controllers we run the command below:
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics’ -Name “16 LDAP Interface Events” -Value 2 -PropertyType DWORD -Force
After increasing LDAP Interface logging, Domain controllers will log event 2889 every time a client perform SASL bind without requesting signing or simple bind on clear text.
As you can see on the screenshot above, this bind come from 10.0.0.10 which is MEM01. We need to observe events 2889 on both DCs to find servers hosting the applications that are performing insecure binds.
On your production, you may have more than 20 domain controllers, you need to look for the event 2889 on all the DCS, don’t panic you will not do that manually 😊.
On GitHub we can download a script that will do the nice job for us, it will query events 2889 from a specific DC and give us a nice CSV with the information we need. Download the script Query-InsecureLDAPBinds.ps1.
In my scenario I will run the script to find insecure binds on DC01 and DC02.
The two screenshots below show execution and output from DC01.
As you can see, we found insecure LDAP binds coming from 10.0.0.10 and 10.0.0.20 which are MEM01 and MEM02.
Ok so if I fix application settings on these servers than I can Enforce Require LDAP Signing on my DCs.
Fixing the LDAP Application on MEM01
By checking applications, we found an LDAP tool which is configured to use Simple Bind.
The LDAP tool offer SASL bind, I can fix this easily by changing the settings.
Sure, we need to check that the new settings are working just fine.
I checked again on both DCs for new events 2889 coming from MEM01 but I can’t find anymore, the SASL bind is signed.
Cool MEM01 is OK now, let’s see MEM02.
☹ Unfortunately, after checking on MEM02, we found an old LDAP tool that support only simple bind. (No SASL that request signature).
What’s the solution for MEM02? The answer is easy, simple bind over SS/TLS. part two of this post will show how to install a certificate on a domain controller to be able to configure Simple bind over SSL.
One thought on “Step by Step: Enforce Require LDAP Signing on domain controllers. Part 1”
You must log in to post a comment.