Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral protocol for reading and updating information in a directory service, the database that holds an organization’s users, groups, computers and other records. Applications, network devices and servers use LDAP to look up a user’s details or group memberships and, commonly, to check a username and password. LDAP is defined by IETF standards, with LDAPv3 the current version, and it is supported by most enterprise directories, including Microsoft Active Directory and OpenLDAP.
At a glance
- A protocol for querying and modifying directory services; not a directory product itself.
- Organizes entries in a tree, each identified by a distinguished name and holding attributes.
- Often used by applications, VPNs, Wi-Fi and network devices to authenticate users against the directory.
- Plain LDAP traffic is unencrypted by default; LDAPS or StartTLS add encryption.
- Still widespread on-premises, while web and SaaS sign-in has largely moved to SAML and OpenID Connect.
What problem it solves
Without a shared directory, each application and device keeps its own user list, so accounts multiply and removing a leaver means visiting every system. LDAP gives these systems a common way to ask one central directory “does this user exist, which groups are they in, and is this password correct?”. That lets organizations manage accounts and group memberships in one place and have applications follow along.
For buyers today, LDAP matters mostly because of what still depends on it. Many on-premises applications, printers, VPN gateways, network devices and older tools authenticate only through LDAP, and those dependencies shape how quickly an organization can move to cloud identity and access management (IAM).
How it works
Directory structure. Entries are arranged in a hierarchy, for example organization, then departments or organizational units, then users. Each entry has a unique distinguished name and attributes such as name, email, phone or group membership, following a schema.
Connection and bind. A client, such as an application server, connects to the directory server and binds, meaning it authenticates. It might bind as a service account to search, or bind as the user to check their password.
Search. The client searches part of the tree with a filter, for example “find the user with this email” or “list members of this group”, and reads the attributes returned.
Authentication pattern. A common application flow is: bind as a service account, search for the user’s entry, then attempt to bind as that user with the password they entered. A successful bind means the password is correct.
Modify. Authorized clients can add, change or delete entries, which is how some provisioning tools manage directory accounts.
Encryption. Because plain LDAP traffic is unencrypted, deployments use LDAPS (LDAP over Transport Layer Security (TLS)) or StartTLS to upgrade the connection, plus signing where the directory supports it.
When it matters for buyers
- When planning a move to cloud identity. Inventory which systems use LDAP before retiring or changing on-premises directories; these are often the long tail of a migration.
- After a security assessment. Unencrypted LDAP, anonymous binds and over-privileged LDAP service accounts are common findings. Service accounts with broad directory rights are often brought under privileged access management (PAM).
- When adding MFA. Password checks over LDAP don’t support modern multi-factor authentication (MFA) on their own; options include moving the app to SAML or OIDC, or putting an MFA-capable proxy or gateway in front of it.
- When buying applications or network gear. Prefer SAML or OpenID Connect support for user sign-in, and treat LDAP-only authentication as a legacy constraint.
Our privileged access management overview covers controlling the service and admin accounts that directory integrations rely on.
Questions to ask vendors
- Does your product authenticate users through LDAP, SAML, OpenID Connect or several of these?
- Do you support LDAPS or StartTLS, and certificate validation?
- What permissions does your LDAP service account need, and can it be read-only?
- Can you support MFA for users who sign in through LDAP?
- If we move to a cloud directory, do you offer an LDAP interface, and what are its limits?
- How do you handle directory failover and timeouts?
How it differs from SAML and identity providers
LDAP is a directory protocol: an application talks directly to the directory, usually passing the user’s password to be checked. Security Assertion Markup Language (SAML) and OpenID Connect are federation protocols: the application typically doesn’t handle the password, because the user signs in at an identity provider (IdP), which sends the app a signed statement of who they are. That design is what makes web single sign-on (SSO) and central MFA practical. Identity providers often still read users and groups from an LDAP directory behind the scenes, so the two commonly coexist.