Detecting Insecure LDAP Binds Across All Domain Controllers Using PowerShell
A PowerShell-based audit workflow for identifying insecure LDAP bind activity across Domain Controllers, helping administrators find legacy clients, misconfigured applications, and non-secure directory integrations before enforcing LDAP signing.
Captures clients using insecure LDAP bind methods against Domain Controllers.
Queries all discovered Domain Controllers instead of checking each server manually.
Exports normalized client, user, bind type, and DNS details for analysis.
Overview
In a modern Active Directory environment, identifying insecure LDAP authentication is critical for maintaining directory security.
This script performs a centralized audit of insecure LDAP bind events across all Domain Controllers in the forest. It validates network connectivity, queries the Directory Service event log remotely using WMI, extracts relevant client and authentication data, and exports the results into a consolidated CSV report.
The script is designed for environments where WinRM may be restricted, using RPC and WMI-based access instead of depending entirely on PowerShell remoting.
Why Monitor Insecure LDAP Binds?
Event ID 2889 is logged when a client performs an LDAP bind without signing or performs a simple bind over a clear-text, non-SSL/TLS LDAP connection.
These insecure bind patterns are commonly seen with legacy applications, misconfigured appliances, hardcoded LDAP integrations, and service accounts still using older authentication methods.
Common Sources
Insecure LDAP binds are often caused by systems that were configured years ago and never updated. The most common sources include older applications, network appliances, monitoring tools, printers, scanners, middleware, and service accounts embedded inside application configuration files.
Common sources of insecure LDAP binds:
- Legacy applications
- Misconfigured network appliances
- Hardcoded LDAP integrations
- Non-secure service accounts
- Old middleware or identity connectors
- Printers, scanners, or monitoring tools using simple LDAP bind
Script Architecture
The script follows a structured workflow so that checks are repeatable across multiple Domain Controllers.
1. Accept a configurable time window
2. Discover all Domain Controllers dynamically
3. Validate ICMP and RPC connectivity
4. Query the Directory Service event log
5. Filter for Event ID 2889
6. Parse and normalize event data
7. Attempt reverse DNS lookup for client IPs
8. Export a consolidated CSV report
Event Data Parsing and Normalization
Event ID 2889 contains useful details inside the event data. The script extracts and normalizes those values so that the report is easier to review.
Extracts the client IP address, source port, and reverse DNS name when available.
Captures the username or account identity used during the LDAP bind attempt.
Converts numeric bind values into readable labels such as unsigned or simple bind.
Reverse DNS Resolution
If a client IP address is available, the script attempts a reverse DNS lookup to identify the hostname.
This is useful when investigating insecure applications or legacy systems, because an IP address alone may not tell the full story. DNS failures are handled gracefully and do not interrupt the script.
Practical Use Cases
This script is useful during pre-hardening assessments before enforcing LDAP signing, security compliance audits, domain modernization projects, and incident response involving credential exposure concerns.
It is especially useful in hybrid or legacy-heavy environments where older systems may still be binding to Active Directory using insecure LDAP methods.
Important Notes Before Running
Event ID 2889 requires LDAP Interface Events diagnostic logging to be enabled on Domain Controllers. Without that logging level, the detailed client information may not be available.
Also remember that this report identifies observed insecure LDAP bind activity during the configured time window. If a legacy application did not authenticate during that period, it may not appear in the report.
PowerShell Script
The full PowerShell script is maintained on GitHub so it can be updated, versioned, and downloaded directly.
# Quick usage
# 1. Download the script from GitHub.
# 2. If the downloaded file ends with .txt, rename it to:
Get-InsecureLDAPBinds.ps1
# 3. Review the script configuration:
# - Lookback window
# - Output path
# - Domain Controller discovery scope
# - CSV report location
# 4. Run from a secured admin host with rights to query DC event logs.
# 5. Recommended execution:
powershell.exe -ExecutionPolicy Bypass -File .\Get-InsecureLDAPBinds.ps1
How to Read the Report
Start with the client IP and resolved hostname. That usually points to the system or application responsible for the insecure bind.
Then review the username used for the bind. If the same service account appears repeatedly from the same host, that system is likely using a legacy LDAP configuration that needs to be updated to use signed LDAP or LDAPS.
Limitations
This script reports what Domain Controllers have logged. If diagnostic logging is not enabled, if the event log rolled over, or if the client did not authenticate during the selected time window, it may not appear.
Reverse DNS is also best-effort. A missing hostname does not mean the IP is invalid. It only means the lookup could not be resolved at the time of reporting.
Final Thoughts
Insecure LDAP binds are often hidden inside older applications and infrastructure components. They usually become visible only when administrators prepare to enforce stronger LDAP security.
By collecting Event ID 2889 across Domain Controllers, this script gives teams a practical way to identify problem clients before policy enforcement causes outages.
Next, we can cover how to enable LDAP signing safely, test application compatibility, and move from audit mode to enforcement without breaking legacy integrations.