For nearly 3 decades, organizations have been using the LDAP (Lightweight Directory Access Protocol) for user management, attributes, and authentication. In that time, the protocol has expanded and evolved to meet changing IT environments and business needs.
This post covers everything you need to know about LDAP, from its origins to its place in the contemporary cloud-driven world. We’ll also take a dive into explaining how it works, how it’s used, how to get started, and which LDAP server solutions might be right for your needs.
What Is The LDAP Protocol?
To understand what LDAP is, it’s best to understand what it was used for in the first place: directory services.
Directory services securely manage users and their access rights to IT resources within an organization using certain protocols.
LDAP is one of the core protocols used for these services. Although directory services may use additional protocols like Kerberos, SAML, RADIUS, SMB, Oauth et.c., most still use LDAP today.
In a nutshell, LDAP enables the secure management of users and IT resources in a directory, making it possible to control access to different parts of a computer network.
History of LDAP
by Tim Howes and his colleagues at the University of Michigan. It was created to be a lightweight, low-overhead version of the X.500 directory services protocols used at the time, such as directory access protocol (DAP).Â
X.500 had a large bandwidth-intensive footprint, making it strenuous for both the systems and the network. Little wonder that most computers on people’s desks in the early 1990s couldn’t connect to an X.500 directory service.
Consequently, in those days, X.500’s usage was limited to specific systems like mainframes, mini-computers, or micro-computers, and generally not PCs.
LDAP solved these problems by allowing for authentication and authorization of users to IT resources while reducing overhead, bandwidth use, and demand on endpoints. Due to these efficiencies, LDAP found great success and became the de facto Internet directory services authentication protocol in no time.
LDAP version 3 was proposed and accepted as the internet standard for directory services in the late nineties. This remains the latest and most prevalent version of LDAP today.
Following this milestone, Kurt Zeilenga started the OpenLDAP Project by releasing OpenLDAP 1.0 in 1998. This version included advanced security features, updated platform support, and bug fixes. It was also the first entirely open-source suite of client and server applications derived from LDAPv3.3.
Amongst other factors, OpenLDAP also enjoyed popularity because it enabled IT admins to modify it to fit their organizations’ needs better. have continued to drive OpenLDAP’s development since 1999.
Also in 1999, Microsoft released Active Directory, which used LDAP and Kerberos while creating proprietary extensions to keep organizations locked into the Microsoft ecosystem.
LDAP has since significantly impacted the evolution of directory services and has become an essential component of modern IT infrastructure.
How Does LDAP Work?
LDAP works by specifying a method of directory storage that allows for adding, deleting, and modifying records. It also enables the search of those records to facilitate both authentication and authorization of users to resources.
LDAP’s three main functions are:
- Update: This includes adding, deleting, or modifying directory information.
- Query: This includes searching and comparing directory information.
- Authenticate: The main authentication functions include binding and unbinding; a third function, abandon, can stop a server from completing an operation.
LDAP Directory Components
When working with an identity provider (IdP), much of LDAP’s operations happen behind a graphical user interface (GUI). Nonetheless, it is helpful to know its components to round out your understanding and help with customization or troubleshooting down the road.
Plus, although OpenLDAP allows for flexible customization, it requires more intricate knowledge of the protocol and its use cases. Especially as changes are generally made using the command line, configuration files, or, sometimes, by modifying the open-source code base.
The following are some of the key elements and concepts of the LDAP protocol and LDAP-based directory:
LDAP Directory Information Tree
LDAP organizes information in a hierarchical tree structure called a directory information tree (DIT). The DIT can vary based on the software or directory service you use.
Generally, though, LDAP directories follow a tree structure where entries without subordinates—users, for example—are leaves. At the same time, the root is the overarching entity encompassing all the information within the directory.
The root is a directory server agent specific entry, also called the root DSE, and it provides information about the directory.
Above is a highly simplified example of an LDAP directory information tree (DIT). There can only be one root, but the branches can be iterative and groups can nest. The leaves—users and printers in the above diagram— have attributes, but they cannot have subordinate entities.
LDAP directories can contain entries for users, groups, printers, servers, applications, and more.
Entry
Entries use attributes to describe the real-world items stored in the directory, like a user or a machine. Just as you’ll find in a phone book, or perhaps, your phone’s contact list, users in a DIT exist as entries, which store additional information about the user.
In LDAP, entries are often referred to by their common name (CN). For users, this common name is usually their username or first and last name.
Attribute
Attributes describe a user, server, or other item stored in the LDAP directory. A user’s attributes, for starters, would typically include their full name, email address, username, and password. Attributes are made up of a type and a value; i.e.,
mail(type)[email protected](value)
The available attributes to include are predefined by an ObjectClass attribute. Organizations may use more than one ObjectClass attribute and create custom ObjectClass attributes to contain the information they want to store in their LDAP directory.
Note that there can only be one structural object class per entry. While additional auxiliary object classes may exist, the structural object class defines each entry.
Schema
Schemas define the directory. Specifically, a schema defines the parameters of the directory, including syntax, attribute types, object classes, and matching rules (e.g., whether the input password matches the directory data).
LDAP V3. offers a predefined schema, and other LDAP offerings provide schema variants or iterations. Therefore, different providers may format their LDAP directories differently. Creatin