What is Lightweight Directory Access Protocol (LDAP)?

• IAM Glossary
• What is Lightweight Directory Access Protocol (LDAP)?

Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral protocol that applications use to access and maintain directory information over a network. A directory is a centralised store of data about an organisation’s users, groups and devices, and LDAP is most commonly used to authenticate users against that directory. LDAP works behind the scenes when users log in to a work email account, VPN or internal company application with a single username and password. Instead of each application maintaining its own list of users, LDAP allows multiple applications to verify credentials against a shared, centralised directory – making it a foundational technology for logging in to corporate systems.

LDAP was designed as a simpler, more efficient alternative to the Directory Access Protocol (DAP), an older, resource-heavy access protocol from the X.500 directory standard. LDAP retained the core idea of a structured directory while eliminating complex implementation and overhead, making it much easier to adopt.

LDAP vs Active Directory

While it’s often thought that LDAP and Active Directory are competing alternatives, they are two different things entirely. LDAP is a standard set of rules, or a shared language, for accessing and managing directory information. It does not store any data itself; instead, it is the protocol that applications use to talk to a directory.

Active Directory (AD) is Microsoft’s directory service product for storing and managing information about users, groups and devices on a network. LDAP is a protocol Active Directory uses to let applications read from and write to its directory. In simpler terms, LDAP is a language Active Directory can speak. Since LDAP is an open, vendor-neutral standard, it is supported by a variety of directory products and services, including OpenLDAP, JumpCloud and Oracle Internet Directory. Applications can rely on the same protocol regardless of which directory an organisation chooses to run; that flexibility is a large reason why LDAP is so widely adopted.

How does LDAP work?

LDAP follows a client-server model, where the client is the application that needs directory information (a login screen or an email program) and the server is the directory itself. A typical interaction with an LDAP directory involves the client sending a request, the LDAP server processing it against the directory and the server sending back a response. To understand how a directory is organised, it helps to understand what can be stored inside it:

• Entry: A single record in the directory. An entry usually represents one thing, such as a person, a group or a device.
• Attributes: The pieces of data attached to an entry, including a name, email address, phone number or department. Each attribute has a type and value.
• Distinguished Name (DN): The unique “address” that identifies an entry within the directory, meaning no two entries can share the same DN. It’s written as a path, built from the entry’s name plus the categories it lives under, telling the directory exactly where to find an entry.

Entries are organised into a hierarchy called the Directory Information Tree (DIT). Like a company org chart, the DIT branches from a broad root down into narrower groupings like departments and finally to individual entries, such as users. This tree structure makes a DN readable as a path, with each person’s DN tracing the route from the top of the tree down to their entry.

Common use cases for LDAP

Almost everything LDAP is used for traces back to one main idea: many applications can share a central source of truth about users and resources instead of each application maintaining its own. Below are the most common ways organisations use LDAP.

Authentication and authorisation

LDAP’s main use case covers both authentication and authorisation. Authentication involves verifying who a user is, which happens through the LDAP bind operation: An application submits a user identity and password, which the directory confirms or rejects. Authorisation involves deciding what an authenticated user is allowed to do. LDAP directories organise users into groups, and applications check group membership to grant or deny access. For example, only members of the “HR” group can edit within the payroll system.

Centralised user management

Traditionally, every application kept its own list of users and passwords. Onboarding a new employee used to mean creating accounts in many places one at a time, and offboarding meant tracking down and disabling each of those accounts, creating a real security risk if even one was missed. With LDAP, there’s one directory that every application authenticates against. The result is faster onboarding, smoother offboarding, consistent password policies and a central location to audit who has access to what.

Single Sign-On (SSO) foundations

Since every application can point to the same directory, LDAP provides the groundwork for Single Sign-On (SSO), where one set of credentials works across different systems. To clarify, LDAP is a foundation for SSO rather than being SSO itself. A full SSO experience, where a user logs in once and moves between apps without re-entering a password, typically incorporates additional protocols, but the shared identity source underneath is often an LDAP directory.

Contact lookups

Because the directory holds people along with their attributes, applications can query it as a shared, company-wide address book. For example, an email client may auto-complete a colleague’s address as someone starts typing their name, or a “staff directory” search inside an internal tool may return a colleague’s information. Here, LDAP works exactly as intended: Directories are read-optimised, built to handle a high volume of fast lookups, making them well-suited to this kind of querying.

Storing configuration information

Beyond people, a directory can store entries for machine resources, including network printers, servers and shared devices. This allows applications and users to discover and connect to those resources from one central place rather than manually configuring each one. A workstation may locate a nearby printer through the directory or a system may pull its device settings on startup. Although it’s a smaller use case, it shows the flexibility of LDAP.

LDAP ports and security

By default, LDAP communicates over port 389, which is the standard port for LDAP traffic. However, on its own, LDAP is unencrypted, so data travels in cleartext. Anyone able to intercept that traffic could read it, including sensitive information like usernames and passwords. That’s a major risk for a protocol so often used to handle logins, which is why encryption is strongly recommended. Here are two of the most common ways to secure LDAP:

• LDAPS uses port 636. Here the connection is encrypted as soon as it’s established, so traffic is protected for the entire session. The S stands for secure, like it does in HTTPS.
• StartTLS runs over the standard port 389. Instead of using a separate secure port, it starts as an ordinary LDAP connection and then upgrades it to an encrypted one using TLS. The end result is similar to LDAPS, but it’s negotiated on the same port instead of a dedicated one.

The main takeaway is that plain LDAP on port 389 offers no protection by itself. Encryption should be considered essential, whether through LDAPS on port 636 or StartTLS on port 389.

Pros and cons of LDAP

LDAP’s strengths explain why it’s been a longstanding pillar of enterprise identity, while its limitations point to situations where it needs supporting tools or isn’t the best fit.