What is LDAP?
Using CloudConnexa and Access Server With LDAP to Manage Data and Permissions
The Directory Access Protocol (DAP) is a protocol for accessing information in a directory service based on the X.500 recommendations. The Lightweight Directory Access Protocol (LDAP), as the name implies, is a lightweight, vendor-neutral version of DAP.
In 1993, LDAP was introduced, allowing applications to access and authenticate specific user information across directory services. It also works on both public networks and private intranets. This user-friendly language is one of the easiest ways to access, modify, and authenticate information in virtually any directory.
LDAP v3, the most prevalent version of the protocol, addresses some limitations — internalization, authentication, referral, deployment — found in v2. It also allows the addition of new features, using extensions and controls, without requiring protocol changes. Another difference between v2 and v3 is authentication mechanisms. LDAP v2 defined three types of authentication: anonymous, simple (clear-text password), and Kerberos v4. LDAP v3 supports anonymous, simple, and SASL authentication.
In this article, we take a look at how LDAP works and how you can configure both CloudConnexa and Access Server to connect with LDAP protocols.
Good to Know: The LDAP protocol was created by University of Michigan graduate student Tim Howes and his associates to replace DAP and enable low-overhead access to the X.500 Directory.
How LDAP Works
LDAP stores data in a centralized directory. Applications use the LDAP communication language to retrieve and update information in it.
To get work done, employees sign in to a number of apps, systems, and devices, each requiring usernames and passwords. That login information is stored in company directories where LDAP can connect users and applications to it. This allows single sign-on (SSO) so users can sign in once to access protected files and applications. A directory user (i.e., the employee via applications) accesses the directory through a client or Directory User Agent (DUA). CloudConnexa and Access Server act as a DUA. The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). Clients interact with servers using a directory access Protocol (DAP). Here the DAP used is LDAP.
To make this happen, the following sequence takes place when a user or application requests information from a server:
- The client connects to the DSA through TCP/IP port 389 or port 636 to initiate the LDAP session.
- A connection between the client and server is established.
- The server and client exchange data. The data exchange process can vary depending on the operations requested.
The primary operators that make functions possible with LDAP are:
- Add – Allows a client to request the addition of an entry into the directory.
- Bind – Authenticates clients to the directory server. As the client is acting on behalf of the user, the bind operation can be used to authenticate the actual directory user (e.g., employee). LDAP bind requests give the ability to use either simple authentication or simple authentication and security layer (SASL) authentication.
- Delete – Removes directory entries.
- Modify – Used to request changes (Add, Delete, Replace) to existing directory entries.
- Unbind – Terminates connections and operations in progress (reverse of the Bind operation).
LDAP communicates with a Directory System Agent (DSA) to access directory information. The DSA stores data in a hierarchical structure, beginning with the Root Object and unfolding into multiple items at each successive layer. Each successive level is known as an Object Class, and the items within each class are called Container Objects because they contain other objects.
An LDAP directory has a tree structure. All LDAP entries, or objects, have a defined position within this hierarchy, called the directory information tree (DIT). The directory schema has a variety of traits that identify its hierarchical relationships. LDAP queries are designed to align with the DSA’s hierarchy. When an entry is requested, the LDAP query references the Distinguished Name (DN) that contains the object's complete path. (Think of an LDAP entry DN like the path to a file on a filesystem.)
Note: A DN is a unique identifier for the hierarchical entry level, and a relative distinguished name (RDN) is a component of the DN.
Good to Know: OpenLDAP is a free, open-source implementation of the Lightweight Directory Access Protocol developed by the OpenLDAP Project. It is released under the OpenLDAP Public License, with its own BSD-style license.
LDAP vs. Active Directory
Microsoft Active Directory (AD) is a directory service created for Windows domain networks. AD is included in most Windows Server operating systems, whereas LDAP is a universal protocol used for accessing information from directories. LDAP can be used to query data from Active Directory.
How Does LDAP Authentication Work?
As mentioned above, the LDAP protocol can be used for authenticating users. This is how the two-step LDAP authentication process takes place:
STEP 1: Username is resolved to a directory entry attribute.
User entries in a directory are identified by a distinguished name (DN) that resembles a path-like structure starting at the directory root. User authentication with an LDAP directory requires the DN and password. Using indexing and caching, DN resolution runs a search of the user’s name, or email, against the name or email attributes of all user entries to find the matching entry DN. The searchFilter configuration parameter defines the directory attributes to search. (NOTE: The default LdapAuth configuration searches the UID and email attributes, substituting the %u placeholder with the user identifier entered.)
User login attributes that are not unique will not be authenticated, and the defined identifying attributes (e.g., username, email) must be the same for every user.
When the user’s directory entry DN is resolved, the password verification begins.
STEP 2: User password validation.
The LDAP bind command verifies passwords. First, it opens a directory server connection, then sends a connection authentication request with a specific user DN and password. The directory server either verifies the entries or returns an LDAP Invalid credentials error (code 49).
Good to Know: LDAP supports two methods to encrypt communications using SSL/TLS — traditional LDAPS and STARTTLS. Both CloudConnexa and Access Server support LDAPS.
Advantages of using LDAP with CloudConnexa
CloudConnexa can be configured to use private LDAP authentication. This means that the LDAP server is positioned in your private network, and your users authenticate with the OpenVPN Connect app using their LDAP username and password credentials. Doing this gives you the benefits of:
Using a single credential: Your workforce can connect to CloudConnexa with the same username and password they use for other corporate applications.
Eliminating the need for upgrades with native LDAP support: You won’t need to upgrade your LDAP directory or use intermediaries to work with SAML.
Enabling MFA for another layer of security: You can enable CloudConnexa MFA support in conjunction with the use of LDAP.
Synchronizing user information at sign-in: User account information is automatically pulled into the CloudConnexa directory on each successful authentication.
Enforcing group-level access control: Configure access controls for CloudConnexa user groups and then map them to your LDAP groups.
Configure CloudConnexa to Use LDAP
Get easy step-by-step instructions for setting up CloudConnexa to use the same private LDAP directory to authenticate remote access for your workforce here.
Benefits of Configuring OpenVPN Access Server With LDAP Authentication Protocols (And How to Do It)
It isn’t just CloudConnexa that works with LDAP; Access Server does, too, with similar benefits. Details for connecting Access Server with a variety of authentication services can be found here.
