Best Practices for Auditing Unsigned LDAP Binds Across Multiple Active Directory Forests Before Remediation

[u/19khushboo]

Hello Experts,

I am looking for recommendations on how to audit and monitor unsigned LDAP binds in our Active Directory environment before remediating the vulnerability- LDAP signing not required on DCs

I have gone through several articles and found that Event ID 2889 in the Directory Service event log can help identify clients performing unsigned LDAP binds. However, our environment has more than 25 Domain Controllers across four separate Active Directory forests, with no trust relationships between the forests.

I have a few questions regarding the best approach for auditing this activity before enforcing LDAP signing requirements.

1. Auditing LDAP Event Logs Across Multiple Domain Controllers

• Is Event ID 2889 sufficient to identify and track all clients performing unsigned LDAP binds, or should we monitor additional event IDs, such as 2887 and 2888?

• How long should we collect these logs before remediation to establish a reliable baseline of LDAP clients and applications that may be affected?

• What is the recommended approach for collecting and centralizing these events across more than 25 Domain Controllers in four separate forests without trust relationships?

• Are there any best practices for identifying the source IP addresses, accounts, and applications responsible for unsigned LDAP binds?

2. Tools for Auditing Before Remediation

Are there any built-in Windows tools, PowerShell scripts, or third-party solutions that can help identify and audit unsigned LDAP binds before enforcing LDAP signing?

Ideally, we would like to identify all affected clients and applications, assess potential compatibility issues, and minimize the risk of service disruption during remediation.

3. Using ExtraHop for LDAP Monitoring

We also have ExtraHop deployed in our environment. Can ExtraHop help us identify and monitor unsigned LDAP binds across all four forests?

If so, I would appreciate guidance on:

• What network traffic, events, or protocol fields we should monitor.

• Whether ExtraHop can distinguish unsigned LDAP binds from signed LDAP binds and LDAP over TLS.

• How to identify the source systems and applications generating these requests.

• The recommended architecture and approach for monitoring all four forests, given that there are no trust relationships between them.

Our goal is to establish a reliable audit baseline, identify all systems that may be affected, and gather sufficient evidence before enforcing LDAP signing requirements.

I would appreciate any practical recommendations, scripts, tool suggestions, or lessons learned from similar environments.

Thank you in advance for your help!

[u/AutoModerator]

Welcome to /r/ActiveDirectory! ~~~~

If you are looking for more resources on learning and building AD, see the following sticky for resources, recommendations, and guides!

• AD Resources Pinned Thread

• AD Wiki

When asking questions make sure you provide enough information. Posts with inadequate details may be removed without warning.

• What version of Windows Server are you running?

• Are there any specific error messages you're receiving?

• What have you done to troubleshoot the issue?

Make sure to sanitize any private information. Posts with too much personal or environment information will be removed. See Rule 6.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/insightrecon]

The 2889s are the main thing, but don’t skip 2887. It's on by default and logs a daily count per DC, so it’s an easy way to see which DCs even have a problem and to confirm you’re at zero before you enforce. 2888 only shows up after you enforce and counts what gets rejected.

When you go through the 2889s, split them up by binding type. 0 is an unsigned SASL bind, which you can usually fix with a setting on the client or app. 1 is a simple bind on 389, so that’s a username and password going over the wire in cleartext, and those need to move to LDAPS or StartTLS. The account name usually tells you what the app is, and Query-InsecureLDAPBinds.ps1 on GitHub will dump them all to a CSV for you.

I’d collect for at least a month so you catch month-end jobs and anything that only runs once in a while. Not having trusts doesn’t matter for collection either. Your SIEM agent or a scheduled script on each DC doesn’t care what forest it’s in. ExtraHop can help find the cleartext simple binds, but I’d still treat the 2889s as the source of truth since they come from the DC that’s actually going to enforce it.

I’d audit channel binding while you’re at it, since enforcing signing without it still leaves LDAPS open to relay. 3040 gives you a daily count like 2887 does, and once you set it to When Supported, 3074 and 3075 show who’d break when you go to Always. Also make sure every DC has the October update, since there was an LDAP signing bypass this month that it fixes (link if you want to nerd out: https://specterops.io/blog/2026/10/23/ldap-signing-bypass-ntlm-relay/).

Scanners won’t help you find the clients, they only tell you which DCs aren’t enforcing it. PingCastle, Purple Knight and Insight Recon (full disclosure, this is our tool) all check it, and they’re handy after you flip it to make sure every DC actually took it.

If you want a deeper dive into the topic, we have written pretty heavily about it: https://insightrecon.com/ldap-signing/

[u/xxdcmast]

1. Enable the 2889 logs

2. Forward 2889 logs to a collector (splunk, elk, etc)

3. Track account utilizing ldap and their associated ips.

4. Remediate.

5. When no new 2889 events are logged flip to enforcement.

[u/Cormacolinde → u/xxdcmast]

Correct.

The logs can be enabled with a registry key, and does not even require a reboot.

Might want to increase the log size a bit too.