LDAP Explained: The Protocol Almost Every Login Still Goes Through

The treeThe LDAP tree, and how names are built

LDAP directory data is a tree, and every entry in it has a name built from its position, which is the part that trips people up first.

An entry's distinguished name, its DN, is the full path from that entry up to the root of the directory, written from the specific to the general. It looks like this.

CN=Ana Novak,OU=Finance,OU=Staff,DC=company,DC=local

Read it right to left. DC=company,DC=local is the root of the LDAP tree, derived from the domain name company.local. OU=Staff and OU=Finance are organizational units, containers within it. CN=Ana Novak is the user entry itself.

Three parts of that are worth knowing.

The DN is a path, not an identifier. Move the user account to a different organizational unit and the DN changes. Any application storing a DN as a permanent reference breaks the day somebody reorganizes the directory, which is why it should store a stable attribute instead.

The relative distinguished name is the leftmost part alone, CN=Ana Novak, which has to be unique within its container in the directory and not anywhere else.

Common LDAP attributes are worth memorizing because every configuration screen uses them: CN is common name, OU is organizational unit, DC is domain component, UID is user id, SN is surname, O is organization.

The operationsBind and search, the two LDAP operations

Every LDAP session is a sequence of these two operations, and understanding them is understanding the protocol.

An LDAP bind authenticates a user. The client sends a DN and a password, and the directory server says yes or no. There are three kinds of bind and the difference matters for security.

An anonymous bind sends no credentials at all. Many directory servers allow it for reading public information and many others refuse it outright, which is a common cause of an integration that works in one environment and not another.

A simple bind sends the user DN and the password in the request. Over port 389 with no encryption, that password crosses the network in the clear. This is the single most important security fact on this page.

A SASL bind uses a real authentication mechanism, usually Kerberos in a Windows environment, and never sends the user password over the wire at all.

An LDAP search reads directory information. The request carries a base DN saying where in the tree to start, a scope saying how deep to go, and a filter saying what to match. The directory server returns the matching entries and the attributes requested.

That structure explains most integration failures. An LDAP search returning nothing usually has the wrong base, a scope of base where it needed subtree, or a filter testing the wrong attribute.

FiltersLDAP filters, which look worse than they are

LDAP search filters use prefix notation and parentheses, and they read strangely until the pattern clicks: the operator goes first, then its arguments.

(uid=anovak)                       one attribute equals a value
(objectClass=person)               every entry of a type
(&(objectClass=user)(mail=*))      AND: users that have an email address
(|(department=Sales)(department=Marketing))    OR: either department
(!(userAccountControl=514))        NOT: excludes disabled accounts in AD
(&(objectClass=user)(memberOf=CN=VPN Users,OU=Groups,DC=company,DC=local))

The last one is the filter most people actually need, and it is the one every VPN appliance and web application asks for: only users in a particular group may sign in. The group is named by its full DN, so moving it in the directory breaks the filter.

The attribute names, which is where a configuration copied between two directory products quietly stops working.

The last row is the one that catches people. Active Directory has no simple disabled attribute: the state lives in a bit field, which is why the filter for enabled accounts looks like an incantation rather than a comparison.

Two practical points. Filters are evaluated on the directory server, so a broad filter across a large directory is slow, and narrowing the base DN helps more than tightening the filter. And attribute names differ between directory services: Active Directory uses sAMAccountName where OpenLDAP on Linux uses uid, which is why a configuration copied between the two rarely works unchanged.

SecurityThe LDAP security problem, and how it was fixed

Plain LDAP on port 389 has no encryption. A simple bind over it puts a user name and a password on the wire in a form anyone on the path can read. That is not a subtle security weakness, and it is still how a surprising number of printers, scanners and older appliances access the directory.

Two LDAP mechanisms fix it, and they are often confused.

LDAPS, on port 636, wraps the whole LDAP session in TLS from the first byte, the same way HTTPS does. It is straightforward, it is what most appliances support, and it needs a certificate the client trusts.

StartTLS, on port 389, opens a plain LDAP connection and upgrades it to TLS before any credentials are sent. It is the modern preference in the standards and it has one weakness: a client that fails to request the upgrade, or fails to check that it succeeded, carries on sending data in plaintext with no error.

Microsoft has been pushing this for years, and current Active Directory servers increasingly require signing and channel binding, which means a plain simple bind on 389 is rejected outright. That change breaks exactly the old devices described above, and finding them before it lands is the work.

