FFoundationalActive Directory
Directory Services and LDAP
Active Directory is a directory server, and LDAP is the protocol that lets clients and applications talk to it. This lesson covers what a directory server actually stores, how LDAP binds establish who is asking, and why the difference between simple and SASL binds matters for security.
This lesson builds on
Why it matters
Almost everything that happens in Active Directory happens over LDAP. When a user logs into a workstation, when an application checks group membership, when an enumeration tool pulls a list of accounts, it is issuing an LDAP query or an LDAP bind. If you cannot explain what a directory server is and how LDAP talks to it, you cannot explain how any of that traffic works, and you cannot reason clearly about why some of it is dangerous and some of it is completely normal. This lesson is the protocol-level foundation underneath enumeration, authentication, and most of the AD attacks that come later.
Key Concepts
- Directory server — a server that stores information about the objects in a network (users, computers, groups) and makes that information available to other systems; Active Directory is Microsoft's directory server implementation
- LDAP (Lightweight Directory Access Protocol) — the protocol clients and applications use to query and manage information held by a directory server; AD speaks LDAP the way a web server speaks HTTP
- Bind operation — the step that establishes the authentication state of an LDAP session; every LDAP session starts with a bind before any query is honored
- Simple bind — a bind that sends a username and password (or nothing, for an anonymous bind) directly to the LDAP server; sent in cleartext by default unless the connection is protected with TLS
- SASL bind — a bind that delegates authentication to another mechanism, most commonly Kerberos, so credentials are never sent to the LDAP server directly
Theory
Core idea
A directory server is a system built to store information about the objects in a network, users, computers, groups, and their attributes, and to make that information searchable by other systems. It is optimized for lookups: read far more often than it is written to, and organized in a hierarchical structure rather than as flat database tables. Active Directory is Microsoft's directory server implementation, but it is not the only one; OpenLDAP and other products play the same role. What makes something a directory server is the function it performs, not the vendor.
LDAP is the protocol that clients and applications use to talk to a directory server: to ask it questions and, with the right permissions, to change what it stores. The relationship is similar to a web server and HTTP. Apache is a web server that happens to speak HTTP; Active Directory is a directory server that happens to speak LDAP. A domain controller runs the AD database, and it listens for LDAP requests, most commonly on port 389 in cleartext and port 636 for LDAP over TLS (LDAPS). Any tool that wants to read from or authenticate against AD, from a login prompt to a third-party application doing single sign-on, is ultimately sending LDAP messages to a domain controller.
Mental model
Think of a domain controller as a reference desk at a large library, and LDAP as the standard request form you have to fill out before the librarian will help you. Before you can ask for anything, you have to identify yourself at the desk. That identification step is the bind: it does not tell the librarian what you want to look up, it just establishes who you are for the rest of the conversation.
There are two ways to identify yourself at this desk. A simple bind is like handing over a printed ID card with your name and a password written on it. It is straightforward, but if someone is standing close enough to read over your shoulder, they can copy what is on the card, because a simple bind sends the username and password in the clear unless the whole conversation is wrapped in TLS. A SASL bind works differently: instead of handing your own credentials to the librarian, you show up with a sealed letter of introduction from someone the librarian already trusts, most often Kerberos. The librarian never sees your password at all, only proof that a trusted party already vouched for you. Once you are bound, whichever way you did it, you can start submitting search requests, and the directory server decides what it is willing to hand back based on who you turned out to be.
Common misunderstandings
- Treating LDAP and Active Directory as the same thing. LDAP is a protocol; AD is one product that implements it. Confusing the two makes it hard to reason about environments running other directory servers, or about why AD's LDAP behavior can be reconfigured or hardened independently of the rest of the platform.
- Assuming LDAP traffic is encrypted by default. A plain LDAP bind on port 389 sends credentials in cleartext unless the connection is upgraded to LDAPS or protected with StartTLS. Anyone who assumes 'it's AD, so it must be secure' is skipping a real configuration decision that every environment has to make.
- Confusing binding with querying. The bind only establishes identity; it does not determine what data comes back. A successful bind, even an anonymous one, can be followed by a search that returns nothing, a little, or a lot, depending entirely on the permissions and query filters involved. Binding and querying are two separate steps with two separate security implications.
- Assuming a SASL bind is automatically secure. SASL is a framework, not a guarantee. Its security depends on the mechanism it delegates to. A SASL bind through Kerberos is strong because Kerberos never puts the password on the wire; a poorly configured SASL mechanism does not inherit that property automatically.
Real-world context
During an assessment, LDAP is usually the first protocol you interact with once you have any foothold, even a low-privileged domain account. Enumeration tools like BloodHound and PowerView are, underneath their tooling layer, issuing LDAP binds and LDAP search queries against a domain controller. The fact that any authenticated domain user can bind and query most of the directory by default is what makes basic AD enumeration possible without any exploit at all. Some environments still allow anonymous binds, which means an attacker does not even need valid credentials to pull useful directory information.
From a defensive standpoint, this is why LDAP signing and channel binding matter: they are controls that specifically target the weaknesses in a plain simple bind, preventing an attacker positioned on the network from relaying or tampering with LDAP authentication. Explaining a finding like "anonymous LDAP binds are enabled" to a stakeholder means being able to say, in plain terms, that this lets anyone on the network ask the directory questions without proving who they are first, and that the fix is a configuration change, not a rebuild. This lesson stops at bind mechanics and query basics; it does not cover manipulating LDAP query syntax to extract or alter data, which is a separate, more advanced topic.
Communication
Interview answer
A directory server stores information about the objects in a network, users, computers, groups, and makes that information queryable. Active Directory is Microsoft's directory server, and LDAP is the protocol clients and applications 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.
There are two bind types that matter. A simple bind sends a username and password directly to the server, in cleartext by default unless the connection is 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 that a plain simple bind leaves open.
Follow-up questions
- What is the difference between LDAP on port 389 and LDAPS on port 636, and why would a defender care which one is in use?
- What happens on a domain controller that still allows anonymous LDAP binds?
- Why does a SASL bind through Kerberos avoid sending the user's password to the LDAP server?
- If a tool like BloodHound can enumerate a domain with a low-privileged account, what does that tell you about default LDAP query permissions?
- How does the bind operation relate to the schema and objects a directory server stores?
