Overview
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 towhere 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 anidentity 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 v.s. Active Directory
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 exactlywhere to find all of the options that satisfy your request and verify you’ve found what you’re looking for.
Optimize Linux security with Red Hat
LDAP authentication process
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.
Understanding LDAP components
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.
Why LDAP?
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 forAPI management,role-based access control(RBAC), or other applications and services likeDockerandKubernetes.
LDAP authentication with Red Hat Enterprise Linux
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 forLinux: 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.
The official Red Hat blog
Get the latest information about our ecosystem of customers, partners, and communities.
All Red Hat product trials
Keep reading
What is SOAR?
What's an insider threat?
What is post-quantum cryptography?
Security resources
Related content
Related articles
- What is AI security?
- What is an image builder?
- What's an insider threat?
- What is SOAR?
- Why choose Red Hat for Linux?
- Why run Microsoft SQL Server on Linux?
- How to move to Red Hat Enterprise Linux from other Linux distros
- Linux for cloud computing
- What is post-quantum cryptography?
- What is Linux?
- What is the SAP HANA migration?
- What is software supply chain security?
- What is secrets management?
- What is confidential computing?
- What are SPIFFE and SPIRE?
- Red Hat Enterprise Linux security
- What is zero trust?
- Why run Linux on AWS?
- What is high availability?
- What is ERP?
- What is SAP HANA (and why does it run on Linux)?
- Functional safety and continuous certification on Linux
- Why run Linux on IBM Cloud
- What is CentOS Stream?
- What is access control?
- Why choose Red Hat Enterprise Linux on Azure?
- Why choose Red Hat Enterprise Linux on AWS?
- What is a CVE?
- Linux on Azure
- Red Hat Enterprise Linux migration process
- What to know for Red Hat Enterprise Linux 7 End of Maintenance
- What is CentOS?
- What to know about CentOS Linux EOL
- Why run Linux on Google Cloud?
- Red Hat Satellite on Red Hat Enterprise Linux
- What is role-based access control (RBAC)?
- What is kubernetes security?
- Shift left vs. shift right
- Why choose Red Hat Enterprise Linux on Google Cloud?
- Red Hat Lightspeed data and application security
- What is Linux kernel live patching?
- What is CI/CD security?
- What is an intrusion detection and prevention system (IDPS)?
- What is security information and event management (SIEM)?
- The increasing importance of cybersecurity in banking
- Gain security with Red Hat Ansible Automation Platform
- What is edge security?
- What is the importance of operational resilience?
- What is vulnerability management?
- What is backup and recovery?
- What is container security?
- What is DevSecOps?
- What is compliance management?
- Why choose Red Hat for DevSecOps
- What is security automation?
- What is cloud governance?
- What's the best Linux distro for you?
- What's the difference between Fedora and Red Hat Enterprise Linux
- What is a Linux server?
- What is a configuration file?
- What is high performance computing (HPC)?
- Security in the software development lifecycle
- What is a golden image?
- What is an ARM processor?
- ARM vs x86: What's the difference?
- Kubernetes security best practices
- Security for IoT devices
- What is MPLS?
- What is identity and access management (IAM)?
- Advantages of Kubernetes-native security
- Container and Kubernetes compliance considerations
- Intro to Kubernetes security
- What is a Linux certification?
- What was CoreOS and CoreOS container Linux
- What is risk management?
- What is SELinux?
- What is the Linux kernel?
- Hybrid cloud security
- What is financial services security (and compliance)?
- What is API security?
- What is malware?
- What is cloud security