What should I know about LDAP?
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 and it is a lightweight version of Directory Access Protocol.
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.
Active Directory vs. LDAP
Active Directory is a directory service provider, while LDAP is an application protocol used by directory service providers such as Active Directory and OpenLDAP.
Active Directory also supports Kerberos-based authentication, and it is a proprietary product of Microsoft and is mainly associated with Windows servers.
LDAP can be used on almost any server with different operating systems.
How Does LDAP Work?
LDAP works by binding an LDAP user to an LDAP server. The client sends an operation request that asks for a particular set of information, such as user login credentials or other organizational data. The LDAP server then processes the query, communicates with directory services if needed, and provides a response. When the client receives the response, it unbinds from the server and processes the data accordingly.
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.
By default, you only have a few basic objects of type person or organization defined. You already have to define the others yourself (according to the application that requires it). Each entry in the tree has a unique name, the so-called “distinguished name” or “DN”. Example DN:
dn: cn=John Doe, ou=Staff, o=Contoso, c=USA
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?
The process starts when a user tries to access an LDAP-enabled client program, like a business email application, on their PC. With LDAPv3, users will go through one of two possible user authentication methods: simple authentication, like SSO with login credentials, or SASL authentication, which binds the LDAP server to a program like Kerberos.
In short, a client sends a request for information stored within an LDAP database along with the user’s credentials to an LDAP server. The LDAP server then authenticates the credentials submitted by the user against their core user identity, which is stored in the LDAP database.
If the credentials submitted by the user match the credentials associated with their core user identity that is stored within the LDAP database, the client is granted access and receives the requested information (attributes, group memberships, or other data). If the credentials sent don’t match, the client is denied access to the LDAP database
There are two LDAP authentication options in LDAP v3 – Simple and SASL (Simple Authentication and Security Layer).
Simple authentication allows for three possible authentication mechanisms:
Anonymous Authentication: Gives the client an anonymous status for LDAP.
Authentication without authentication: for registration purposes only, should not grant access to the client.
Name or password authentication: Grants access to the server based on the credentials provided – simple user or password authentication is not secure and is not suitable for authentication without privacy protection.
SASL authentication associates the LDAP server with another authentication mechanism, such as Kerberos. The LDAP server uses the LDAP protocol to send an LDAP message to another authorization service. This initiates a series of request response messages that result in either a successful authentication or a failed authentication.
It’s important to note that by default, LDAP transmits all of these messages in clear text, so anyone with a network analyzer can read the packets. You need to add TLS encryption or similar to keep your usernames and passwords safe.
Example LDAP settings of Microsoft Active Directory in our product:
The above dialog contains example LDAP settings of Microsoft Active Directory.
To the Storage Root field, enter the distinguished name of the AD node that contains all the users you want to import.
By default, only the given AD node (i.e. the Storage Root node) will be searched for users, excluding its sub-nodes. If you want to search for users in the storage root node and all of it’s sub-nodes, select the Include Subtree option.
In order to connect with ERES you will need to have a user in your LDAP server that can read from the Active Directory. Enter the user’s distinguished name in to the User DN field, and then type the user’s password to the Password field.
After “Save Changes & Test Connection”, LDAP users are imported into ERES. The users are listed under “User List” tab.
There are some users marked as LDAP users without access in the Users list (user roles are distinguished by their colors – there is a legend for that below the Admin Console).
Select one or more LDAP users without access. The Insert LDAP User(s) button will show up. Click on it.
A new window dialog will show up, allowing you to select user role for the selected user(s). Select a user role and click Ok.
The users will not be marked as LDAP Users without access anymore. Their color changed from dark red to light red (if you gave them admin privileges), blue (if they are designers) or black (if you gave them viewer rights). They are valid ERES users and can start using the ERES now.