Directories should be based on which protocol to allow use with multiple systems?

Organizations have been using the LDAP protocol for user management, attributes, and authentication for nearly three decades. In that time, the protocol has expanded and evolved to meet changing IT environments and business needs.

This blog covers everything you need to know about LDAP, from its origins to its place in the cloud-driven business world today, and explains 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?

LDAP (Lightweight Directory Access Protocol) is one of the core protocols that was developed for directory services (the process of securely managing users and their access rights to IT resources), and most directory services still use LDAP today, although they may also use additional protocols like Kerberos, SAML, RADIUS, SMB, Oauth, and others.

In a nutshell, LDAP specifies a method of directory storage and facilitates the authentication and authorization of users to servers, files, networking equipment, and applications, among other IT resources. LDAP was developed in 1993 by Tim Howes and his colleagues at the University of Michigan to be a lightweight, low-overhead version of the X.500 directory services protocols that were in use at the time, like DAP (directory access protocol). 

X.500 was hard on both the systems (large footprint) and network (bandwidth intensive). In fact, many of the systems on people’s desks in the early 1990s could not connect to an X.500 directory service, so it was limited to specific systems (think more like mainframes, mini-computers, or micro-computers back in the day – generally not PCs).

LDAP solved these problems by allowing for authentication and authorization of users to servers, files, and applications while reducing overhead, bandwidth use, and demand on endpoints.

As a result of these efficiencies, LDAP would find great success and become the de facto internet directory services authentication protocol for quite awhile. In fact, LDAPv3 (the third version of LDAP) was proposed and accepted as the internet standard for directory services in 1997. This is the latest and most prevalent version of LDAP today.

Following this milestone, Kurt Zeilenga started the OpenLDAP Project with the release of OpenLDAP 1.0 in 1998.

OpenLDAP 1.0 was the first completely open-source suite of client and server applications derived from LDAPv3.3 and included advanced security features, updated platform support, and bug fixes. OpenLDAP’s open-source nature allowed IT admins to modify it to better fit the needs of their organization, which made it a popular LDAP choice. OpenLDAP has since been driven by Howard Chu and the Symas team.

A year later, in 1999, Microsoft released Active Directory, which used LDAP and Kerberos, while also creating proprietary extensions to keep organizations locked into the Microsoft ecosystem. 

How Does LDAP work? 

In short, LDAP specifies a method of directory storage that allows for adding, deleting, and modifying records, and it 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 be used to stop a server from completing an operation. 

LDAP Directory Components

The following are some of the key elements and concepts of the LDAP protocol and LDAP-based directory. When working with an identity provider (IdP), much of this happens behind a GUI; however, it can be helpful to know, both to round out your understanding and help with customization and troubleshooting down the road.

Further, OpenLDAP allows for flexible customization, but requires more intricate knowledge of the protocol and its use cases. Generally, those changes are made using the command line, configuration files, or, sometimes, by modifying the open source code base. Understanding how LDAP works is particularly important for those using OpenLDAP and for those interested in customizing it to their needs.

LDAP Directory Information Tree

LDAP organizes information in a hierarchical tree structure, referred to as a directory information tree (DIT). The LDAP DIT can vary based on the software or directory service you use; however, LDAP directories generally follow this tree structure, where entries without subordinates (users, for example) are leaves, and the root is the overarching entity that encompasses all the information within the directory.

This root is a directory server agent (DSA) specific entry (DSE), called the root DSE, and it provides information about the directory.

Entry

Entries use attributes to describe the real-world items stored in the directory, like a user or a machine. Just like in a phone book — or, more relatably, the contact list in your phone — users 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 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 example, would typically include their full name, email address, username, and password, for starters. Attributes are made up of a type and a value; i.e., mail(type)[email protected](value).

The attributes available to include are predefined by an ObjectClass attribute; organizations may make use of more than one ObjectClass attribute and create custom ObjectClass attributes to encompass the information they want to store in their LDAP directory, but there can only be one structural object class per entry. (There may be additional auxiliary object classes, but one main object class, called the structural object class, defines each entry).

Schema

Schemas define the directory. Specifically, a schema defines the parameters of the directory, including syntax, matching rules (i.e., does the input password match the directory data?), attribute types, and object classes.

LDAPv3 (the most current iteration of LDAP) offers a predefined schema, and other LDAP offerings provide schema variants or iterations, so different providers may format their LDAP directories a bit 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, and it specifies all the attributes assigned to the object. It can contain multiple data points and is composed of relative distinguished names (RDNs) in a string separated by commas.

