E-LDA
ldapsearch
Standard OpenLDAP command-line client for querying and enumerating LDAP directories, including Active Directory.
OVERVIEW
ldapsearch is the reference command-line client shipped with OpenLDAP (openldap.org): it opens a connection to any LDAP-speaking directory — including a Windows Active Directory domain controller, which speaks LDAP on top of its AD-specific schema — and runs an arbitrary search filter and base DN, returning matching entries and attributes as plain text.
Because it is a thin, scriptable wrapper around the LDAP protocol itself, it is often used to sanity-check exactly what a directory exposes to an anonymous or low-privilege bind before pointing a heavier AD-enumeration tool (like BloodHound's collector or crackmapexec's LDAP module) at the same service.
USE CASES
Practical use cases
- 01
Testing whether an anonymous LDAP bind against a domain controller returns any directory data.
- 02
Pulling the base DN, naming contexts, and schema details of an unfamiliar LDAP directory.
- 03
Enumerating specific users, groups, or computer objects with a targeted search filter.
- 04
Scripting a bulk export of directory attributes for offline analysis or feeding into another tool.
QUICK START
When a domain controller or LDAP service is reachable, to enumerate directory objects directly with a raw query before reaching for a heavier AD tool.
- Confirm LDAP (TCP 389/636) enumeration against this domain controller is in scope.
- Try an anonymous bind first to see the base DN and any exposed naming contexts.
- If anonymous bind is refused and credentials are in scope, retry with a low-privilege account.
- Run a targeted search filter (e.g. for user objects) against the confirmed base DN.
- Save the output for cross-referencing with other AD enumeration tools.
ldapsearch -x -H ldap://10.10.10.10 -b "dc=target,dc=local" "(objectClass=user)"BEFORE YOU RUN IT
What to check before running it
Anonymous LDAP binds are disabled by default on modern Active Directory and many hardened OpenLDAP deployments, so a bind refusal is a common, expected outcome, not a tool failure.
LDAP queries against a domain controller are logged and can be correlated with other reconnaissance activity by a monitored SOC.
Unencrypted LDAP (port 389, no STARTTLS) sends any bind credentials in the clear on the wire — prefer LDAPS/StartTLS whenever authenticating with real credentials.