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: 

• Domain controller for Linux: Centrally manage identities, access, and policies for all users, services, and hosts within this trusted and centralized identity store. This helps reduce administrative overhead and simplifies domain registration to create a trusted security boundary. Users get a streamlined user authentication experience.

• AD integration: Bridge the user identity gap between Linux and Windows with the native Red Hat Enterprise Linux integration with Active Directory. Use Active Directory as a single source of truth for user identities and apply tailored access control policies directly to the Linux domain to improve administrative efficiency and centralize where policies are created.

• Kerberos SSO: Simplify the user authentication process using Kerberos, the core of identity management authentication, to support SSO for infrastructure. Extend to services so they can authenticate without passwords and support web authentication using SSO (based on Keycloak).

• System roles: Save time and resources by making use of consistent and repeatable configuration workflows. Automation will significantly reduce the technical burden and manual tasks associated with deployment and identity administration over time.

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.