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. To ensure security, it’s crucial to enable LDAP logging on domain controllers.
In the second half of 2020, Microsoft changed 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.
🎬 Watch This Week in IT.
The current default settings don’t enforce 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.
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 on Domain Controllers
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 HKLMSYSTEMCurrentControlSetServicesNTDSDiagnostics 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:SYSTEMCurrentControlSetServicesNTDSDiagnostics' -Name "16 LDAP Interface Events" -Value 2 -PropertyType DWORD -Force
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 supports it. Signed SASL binds are easier to set up and maintain because they don’t require maintenance of a certificate. Ensure you enable LDAP logging on domain controllers to monitor these changes effectively. And of course LDAP signing aren’t the only events you should monitor, there are other events to audit in Active Directory.
FAQs
What are the performance implications when you enable LDAP logging on domain controllers?
When you enable LDAP logging on a domain controller, there can be a 2-5% performance impact on CPU usage and disk I/O, depending on the volume of LDAP traffic. It’s recommended to enable LDAP logging on domain controllers during off-peak hours for initial testing.
Can I automatically enable LDAP logging on domain controllers using Group Policy?
Yes, you can create a Group Policy to enable LDAP logging on domain controllers by configuring a registry policy that sets the “16 LDAP Interface Events” value. This allows for centralized management across multiple domain controllers.
How long should I keep LDAP logging enabled on domain controllers for proper analysis?
When you enable LDAP logging on domain controllers, maintain the logging for at least one week to capture all application patterns, including weekly scheduled tasks and periodic authentication attempts.
What happens if I enable LDAP logging on a domain controller without sufficient disk space?
If you enable LDAP logging on a domain controller without adequate storage, it can fill up the system drive and cause performance issues. Ensure at least 10GB of free space before enabling detailed LDAP logging.
Can I remotely enable LDAP logging on domain controllers using PowerShell?
Yes, you can enable LDAP logging on domain controllers remotely using PowerShell’s Invoke-Command cmdlet combined with the New-ItemProperty command, but you need appropriate administrative privileges and WinRM enabled on the target servers.
Related Article:
Russell Smith, the Editorial Director at Petri IT Knowledgebase, has over two decades of hands-on experience in IT, in both small business settings and government IT infrastructure projects. Russell started writing for Windows IT Pro Magazine in t...
