How to Audit LDAP Signing in an Active Directory Domain

Windows Server Active Directory (AD) uses the Lightweight Directory Access Protocol (LDAP) to communicate between the directory service, clients, and applications. LDAP is an open, industry-standard protocol for accessing directory services on Internet Protocol (IP) networks.

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.

For more information on LDAP, and the changes that Microsoft is planning to make, see Microsoft Delays LDAP Signing and Channel Binding Changes in Active Directory on Petri.

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).

For more information on the Group Policy settings used to configure LDAP, see Microsoft Delays LDAP Signing and Channel Binding Changes in Active Directory on Petri.

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.

How to Audit LDAP Signing in an Active Directory Domain (Image Credit: Russell Smith)

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.

The easiest way to add the key is to use PowerShell as shown below:

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name "16 LDAP Interface Events" -Value 2 -PropertyType DWORD -Force

How to Audit LDAP Signing in an Active Directory Domain (Image Credit: Russell Smith)

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.

How to Audit LDAP Signing in an Active Directory Domain (Image Credit: Russell Smith)

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.