The Lightweight Directory Access Protocol (LDAP) is an open-source application protocol that allows applications to access and authenticate specific user information across directory services.
LDAP is a "lightweight" version of Directory Access Protocol (DAP). LDAP works on both public networks and private intranets and across multiple directory services, making it the most convenient language for accessing, modifying, and authenticating information in any directory.
The two most popular directory services that communicate with LDAP are:
- Active Directory
- OpenLDAP
To understand the value of LDAP, consider the vast amounts of data required just for daily administrative tasks.
Employees need to regularly access usernames, passwords, email addresses, endpoints, and printers to fulfill their daily tasks.
Such information is stored on company directories and LDAP is the protocol that efficiently connects users and applications to this information.
Because LDAP maps to usernames and passwords, the protocol can also be used to authenticate users. This allows single sign-on (SSO), where users need to only sign in once to access all protected files and applications.
Active Directory vs. LDAP
An essential prerequisite to understanding how LDAP works is an understanding of its relationship with Active Directory.
LDAP and Active Directory are not the same, they work together to connect clients to servers.
LDAP is the language that Microsoft Active Directory understands. In order to access or authenticate any data stored on Active Directory, the LDAP protocol is used by Exchange Server to communicate with the target server.
If your organization uses Windows computers, it's likely relying on LDAP to ensure business continuity.
LDAP is also a cross-platform protocol, meaning that it can be used to share information between different directory services via the IP network.
Active Directory could be networked with Unix/Linux, OSX, and other non-Windows servers via the LDAP protocol.
The different directory services that support LDAP are listed below.
- 389 Directory Server
- Active Directory
- Apache Directory Server
- Apple Open Directory
- eDirectory
- Red Hat Directory Server
- Oracle Internet Directory
- Sun Java System Directory Server
- OpenDS
- Oracle Unified Directory
- IBM Tivoli Directory Server
- Windows NT Directory Services (NTDS)
- Critical Path Directory Server
- OpenLDAP
- Lotus Domino
- Nexor Directory
- OpenDJ
How Does LDAP Work?
When a user or an application requests information from a server, the following high-level sequence is initiated.
- Step 1 - Client connects to the Directory System Agent (DSA) through TCP/IP port 389 to commence an LDAP session.
- Step 2 - A connection between the client and server is established.
- Step 3 - Data is exchanged between the server and the client.
The data exchange process in step 3 varies depending on the specific LDAP operations being requested.
Many functions are possible with LDAP, through 4 primary operators.
- Add - Inserts a new entry into the directory-to-server database.
- Bind - Authenticates clients to the directory server.
- Delete - Removes directory entires.
- Modify - Used to request changes to existing directory entries. Changes could either be Add, Delete, or Replace operations.
- Unbind - Terminates connections and operations in progress (this is an inverse of the Bind operation).
To access directory information, an LDAP protocol communicates with a Directory System Agent (DSA) - the database that stores information like usernames, passwords, etc.
The Directory System Agent stores data in a hierarchical structure, starting from the Root Object and unfolding into multiple items at each successive layer.
Each subsequent level is known as an 'Object Class' and the items within each class are known as 'Container Objects' since they contain other objects.
The directory schema consists of multiple attributes identifying its hierarchical relationships.
Here's an example of the different attributes describing a set of contact details for a particular user.
LDAP queries are designed to align with the hierarchical structure of the Directory System Agent. When an entry is requested, the LDAP query references the Distinguished Name (DN), which contains the object's entire path.
For example, if the username EKost is stored in the cn=Users container which is stored in the domain UpGuard.com, its Distinguished Name (DN) would be as follows:
dn: cn=EKost,cn=Users, dc= UpGuard, dc=com
Where the references:
- CN = Common Name
- DC = Domain Components
There are other LDAP attributes, such as Relative Distinguished Name, that aid in the accurate classification of each item. For a list of LDAP attributes and their relations to Object Classes, see this post.
When reading the DN path from left to right, the reference moves up the information tree.
What is LDAP Authentication and How Does it Work?
Because LDAP facilitates connections to databases storing sensitive credentials, the protocol can be used to authenticate users.
At a high level, the authentication process occurs in 4 stages following a username and password submission.
- A Bind request is sent from the LDAP client to the LDAP server to initiate the authentication process.
- A Bind result communication is sent back to the LDAP client to confirm the authentication process has commenced.
- The LDAP protocol is used to confirm the existence of each credential in the LDAP directory and the valid combination of each entry.
- After user credentials have been authenticated, an Unbind Operation is sent to the LDAP server to terminate the connection.
- User access is either granted or denied.
There are three different methods for authenticating users in LDAPv3:
- Anonymous
- Simple
- SASL (Simple Authentication and Security Layer)
SAML is another protocol used for SSO authentication, but unlike LDAP, its authentication mechanism extends to the cloud and other web apps.
Anonymous Authentication
Anonymous authentication is the least secure because the user accounts being verified are stored on a public LDAP database.
Simple Authentication
The simple authentication mechanism only relies on directory entry name and password combinations which are usually delivered unencrypted via plain text - information that can easily be intercepted with a network sniffer.
This creates a heightened risk of permission escalation, where cyberattacks leverage privileged credentials to access sensitive data.
Learn more about Privileged Access Management (PAM).
Besides securing LDAP account access, adding SSL encryption to LDAP authentication data will prevent network sniffers from intercepting and compromising user credential data.
SASL Authentication
SASL is the most secure mechanism for LDAP authentication. SASL authentication integrates other authentication mechanisms like TLS and Kerberos to the LDAP server.
The Kerberos authentication mechanism uses cryptography to prevent traveling authentication data from being accessed and modified by cyberattackers.
LDAP authentication is supported by the following applications:
- Jenkins
- Docker
- Open VPN
- Linux Samba Servers
Cybersecurity Risks of the LDAP Protocol
Because LDAP facilitates connections to private resources, there are cybersecurity risks associated with this protocol, the most critical being LDAP injections.
An LDAP injection is a type of cyberattack where code is injected through a web application in order to access sensitive information in an LDAP directory.
The injected code contains LDAP metacharacters that modify legitimate requests from LDAP clients to achieve malicious objectives.
An LDAP injection could result in a data breach, user privilege escalation, or account hijacking.
LDAP injections are possible when servers do not validate the legitimacy of LDAP client requests, allowing cyberattackers to liberally communicate with LDAP servers.
Similar to an enumeration attack, LDAP injection could be used to confirm identifiers and attributes in a database.
How to Prevent LDAP Injections
LDAP injections can be mitigated with the following security controls.
- Enforce Server-Side Input Validation - All inputs should be validated against a list of permitted characters and strings.
- Escape User-Controlled Input Strings - This will turn malicious inputs into string values and not LDAP predicates.
- Implement Principe of Least Privilege - By securing the LDAP account required for binding a directory, LDAP queries will not be executed without authorization.