The practical instruction: use 636 or StartTLS everywhere, and audit for anything still binding in plaintext. Directory servers log the source of unsigned binds, and that log is the list of devices to fix.

Against ADLDAP and Active Directory

LDAP and Active Directory get used interchangeably and they are not the same kind of thing.

LDAP is a protocol. A specification for accessing a directory, defined by the IETF and implemented by many directory services.

Active Directory is a directory service that speaks LDAP among several other protocols. It also uses Kerberos for authentication, DNS for locating services, and Group Policy for configuration management, none of which is LDAP.

So an application configured to authenticate users against Active Directory over LDAP is using one protocol out of the several the directory offers, and usually the least preferred one. Where the application supports Kerberos or a modern federation protocol instead, that is nearly always the better choice: no user password crosses the wire, and single sign on works.

The other common comparison is with SAML and OIDC. Those are web federation protocols based on redirecting a browser to an identity provider, and they are what a modern web application should use for authentication. LDAP is for applications and appliances that predate them or run outside a browser, and there are a great many of those.

The cloudWhat happens when the directory moves to the cloud

This is the question that arrives in every modernization project, and the answer surprises people: cloud directory services generally do not speak LDAP at all.

Microsoft Entra ID, formerly Azure AD, is an identity and access management service rather than an LDAP directory server. It handles authentication over OAuth, OIDC and SAML, which are the right protocols for web applications and useless to a printer. There is no LDAP endpoint to point a scanner at, and no port 389 anywhere.

Three paths exist, and choosing between them is the actual decision.

Keep a domain controller. The simplest answer for a building full of appliances. Cloud authentication for the web applications, on premises Active Directory for everything that only speaks LDAP, with the two synchronized. Most organizations are here and will be for years.

Run a managed directory service in the cloud. Entra Domain Services provides an LDAP and Kerberos endpoint backed by the cloud directory, so appliances have a server to bind to without one to patch. It costs real money per month and it is the answer when the only reason a domain controller still exists is LDAP access.

Replace the appliances. Slower, more expensive, and the only path that actually removes the dependency. Worth doing at the natural refresh point rather than as a project of its own.

The trap to avoid is discovering the dependency late. Before any plan to retire the last domain controller, search the server logs for every device still binding over LDAP. The list is always longer than the inventory, and it always contains at least one thing nobody remembers putting on the network.

PitfallsWhere people go wrong

Binding as a domain administrator. An application only needs read access to the directory information, and it is frequently given an account that could rewrite all of it. That password sits in the application configuration file, often in plaintext. Create a dedicated read only service account with no privileges beyond the LDAP search it performs.

Using port 389 with a simple bind. The user password is readable by anyone on the path. This is the security finding that appears in every audit, usually on a multifunction printer.

Storing a DN as a stable reference. It changes when the object moves in the directory. Store the objectGUID attribute in Active Directory, or entryUUID in OpenLDAP on Linux, both of which are permanent.

Setting the LDAP search base too high. Basing a search at the root of a large directory and relying on the filter makes every query expensive for the server. Base it on the organizational unit that actually contains the user accounts.

Copying a configuration between directory services. The attribute names differ. sAMAccountName, uid and userPrincipalName are three different things, and a configuration that assumes the wrong one returns no information and no useful error.

Pointing at one directory server by name. It reboots on patch night and the integration fails. Point at the domain name so the client can use any server, or configure two.

Forgetting the paged results limit. Active Directory returns 1,000 entries by default, and a client that does not implement paging silently receives truncated information. Every subtle "some users cannot log in" problem in a large directory is worth checking against this.

ComparisonLDAP, Kerberos and web federation, on what each one is actually for

The first row is the security argument. LDAP survives because the bottom row is true and because appliances support no other authentication, not because it is the better protocol.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Identity and access What Is MFA? A bind checks one password. Everything that makes that password sufficient sits above it. Open this next16 min

• Directory and identity · 15 min Active Directory Explained The directory service most people are actually talking to when they configure LDAP.
• Ports · 12 min What Is a Port Number? Ports 389 and 636 are the whole of the LDAP security decision, and the difference is TLS.
• Ports · 10 min Port 88, and Why a Domain Stops Working Without It Kerberos on port 88, where five minutes of clock difference stops every login on the domain.
• Ports · 11 min The LDAP Ports, and Which One Your Application Should Use What LDAP is, before the port question.