What is lightweight directory access protocol (LDAP) authentication?

Lightweight directory access protocol (LDAP) is a protocol that helps users find data about organizations, persons, and more. LDAP has two main goals: to store data in the LDAP directory and authenticate users to access the directory. It also provides the communication language that applications require to send and receive information from directory services. A directory service provides access to where information on organizations, individuals, and other data is located within a network.

The most common LDAP use case is providing a central location for accessing and managing directory services. LDAP enables organizations to store, manage, and secure information about the organization, its users, and assets–like usernames and passwords. This helps simplify storage access by providing a hierarchical structure of information, and it can be critical for corporations as they grow and acquire more user data and assets. 

LDAP also functions as an identity and access management (IAM) solution that targets user authentication, including support for Kerberos and single sign-on (SSO), Simple Authentication Security Layer (SASL), and Secure Sockets Layer (SSL).

LDAP is the core protocol used in–but not exclusive to–Microsoft’s Active Directory (AD) directory service, a large directory service database that contains information spanning every user account in a network. More specifically, LDAP is a lightweight version of Directory Access Protocol (DAP) and provides a central location for accessing and managing directory services running on the Transmission Control Protocol/Internet Protocol (TCP/IP). The most recent version is LDAPv3. 

AD provides the authentication and management of users and groups, and it is what ultimately authenticates a user or computer. The database contains a higher volume of attributes than what is pulled into LDAP. However, LDAP specializes in finding a directory object with little information, so it doesn’t need to extract all of its attributes from AD, or whichever directory service it is pulling from.

The main goal of LDAP is to communicate with, store, and extract objects (i.e. domains, users, groups, etc.) from AD into a usable format for its own directory, located on the LDAP server. 

Think of it this way: AD is the largest library in the world, and you’re looking for a book with a title that mentions zombies. In the world of LDAP, the details of whether or not the book was published in the U.S., contains over 1,000 pages, or is a how-to guide on surviving the zombie apocalypse don’t matter–although they do help narrow down the options available. LDAP is the experienced librarian who knows exactly where to find all of the options that satisfy your request and verify you’ve found what you’re looking for.

What prompts an LDAP search, and how does it work?

The LDAP authentication process is a client-server model of authentication, and it consists of these key players: 

• Directory System Agent (DSA): a server running the LDAP on its network
• Directory User Agent (DUA): accesses DSAs as a client (ex. a user’s PC)
• DN: the distinguished name, which contains a path through the directory information tree (DIT) for LDAP to navigate through (ex. cn=Susan, ou=users, o=Company)
• Relative Distinguished Name (RDN): each component in the path within the DN (ex. cn=Susan)
• Application Programming Interface (API): lets your product or service communicate with other products and services without having to know how they’re implemented

The process starts when a user tries to access an LDAP-enabled client program, like a business email application, on their PC. With LDAPv3, users will go through one of two possible user authentication methods: simple authentication, like SSO with login credentials, or SASL authentication, which binds the LDAP server to a program like Kerberos. The login attempt sends a request to authenticate the DN assigned to the user. The DN is sent through the client API or service that launches the DSA.

The client automatically binds to the DSA, and LDAP uses the DN to search for the matching object or set of objects against the records in the LDAP database. The RDNs in the DN are very important at this stage, as they provide each step in LDAP’s search through the DIT to find the individual. If the path is missing a connecting RDN on the backend, the result could turn up as invalid. In this case, the object LDAP is searching for is the individual user account (cn=Susan), and it can only validate the user if the account in the directory has the matching uid and userPassword. User groups are also identified as objects within the LDAP directory.

Once the user receives a response (valid or not valid), the client unbinds from the LDAP server. Authenticated users are then able to access the API and its services, including necessary files, user information, and other application data, based on the permissions granted by the system administrator. 

LDAP’s lightweight structure and use of a DIT make it possible to quickly run an LDAP search and successfully provide results. Understanding the DIT is vital to successfully navigating an LDAP server and understanding how the LDAP searches work.

The DIT makes it possible to quickly navigate through the different levels of the LDAP directory to narrow down search results and provide a response to a query. The DIT starts at the root directory, followed by countries, which then branches out to two subclasses: the Domain Component (dc) and Organization Name (o).

Domain Access Component  (dc)

The dc (i.e. dc=com, dc=example) uses domain name system (DNS) mapping to locate Internet domain names and translate them into IP addresses. 

Most users don’t know the domain name and/or IP address of the individual they’re searching for. In this case, LDAP uses the Distinguished Name (DN) assigned to the user as a path to quickly navigate through the DIT and find the search result. This is where the o subclass comes in. 

Organization Name (o)

The o subclass (ex. o-Company) is one of the most general subclasses listed in the DN, and it is usually where LDAP starts when it runs a search. For example, a simple path usually starts with the o subclass, branching off to the Organizational Unit (ou), followed by a user account or group. 

