How LDAP Works: Bind, Search & Active Directory Security (Animated)

LDAP is how applications talk to a directory such as Microsoft Active Directory: “Is this password right?”, “Which groups is Priya in?”, “List all computers.” Almost every corporate login touches LDAP, so SOC teams watch it closely.

1. Bind: the app logs in to the directory

The intranet app first logs in (binds) to the domain controller with its own service account.

1. bindRequest (Intranet app → Domain controller): A simple bind on port 389 sends the account’s password unencrypted. Keep this in mind for the attack chapter.
2. bindResponse (Domain controller → Intranet app): The app is now logged in to the directory.

Wireshark filter:

ldap.protocolOp == 0

2. Search: find the user and their groups

When Priya logs in to the app, it searches the directory for her account, then tries her password with a second bind.

1. LOGIN (User PC → Intranet app): Priya types her domain password into the intranet app.
2. searchRequest (Intranet app → Domain controller): The app asks for Priya’s entry and her group memberships.
3. searchResEntry (Domain controller → Intranet app): The directory returns her entry. Group membership decides what she may see in the app.
4. bindRequest (Intranet app → Domain controller): To check the password, the app binds as Priya.
5. bindResponse (Domain controller → Intranet app): Correct password: Priya is in.

Wireshark filter:

ldap.protocolOp == 3

3. Exposed binds & mapping: attack: reading passwords and the whole directory

Two weaknesses. Clear-text binds on 389 expose every password to anyone who can capture the traffic. And by default any domain account can read most of the directory, so one stolen low-level login lets an attacker list every user, admin group and server.

1. CAPTURED (Intranet app → Attacker): Capturing the app’s traffic reveals the service account password in readable form.
2. searchRequest (Attacker → Domain controller): With any valid login, the attacker asks for everything.
3. searchResEntry (Domain controller → Attacker): The directory obliges. The attacker now knows exactly whose accounts are worth targeting.

Wireshark filter:

ldap.authentication.simple

4. Ldaps & signing: defence: encrypt, sign, watch

Require LDAP signing and channel binding, move apps to LDAPS (636), lock down what ordinary accounts can read, and alert on one account pulling thousands of directory objects.

1. bindRequest (Intranet app → Domain controller): Unsigned clear-text binds are now refused.
2. LDAPS (Intranet app → Domain controller): The app reconnects over LDAPS; a sniffer sees only encrypted bytes.

Group policy:

Domain controller: LDAP server signing requirements = Require signing
LDAP server channel binding token requirements = Always

FAQ