LDAP explained: what it is, how it works, and its security risks

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is an open, vendor-neutral protocol for reading from and writing to a directory service. A directory is a specialised database optimised for fast, high-volume reads of relatively stable data — the kind of information you look up far more often than you change, such as people, groups, roles, computers, printers and services. LDAP defines how a client connects to a directory server and the operations it can perform: bind (authenticate), search, compare, add, modify and delete. It is standardised by the IETF; the version in common use today is LDAP v3.

Because so many systems can speak it, LDAP is the common denominator for centralising identity: rather than every application keeping its own list of usernames and passwords, applications query one directory as a single source of truth. That central role is exactly why its security matters — a weakness in the directory, or in how an application talks to it, affects everything that trusts it.

The directory model: DN, entries and attributes

An LDAP directory is organised as a tree — the Directory Information Tree. Each node in the tree is an entry, and every entry is identified by a unique Distinguished Name (DN) that spells out its full path from the entry up to the root of the tree.

• Entry — a single object in the directory, such as one user or one group.
• Attributes — the name/value pairs on an entry (for a person, attributes such as cn for common name, mail, uid and memberOf). An entry's objectClass attributes decide which attributes it may hold.
• Distinguished Name (DN) — the unique, fully-qualified name of an entry, read left to right from most specific to least, e.g. cn=Jane Doe,ou=People,dc=example,dc=com.
• Base DN — the top of the subtree you search under, often mirroring a domain (dc=example,dc=com) with organisational units (ou=) beneath it.

A search combines a base DN, a scope (how deep to look) and a filter such as (uid=jdoe) or (&(objectClass=person)(mail=jane@example.com)). That filter syntax is central to the LDAP injection discussion below, because an application that builds a filter out of raw user input can have its query logic altered.

How LDAP authentication (bind) works

Authentication in LDAP is the bind operation. The client sends a DN and a credential (usually a password) and the server confirms whether they match the entry. A simple bind sends the DN and password directly; SASL binds support stronger mechanisms. Applications typically authenticate a user in two steps:

1. 1Bind as a service account and search. The app binds with a dedicated, low-privilege service account and searches for the user's entry by a known attribute (for example their uid or email) to retrieve their full DN.
2. 2Re-bind as the user. The app then attempts a second bind using that DN and the password the person entered. If the bind succeeds, the password is correct; if it fails, authentication is rejected.

The password the user supplies crosses the wire during that bind, so the connection must be encrypted (see LDAPS and StartTLS below). Authorisation — what the authenticated user may then do — is a separate concern, usually driven by group membership (memberOf) or roles the application maps onto its own permissions.

LDAP vs Active Directory

This comparison trips people up because it compares two different kinds of thing. LDAP is a protocol; Active Directory is a product — Microsoft's directory service. Active Directory speaks LDAP, so applications can query and authenticate against it over LDAP, but AD is much more than the protocol: it also provides Kerberos and NTLM authentication, Group Policy, DNS integration, a multi-master replication model, and domain, tree and forest structures. LDAP is just one of the ways you talk to it.

Active Directory is not the only directory that speaks LDAP. Open-source and cross-platform directories such as OpenLDAP and 389 Directory Server, along with many cloud and appliance directories, implement LDAP too. So the practical read of "LDAP vs Active Directory" is: use LDAP when you want an open, portable way to reach a directory; expect Active Directory when you are in a Microsoft-centric environment, and talk to it over LDAP (or LDAPS) when you integrate an application with it.

LDAP vs LDAPS vs StartTLS

Plain LDAP has no transport encryption by default. On an open or untrusted network that means credentials and directory data can be read in transit, so a production bind should never run unprotected. There are two standard ways to encrypt the connection:

• LDAPS — LDAP wrapped in TLS on a dedicated port (historically 636). The TLS tunnel is established first, then LDAP runs inside it.
• StartTLS — an extended operation that upgrades an ordinary LDAP connection (port 389) to TLS. The connection begins in the clear and is then promoted to an encrypted channel.

Both protect confidentiality and integrity when they are configured with valid certificates and certificate validation enabled on the client. Turning off certificate verification to "make it work" quietly removes the protection against an attacker impersonating the directory server, so treat it as a misconfiguration, not a workaround.

LDAP security issues (and how to defend against them)

Because the directory is a central source of identity, the following issues deserve attention in any LDAP integration. Each is described with the defence, not an exploit.

LDAP injection

LDAP injection happens when an application builds an LDAP search filter or a DN by concatenating untrusted user input without neutralising characters that are meaningful to LDAP — parentheses, the asterisk, the backslash and the null byte, among others. As with SQL injection, the danger is that user-controlled text changes the structure of the query rather than being treated as a plain value, which can widen a lookup or alter its logic. Defend against it:

• Escape all input with the library's LDAP escaping functions — RFC 4515 filter escaping for search filters and RFC 4514 escaping for DN components — rather than building filters by string concatenation.
• Validate and constrain input to what the field legitimately allows (for example, an allow-list of characters for a username) before it ever reaches a filter.
• Use a least-privilege bind account so that even a crafted query cannot read or modify more of the directory than the application's purpose requires.

Anonymous bind

Many directories allow an anonymous bind — a connection with no credentials — and may expose a surprising amount of directory structure and attributes to it. Disable anonymous bind where you do not need it, or tightly restrict what an anonymous connection can read through access controls, so the directory is not an unauthenticated information source.

Cleartext bind over a non-TLS connection

A simple bind sends the password to the server, so performing it over plain LDAP exposes credentials in transit. Require LDAPS or StartTLS for every bind, and configure the server to reject simple binds that arrive over an unencrypted connection so a misconfigured client cannot silently fall back to cleartext.

Over-broad service accounts

The service account an application binds with is a standing credential, and if it has broad read or write rights across the directory it becomes a high-value target. Scope each service account to the least privilege it needs — read access to only the subtree and attributes it uses — rotate its credentials, and store them in a secret manager rather than in application config or source control.