Share This Article
Contents
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
LDAP was developed in 1993 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. Howard Chu and the Symas team 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. Creating a custom schema is also possible for more nuanced and niche use cases.
DN: Distinguished Name
This is the unique identifier for an LDAP entry, specifying all the attributes assigned to the object. It can contain multiple data points and comprises relative distinguished names (RDNs) in a string separated by commas.
The DN format works like geographic coordinates, only in reverse order: it specifies the location in the directory by listing each subsection in increasing degrees.
While geographic coordinates start general and get more specific, the DN starts with the object’s name and works up to the main directory component—your LDAP server’s domain, for example—forming a complete address pointing to the entry’s location in the LDAP tree.
DNs are formatted as follows:
RDN,RDN,RDN
For Peter Gibbons, a programmer in the IT department at Initech, the DN may look like this:
cn=Peter Gibbons,ou=IT,ou=People,dc=Initech,dc=com
RDN: Relative Distinguished Name
These are strings that assign values to attributes, like assigning an email address to a user. They are formed with an equal sign (=) in name-value pairs. The format looks as follows:
attribute=value
For example, the RDN for user Peter Gibbons’ email address may be [email protected]
Multivalue RDNs
RDNs can be combined into an overarching RDN with plus signs. Multivalue RDNs treat two attribute values as one, and can be used to differentiate between two RDNs with the same value.
For example, in an instance of two users having the same name, the directory could attach the RDN for their email address to their username to create unique RDNs for each. A multivalue RDN would be formatted as follows:
RDN+RDN
LDAP Servers
An LDAP directory can contain one or more servers, but there must be one root server (the root DSE in the diagram above). Main LDAP servers run on the stand-alone LDAP daemon (slapd) and they send changes to server replicas via the stand-alone LDAP update replication daemon (slurpd).
Traditionally, LDAP servers were hosted on-prem and managed by the organization internally, and Microsoft AD was the most popular commercial solution for LDAP on the market.
OpenLDAP is the most popular open-source and pure-play LDAP server available today. Now however, organizations are more often using cloud-hosted directory services that relieve the burden of internal server hosting, security, and management.
Cloud-based LDAP servers also enable organizations to shift their infrastructure to the cloud, take advantage of remote work opportunities, and decrease costs. See the LDAP and Active Directory section in this article to learn more.
LDAP Authentication and Authorization
The LDAP protocol both authenticates and authorizes users to their resources. The protocol authenticates users with a bind operation that allows the user to communicate with an LDAP directory, then authorizes the authenticated user to the resources they need if their input login information matches what’s listed for them in the database.
How LDAP Authentication Works
LDAP authentication relies on a client/server bind operation. This operation allows the LDAP-ready client, also called the directory user agent (DUA), to communicate with the directory server, also called the directory system agent (DSA), in a secure, encrypted session.
When authenticating against an LDAP server to access the database, the user is prompted to provide their username and password.
If the values the user inputs into the client match what is found in the LDAP database, the LDAP server grants the user access to whatever the IT resource may be.
How LDAP Authorization Works
Once a user is successfully authenticated, they need to be authorized to access the resource(s) requested. While different LDAP instances may structure and encode this process slightly differently, it is essentially accomplished by assigning permissions with groups and roles in the directory.
With OpenLDAP, for example, users belong to groups that can be assigned different permissions. If the authenticating user is assigned the correct permissions to access a certain resource, the LDAP protocol will authorize them to it; if not, the protocol will deny access.
What Is LDAP Used For?
The LDAP protocol defines a directory that can:
- Store user data in one central and accessible location.
- Associate those users with resources they are allowed to access.
- Authenticate and authorize users to their assigned resources, which include:
- Technical Applications: Jenkins, Docker, OpenVPN, the Atlassian suite, and many others authenticate best with LDAP.
- Server Infrastructure: Linux servers, both on-prem and in the cloud (like AWS), leverage LDAP to authenticate users. Learn more in Can I Integrate AWS With LDAP?
- File Servers: File servers like QNAP, Synology, and FreeNAS support LDAP.
- Networking Equipment: Though this can overlap with the RADIUS protocol, some organizations use LDAP for network access via VPNs, WiFi access points, and other networking equipment.
Back in LDAP’s early days, its functions were far more sophisticated than other options available. As the protocol gained popularity, more IT resources became LDAP-compatible. New offerings such as cloud LDAP, other authentication protocols, and full directory services also entered the scene to support access to those resources.
Now, IT admins can use LDAP to authenticate machines and manage access to legacy applications, networks, NAS, and other components both on-prem and in the cloud. With cloud directory services like JumpCloud, they can combine this functionality with other protocols to provide users access to virtually all their IT resources.
LDAP and Active Directory: What’s The difference?
As LDAP became a core directory services protocol, Microsoft AD built many of its underpinnings on LDAP; however, AD is not a pure LDAP tool.
While AD can use LDAP, it relies more heavily on Kerberos for authentication and is less flexible than an open-source LDAP directory. AD requires domain controllers and works best with Microsoft Windows-based devices and applications. Explore these differences further in our AD vs. LDAP comparison.
Until recently, directory tools predominantly catered to on-prem Windows-based environments. AD’s success came largely from its focus on Windows-centric, on-prem environments, which were the business standards for decades.
However, this past decade’s transition to the cloud, which accelerated with the pandemic-driven mass shift to remote work in 2020, changed the world’s directory needs.
Companies are now opting for cloud-based, Mac and Linux friendly directory services in place of AD and other on-prem directory models.
Skip to the section on LDAP’s Place in the Cloud to read more about how LDAP solutions have evolved to accommodate these changes.
LDAP and Azure Active Directory
Azure Active Directory is a cloud-friendly add-on to AD that enables Azure user management and web application single sign-on. Azure Active Directory does not use LDAP natively, instead, it uses other protocols, and it facilitates LDAP functions with Azure AD Domain Services (DS) or a hybrid AD environment where LDAP is necessary.
Azure AD DS is billed as a domain controller-as-a-service for virtual machines and Windows legacy applications deployed within Azure. It’s charged per hour, and the price is based on the number of directory objects.
For organizations that use LDAP with Azure AD, especially in an on-prem environment, it can be quite a tricky balancing act. This explains why many IT organizations opt to deploy an additional LDAP server in the cloud.
LDAP’s Place in the Cloud
Recent shifts to the cloud, coupled with disparate workplaces, have created the need for flexible directory solutions that work with cloud resources. It is also important that these solutions are built to accommodate different operating systems. This is especially as at least 55% of businesses are now Mac-friendly, and 90% of the world’s cloud infrastructure operates on Linux.
The implication of this is that AD’s Microsoft Windows and an Azure-centric approach is no longer viable for many businesses with OS-diverse environments. This has led them to resort to relying on additional integrated solutions to manage their growing infrastructure; particularly cloud LDAP and Directory-as-a-Service.
Cloud LDAP relieves companies of a great deal of directory management burden. This ranges from setting up and maintaining the core directory infrastructure to integrating applications and systems into their LDAP-based IdP. With cloud LDAP, the servers are primed and ready for businesses to direct their LDAP-connected endpoints to them.
Cloud directory services also tend to use other protocols as well. This widens their scope and positions them to accommodate emerging technologies. This ultimately eliminates the need for an on-prem Active Directory server.
Some cloud LDAP services also include a GUI and technical support where needed, eliminating the need to execute all operations with plain-text code. Nonetheless, some directory services still provide the option for command-line execution which are super helpful for bulk operations.
Is LDAP Still Relevant?
If directories are moving toward the cloud and LDAP was built to work in an on-prem environment, is LDAP still relevant?
With cloud applications becoming the business standard, IT networks have become more decentralized, and new protocols have being developed to meet these evolving needs. Naturally, these have led system administrators to question LDAP’s relevance in contemporary times.
LDAP is, however, still very relevant, given that directories have begun to adopt multi-protocol approaches to address modern, decentralized business environments. A multi-protocol directory leverages many protocols—each for a specific purpose.
The result is that each protocol is less frequently used but is highly suited to its use cases and remains a critical component of a robust multi-protocol directory.
LDAP is no exception; while it makes up a smaller percentage of the directory’s functionality than older directory models, it remains an integral part of the modern directory.
Multi-protocol directory services continue to use LDAP alongside other protocols because of its flexibility, open-source heritage, and stability over the years.
For example, many legacy applications like OpenVPN, Jenkins, MySQL, Jira, and Confluence— along with several other applications, storage systems, networking devices, servers, et.c.—continue to use LDAP.
How To Set Up LDAP
LDAP setup steps vary depending on which LDAP offering you’re using, and steps will largely depend on whether you’re using a cloud LDAP server or setting one up on your own.
Before starting down either path, however, the first step to any LDAP implementation should be planning: your IT team should think carefully about how it wants to organize its directory before implementing anything.
This thinking should consider the following:
- which resources to include in the directory
- how to separate user groups, allocate permissions
- operating systems you’ll need to accommodate
- how do you plan to integrate remote workers
- what your security parameters will be
- what you will do to ensure near 100% uptime
- how your organization plans to scale, and lots more.
Initial planning is critical to building an organized, scalable, flexible, and well-suited directory to its environment. For example, if you’re an organization of 10 but plan to expand significantly, it might make sense to divide your employees into departmental groups at the outset. This allows for organized growth, even if each department starts with only one or two users.
Planning is also critical for organizations building their directories because it helps them understand which LDAP solutions best meet their needs.
After planning your directory layout and choosing an LDAP provider (or opting for open-source LDAP), you must configure your LDAP servers.
On-Prem LDAP Setup:
If you’re hosting your own LDAP instance, you must stand up your LDAP server(s). The steps to installing and configuring your LDAP directory will vary depending on the LDAP instance you use. OpenLDAP is perhaps the most popular LDAP instance on the market, but there are other LDAP servers to choose from, such as Apache DS, 389 DS, and Open DJ.
Cloud LDAP Setup:
As mentioned earlier, cloud LDAP setup and maintenance are minimal. This is a major reason many companies choose it over traditional on-prem options. The server step for cloud LDAP involves subscribing to a cloud LDAP server rather than standing it up yourself.
You’ll still want to plan carefully before choosing an LDAP solution. Still, most providers offer directory configuration and management via a user-friendly GUI that makes modifications easier.
While there aren’t many free LDAP servers (including the hardware) to choose from, several free LDAP software options are available. We’ll explore those next.
LDAP Providers
Without LDAP, IT commonly lacks visibility into user accounts and activity. Admins will therefore need to manage resource access manually, This creates a decentralized and unorganized identity and access management (IAM) model that can lead to redundancies, friction, and security risk.
When organizations realize that the cost of implementing a solution is less than that of time-intensive manual management and the attendant risks, they often begin to look at LDAP. These are a few LDAP solutions most businesses consider:
Active Directory (AD)
AD uses LDAP and Kerberos to authenticate users to resources. As a Microsoft product, it is best suited for Windows-based environments. To use AD, IT admins must pay to license Windows Server, which includes AD. This represents the traditional licensing model that IT organizations know well with Microsoft products.
AD also requires remote access, like a VPN or SD-WAN, to authenticate remote users to on-prem resources. Azure Active Directory has recently emerged as an extension to AD but lacks true, native LDAP capabilities.
OpenLDAP
As noted previously, OpenLDAP doesn’t cost anything to download. However, significant costs surround the infrastructure’s setup and ongoing management. Because of its open-source roots, OpenLDAP works great with Linux- and Unix-based OSes, so you’ll find it in many DevOps environments. Like AD, you’ll need a VPN to authenticate to on-prem resources.
Learn more about OpenLDAP vs Active Directory here.
Cloud LDAP
Cloud-based LDAP is vendor-neutral and works with a wide variety of IT resources. With a cloud directory platform, there is no need for a VPN—although they are still supported—instead, a lightweight agent on the user’s device establishes a secure TLS connection at the start of each session. This allows users to connect to their LDAP resources without a VPN securely.
Cloud LDAP services often include additional protocols so one tool can grant users access to virtually all their resources.
Pros and Cons of LDAP
What Are the Advantages of LDAP?
Open Source
It doesn’t often cost anything to download, and quickly try OpenLDAP.
Standardized
LDAP was ratified as an Internet Engineering Task Force (IETF) standard in 1997 with RFC 2251. As such, the industry at large supports LDAP and will continue to do so.
Flexibility
Developers and IT admins utilize LDAP authentication for many use cases, including application and remote server authentication. And because it‘s been used in so many different ways, there is a community surrounding the protocol that helps people get the most out of it.
Device-Agnosticism
LDAP is compatible with different operating systems and devices. However, different LDAP offerings may limit this flexibility; AD, for example, is Windows-centric and often requires add-ons to work seamlessly with additional operating systems.
Security
In its original instance, LDAP was transmitted over clear text. Today, however, there are options to encrypt LDAP communications, either over Secure Sockets Layers through LDAP over SSL i.e., LDAPS, or Transport Layer Security through StartTLS i.e STARTTLS.
STARTTLS is the ideal and highly secure option, with LDAPS coming in second — always use one of the two wherever possible (now, almost everywhere) rather than using clear text.
Learn more about LDAP vs. LDAPS here.
What Are the Drawbacks of LDAP?
Age
LDAP is an older protocol. Newer authentication protocols like SAML are built for modern, cloud-forward IT environments that use web applications.
On-Prem
LDAP is traditionally set up on-prem with an OpenLDAP server, and it is not an easy undertaking. For organizations moving to the cloud, setting up an on-prem authentication mechanism that bridges to cloud IT resources is less than ideal.
Expertise
LDAP setup and maintenance generally require an expert. People with this level of technical knowledge can be difficult to find and expensive. This is especially true for OpenLDAP.
Significant Ramp-Up
The larger your organization, the more difficult it is to start a new directory. Because directories are essentially an amalgamation of all the components in your organization, it can be challenging to build a new directory from scratch or pivot from one directory to another.
Fortunately, cloud directory platforms like JumpCloud have setup guidance and can integrate with existing directories like AD. Therefore, large companies looking to take advantage of cloud LDAP can do so without doing a full about-face.
Extending LDAP to a Full Cloud Directory
Cloud LDAP uses a cloud-hosted server to provide users access to all their on-prem resources. Cloud directory platforms now combine LDAP with other IAM protocols, like SAML, OAuth, RADIUS, SCIM, and WebAuthn, facilitating secure authentication and authorization to web and cloud-based resources.
Some LDAP instances integrate with protocols like RADIUS to facilitate secure WiFi and VPN access, Samba for secure file authorization, SAML, JIT, and SCIM for automated web-based identity provisioning.
The result is one core directory that manages your users and grants them access to all the IT resources they need—both on-prem and cloud-based—from wherever they are.
Cloud LDAP and Beyond with JumpCloud
Take control of your organization’s IAM and device management with JumpCloud’s cloud directory platform. By combining LDAP with other secure protocols, JumpCloud offers a comprehensive solution for connecting users to IT resources while also implementing a Zero-Trust security approach to keep devices and data secure.
Plus, with user-friendly GUI and live chat support, you’ll have all the tools you need to manage your network with ease. Don’t wait – check out our pricing model, sign up for JumpCloud today, and enjoy the benefits of streamlined IAM and device management firsthand.