Organizational Unit (ou)

As previously mentioned, the ou is a subclass of o and is often seen as ou=users or ou=group, with each containing a list of user accounts or groups. Here’s how this might look in a directory:

• o-Company

  • ou=groups

    • cn=developers

  • ou=users

    • cn=Susan 

Common name (cn)

A common name, or cn, is used to identify the name of a group or individual user account (ex. cn=developers, cn=Susan). A user can belong to a group, so if Susan is a developer, they could also live under cn=developers. 

Attributes and values

Each subclass in the LDAP DIT (i.e. o, ou, cn) contains attributes and values, or schema that contains information on a LDAP directory’s structure that can help narrow down a search. Attributes are similar to what you would find in an address book entry, with labels like name, phone number, and address, and there are values assigned to each attribute. For example, Susan would be the value of the name attribute.

In the cn=Susan account, user id (uid) and userPassword are attributes and a user’s login credentials are the values. However, in a group like cn=developers, Susan would have the uniqueMember attribute (ex. uniqueMember=cn-Susan,ou-Users,o-Company). This maps a path to where Susan’s individual user account is located, along with the information LDAP is searching for. A user account is the end of the line in the DIT, and it is where LDAP ultimately extracts the results of the search. 

There are many other attribute types and syntaxes that can help narrow down a search, including ObjectClasses, like organizationalPerson (structural) or personal (structural). However, the number of attributes on LDAP is limited in order to keep it lightweight and easy to use.

Enterprise network admins are typically managing thousands of users at a time. This means they are responsible for assigning access controls and policies based on a user’s role and access to files for everyday tasks, like a company intranet.

LDAP simplifies the user management process, saves network admins valuable time, and centralizes the authentication process. Before integrating LDAP into your environment, it’s important to consider the following:

• Capacity: how much user management data do you need to store? Consider if products that implement LDAP solutions have the capacity to store and manage all the data you need.

• Search frequency: are there pieces of data that a user needs to access daily, like a company intranet, email application or service? If so, LDAP may be for you.

• Organization: will the simple DIT in LDAP provide enough organization for your data, or do you need a more detailed system?

While LDAP is commonly used in AD, it can also be used to authenticate users for other tools and client environments, including Red Hat Directory Servers on UNIX, and OpenLDAP, an open source application, on Windows. You can also take advantage of LDAP’s authentication and user management capabilities for API management, role-based access control (RBAC), or other applications and services like Docker and Kubernetes.

Red Hat® Enterprise Linux® includes centralized identity management capabilities that allow you to authenticate users and implement RBAC using a single, scalable interface that spans your entire datacenter.

Identity management with Red Hat Enterprise Linux includes a range of authentication and authorization capabilities, including: 

• Centralized identity management. Red Hat Enterprise Linux facilitates centralized identity management, allowing organizations to enforce security controls, meet compliance standards, and manage authentication policies from a single location—ensuring consistency across platforms, improving user experience, and reducing IT burden.
• Multi-factor authentication (MFA) and passwordless capabilities. Red Hat Enterprise Linux offers multi-factor authentication (MFA), offering a second layer of identity verification. Red Hat Enterprise Linux builds zero trust architecture (ZTA) maturity by supporting passwordless authentication, including FIDO2/WebAuthn and passkey-derived Kerberos tickets for SSH and GDM logins, moving security beyond simple MFA to a phishing-resistant and adaptive authentication state.
• External identity provider integration. Red Hat Enterprise Linux enables users to authenticate with clients using OAuth 2.0 and integrates with external identity providers such as Keycloak, Entra ID (Azure AD), and GitHub. This allows for the delegation of authentication and authorization processes to external entities, enhancing flexibility and interoperability within diverse IT environments.
• Comprehensive policy and certificate management. Red Hat Enterprise Linux offers tailored security policy management, including role-based access control for delegating identity management (IdM) server administration and custom sudo rules to limit privilege escalation. It also provides robust certificate management tooling that automates the entire certificate lifecycle—tracking expirations, ensuring timely renewals, and using public key infrastructure (PKI) authentication to verify trusted identities, a key component of ZTA.
• Automation and orchestration with system roles. Using Red Hat System Roles (powered by Ansible Automation Platform), Red Hat Enterprise Linux automates security configuration and management. This automation is vital for ensuring consistency and compliance at scale across all environments, from cloud to on-premise, reducing manual effort and potential misconfigurations. System roles are part of the automation and orchestration layer within the CISA ZTA framework.

Red Hat also offers Red Hat Directory Server as an add-on for those with more specialized needs.

Red Hat Directory Server is an LDAP-based directory that is scalable for large, diverse environments. Use near drop-in replacement for existing costly third-party LDAP solutions and manage distributed and complex directory topologies with a spectrum of replication options. This solution provides flexibility by providing customizable attributes and schema for your directory data.