Directory Services and LDAP Brief
What It Is
A directory server stores information about the objects in a network, users, computers, groups, and their attributes, and makes that information searchable by other systems. It is optimized for lookups: read far more often than written to, and organized hierarchically. LDAP is the protocol clients and applications use to talk to a directory server. Active Directory is Microsoft's directory server, and it speaks LDAP the way a web server speaks HTTP; a domain controller listens for LDAP requests on port 389 (cleartext) and port 636 (LDAPS).
The Reference Desk
Think of a domain controller as a reference desk at a large library, and LDAP as the standard request form you fill out before the librarian helps you. Before you can ask for anything, you identify yourself: that is the bind. A simple bind is like handing over a printed ID card with your name and password on it, readable by anyone close enough to see it unless the whole conversation is wrapped in TLS. A SASL bind is showing up with a sealed letter of introduction from someone the librarian already trusts, most often Kerberos: the librarian never sees your password, only proof that a trusted party vouched for you.
Key Facts
- A bind establishes the authentication state of a session; it does not determine what data a search will return
- A simple bind sends a username and password (or nothing, for anonymous) in cleartext by default, unless the connection uses TLS or LDAPS
- A SASL bind delegates authentication to a mechanism like Kerberos, so the password never reaches the LDAP server directly
- SASL is a framework, not a guarantee; its security depends entirely on the mechanism it delegates to
- Any authenticated domain user can bind and query most of the directory by default, which is what makes basic AD enumeration possible without an exploit
- Some environments still allow anonymous binds, letting anyone on the network query the directory without valid credentials
Interview Phrasing
A directory server stores information about the objects in a network and makes it queryable. Active Directory is Microsoft's directory server, and LDAP is the protocol clients use to talk to it, the same way a web server speaks HTTP. Before any query happens, an LDAP session has to bind, which establishes the authentication state of that session. A simple bind sends a username and password directly to the server, in cleartext by default unless wrapped in TLS. A SASL bind delegates authentication to another mechanism, most often Kerberos, so the password never touches the LDAP server directly. That difference is the whole reason LDAP hardening controls like signing and channel binding exist: they close the gap a plain simple bind leaves open.
Common Pitfalls
- Treating LDAP and Active Directory as the same thing: LDAP is a protocol, AD is one product that implements it
- Assuming LDAP traffic is encrypted by default: a plain bind on port 389 sends credentials in cleartext unless upgraded to LDAPS or StartTLS
- Confusing binding with querying: binding establishes identity, and a separate search request determines what data comes back
- Assuming a SASL bind is automatically secure: its strength depends entirely on the underlying mechanism, such as Kerberos