In the second half of 2020, Microsoft is changing the default LDAP signing and channel binding settings on Windows Server Active Directory domain controllers (DC). The new settings will enforce LDAP signing and channel binding.

The current default settings don’t enforce enforcing LDAP channel binding and signing. This could expose AD to an elevation of privilege vulnerabilities. Microsoft will make preparatory changes in a cumulative update due in March. But the new LDAP settings will only be enforced in a second cumulative update later in the year.

Audit LDAP signing

LDAP signing is configured using Group Policy. The Default Domain Policy Group Policy Object (GPO) can be used to configure the setting on domain-joined devices. And the Default Domain Controllers Policy GPO to configure the setting on domain controllers (DC).

While you can check the LDAP GPO settings configured in your domain, you should look in the Windows Event Log on each DC to make sure that clients and applications are not making insecure binds to AD.

Directory Service event IDs 2886 and 2887

Event ID 2886 in the Directory Service log indicates that LDAP signing is not enabled in your domain. And this is the current default configuration. The event provides further information, including that clients might be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection.

If either of the two insecure bind types are being made in your environment, an event (ID 2887) will be generated in the Directory Service log every 24 hours detailing the number of insecure binds performed. If event ID 2887 is generated, enforcing LDAP signing could break the clients or applications connecting to your domain controller.

Enable LDAP logging

LDAP logging can be set on domain controllers to help you identify where insecure LDAP bind attempts are coming from. To enable more detailed LDAP logging, add a new key (16 LDAP Interface Events) with a value of ‘2’ to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics in the registry. The key needs to be added on each DC that you want to audit.

Once the new registry key is in place, event ID 2889 will be generated in the Directory Service log whenever an insecure bind is made to the DC. The event logs the client IP address so you can identify which device is making the bind.

You need to audit all DCs in your domain for event ID 2889. If you have a lot of DCs, you can use Query-InsecureLDAPBinds.ps1 to automate the process. The script is available for free on GitHub here. Make sure you review and understand the code before running the script in a production environment.

Modify clients and apps to support secure LDAP binds

Once you have identified the clients or apps that are using insecure binds to communicate with AD, you need to modify them to ensure that either simple LDAP binds are sent over a secure SSL/TLS channel or enable signed SASL binds if the client or app support it. Signed SASL binds are easier to set up and maintain because they don’t require maintenance of a certificate.

Subscribe to Petri NewslettersOffice 365 Insider

Our Petri Office 365 Insider is dedicated to sharing detailed knowledge from top Office 365 experts. Delivered once a month to your inbox.

Petri.com may use your contact information to provide updates, offers and resources that may be of interest to you. You can unsubscribe at any time. To learn more about how we manage your data, you can read our Privacy Policy and Terms of Service.

Subscribe to Petri NewslettersOffice 365 Insider

Petri.com may use your contact information to provide updates, offers and resources that may be of interest to you. You can unsubscribe at any time. To learn more about how we manage your data, you can read our Privacy Policy and Terms of Service.