The DN format works like geographic coordinates, only in reverse order: it specifies 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 (like two users with 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 slapd daemon, and they send changes to server replicas via the slurpd daemon. 

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.

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. 

What Is LDAP Authentication 

LDAP authentication relies on a client/server bind operation, which allows the LDAP-ready client, referred to as the directory user agent (DUA), and the directory server, referred to as the directory system agent (DSA), to communicate within a secure, encrypted session.

When authenticating against an LDAP server in an attempt to gain access to the database, the user is prompted to provide their username and password.

If the values the user inputs into the client matches what is found in the LDAP database, the user is granted access by the LDAP server to whatever the IT resource may be.

What Is LDAP Authorization

Once a user is successfully authenticated, they need to be authorized to the resource(s) requested. While different LDAP instances may structure and encode this slightly differently, this 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 when LDAP originated, the above functions were far more sophisticated than other user management options available. As the protocol gained in popularity, more IT resources became LDAP-compatible, and new offerings — including cloud LDAP, other authentication protocols, and full directory services — entered the scene to support access to those IT 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 some 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 functioned within and 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 standard 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, a cloud-friendly add-on to AD (not a replacement of AD) for Azure user management and web application single sign-on, 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 for the hour, and the price is based on the number of directory objects.

For those that want to use LDAP with Azure AD, especially authenticating on-prem applications or storage systems, it can be quite challenging. Many IT organizations opt to deploy an additional LDAP server. In many instances, this LDAP server is deployed in the cloud.

LDAP’s Place in the Cloud

Recent shifts to the cloud and disparate workplaces have created the need for more flexible directory solutions that can work with cloud resources and accommodate different operating systems; 55% of businesses are now Mac-friendly, and 90% of the world’s cloud infrastructure operates on Linux.

AD’s Microsoft Windows and Azure-centric approach is no longer viable for many businesses with OS-diverse environments, and many rely on several additional integrated solutions to manage their growing, diversifying, and dispersing infrastructure. These new challenges with AD and on-prem directories have driven businesses to turn to cloud LDAP and, ultimately, Directory-as-a-Service.

Cloud LDAP relieves companies of a great deal of directory management burden, 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 already there and ready for businesses to direct their LDAP-connected endpoints to them.

Cloud directory services also tend to use other protocols as well, further widening their scope and accommodating new technologies as they emerge while eliminating the need for an on-prem Active Directory server.

Some cloud LDAP services also include a GUI and technical support, eliminating the need to execute everything with plain-text code (although some directory services still provide the option for command-line execution, which can be beneficial for executing operations in bulk) and offering expert help where needed.

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?

As cloud applications become the business standard, IT networks become more decentralized, and new protocols are developed to meet these evolving needs, some system administrators have begun questioning LDAP’s relevance. 

Directories have begun to adopt multi-protocol approaches to address modern, decentralized business environments. The 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 compared to 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 tens of thousands of other applications, storage systems, networking devices, servers, and more — 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 standing 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 includes which resources to include in the directory, how to separate user groups and allocate permissions, which operating systems you’ll need to accommodate, how you plan to integrate remote workers, what your security parameters will be, what you will do to ensure near 100% availability, how your organization plans to grow, and more. 

Initial planning is critical to building an organized directory that’s well-suited to its environment and well-positioned to accommodate growth and changes. For example, if you’re an organization of 10 but know you plan to expand significantly, it might make sense to divide your employees into departmental groups at the outset to allow for organized growth, even if each department starts with only one or two users. 

The planning step is especially critical for organizations building their own directories; however, it also helps organizations understand which LDAP solutions would best meet their needs. 

After planning your directory layout and choosing an LDAP provider (or opting for open-source LDAP), you’ll need to configure your LDAP servers. 

On-Prem LDAP Setup: 

If you’re hosting your own LDAP instance, you’ll need to 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 several LDAP servers to choose from.

Cloud LDAP Setup:

As we mentioned, cloud LDAP setup and maintenance is minimal, which is one of the reasons 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 carefully plan before choosing an LDAP solution, but most providers offer directory configuration and management via a user-friendly GUI that makes modifications easier down the road. 

While there aren’t many free LDAP servers (including the hardware) to choose from, there are several free LDAP software options available. We’ll explore those next. 

LDAP Providers

Without LDAP, IT commonly lacks visibility into user accounts and activity and manually manages resource access, creating a decentralized and unorganized identity and access management (IAM) model that can lead to redundancies, friction, and security risk.

When organizations realize the cost of implementing a solution is less than the cost of time-intensive manual management and the risks associated with it, they often begin to look at LDAP. There are a few main LDAP solutions most businesses consider:

Active Directory (AD)

AD uses LDAP and Kerberos to authenticate users to IT 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.

Finally, AD requires some form of 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. Significant costs do surround the setup and ongoing management of the infrastructure, though. 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.

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, allowing users to securely connect to their LDAP resources without a VPN. Cloud LDAP services often include additional protocols in their offering 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 back in 1997 with RFC 2251. As such, the industry at large supports LDAP and will continue to do so. 
• Flexible: Developers and IT admins utilize LDAP authentication for many different 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-Agnostic: By nature, 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.
• Secure: In its original instance, LDAP was transmitted over clear text; however, there are options to encrypt LDAP communications, either over SSL (LDAPS) or over TLS (STARTTLS). STARTTLS is the ideal option and is highly secure, 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.

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, having to set 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, some cloud directory platforms like JumpCloud have setup guidance and can integrate with existing directories like AD, so 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 are now combining LDAP with other protocols, like SAML, OAuth, RADIUS, SCIM, and WebAuthn, that facilitate secure authentication and authorization to web and cloud-based resources.

Some LDAP instances also integrate with other 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, and more. 

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

The JumpCloud directory platform was the first comprehensive cloud directory service to offer direct LDAP configuration to services and applications. Further, JumpCloud combines LDAP with RADIUS, SAML, Samba, WebAuthn, SCIM, and other protocols to connect users to the IT they need to Make Work Happen.

In addition to IAM and device management, JumpCloud applies a Zero-Trust security approach with tools like multi-factor authentication (MFA), facilitates cross-platform device management to keep all devices secure and correctly configured, and offers a user-friendly GUI for both admins and users.

Learn more about JumpCloud’s cloud LDAP offering, or try the platform free — it doesn’t cost anything to add your first 10 users and devices, and the platform comes with 10 days of live chat support.