How To Fix Insecure LDAP Binds To Prevent Exposed Windows Admin Credentials

First the good news: Microsoft planned to release a patch in January to disable insecure LDAP channel binding and LDAP signing to more secure configurations. As a result of businesses asking for more time due to the holiday season, Microsoft has pushed this off to March 2020. Now the bad news: You may be already passing the credentials for the domain admin account in cleartext in your network as noted in a 2016 blog post.

How do you know? Start by looking for event ID 2886 and 2887 in your directory service log. If event ID 2886 is present, it indicates that LDAP signing is not being enforced by your domain controller. What’s so bad about this? Plenty. It means that it’s possible to perform a cleartext LDAP bind over a non-encrypted connection.

If you see event 2886, you need to take immediate action to remedy the situation. Review your Group Policy or registry settings on your domain controllers. If you’ve never configured the option “Domain controller: LDAP server signing requirements” and still have them set as none, chances are this LDAP configuration is opening you up to risky configurations.

Review your group policy setting located at GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

Especially if you are running a domain based on older servers and participating in the extended support patch process and will obtain Server 2008 R2 patches, review this Group Policy setting and change it to “Require signing.”

Check for unsigned, cleartext binds

Obviously before you do so, determine the impact on your network. As noted in the blog post, look for event ID 2887. It normally occurs every 24 hours and reports how many unsigned and cleartext binds have occurred to the domain controller in question.

If you have a single unsigned and cleartext bind occurring, you need to take action. You can increase the logging of these events to review if you are impacted. Keep in mind that more logging will turn on a great number of events and may also enable errors in the log file that might seem alarming. Don’t worry; these events are normal. It’s recommended to enable additional logging only for a few minutes and then disable the logging afterwards. Here are the changes to the registry keys you need to make to increase logging:

# Enable Simple LDAP Bind Logging

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2

# Disable Simple LDAP Bind Logging.

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 0

Note: You may need replace the double quotes after copy and paste.

You are looking for 2889 events. You can also download from GitHub a filtered view. To use the .xml file, open “Event viewer”, right-click on “Custom views” and then select “Import Custom View”. Browse to the location of the .xml file. If you are doing this on a management workstation or server and not the domain controller, you will get an error message until you bind it to your domain controller.

You can also download a PowerShell script from GitHub that will extract the data from event 2889 on your domain controller into a .csv file. It will only query for events in the last 24 hours.

You can also follow the advice in two blog posts. The first goes through the process of setting up additional logging to you can review if you have insecure LDAP bindings occurring.

Wait 24 hours and look for event 2889 every time a client performs Simple Authentication and Security Layer (SASL) bind without requesting signing or simple bind on cleartext. This will identify what applications or platforms you need to upgrade or fix to support insecure bindings.

Once you determine that you have insecure bindings, fix this issue by reviewing if you can enable secure connections or secure bind on a checkbox inside the applications config. You can also go back to the vendor that you purchased the LDAP-reliant application from to see if they can provide a more secure way to access LDAP queries.

If you need to enable secure binding, you can do so with internal SSL certificates as noted in this blog. As you go through your end-of-year inventory, review if you have insecure setups in your active directory infrastructure. Don’t be leaking credentials in your network.