Overview of LDAP
LDAP (Lightweight Directory Access Protocol) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
LDAP protocol is based on the client/server structure to provide directory information binding and querying, and all directory information stored on the LDAP server. It’s often used for authentication and storing information about users, groups, and applications, and an LDAP directory server is a general-purpose data store and can be used in a wide variety of applications.
Terminology
LDAP (Lightweight Directory Access Protocol)
LDAP is a protocol used to publish directory information to many different resources. It is often used as a centralized address book, and the basic model is based on entries. An entry is a collection of one or more attributes with a globally unique distinguishable name (DN). LDAP organizes the data in a tree structure.
Figure 1 LDAP Directory Structure
DC: Domain controller. It indicates the domain to which an object belongs. In general, one LDAP server is a domain controller.
DN: Distinguished name. It indicates the location of an object on the AD or LDAP server. It starts from the object to its upper layers, until the root nodes. In Figure 1, the DN of User 1 in the directory is “CN=User1, OU=People, DC=fs, DC=com”.
Based DN: DN of the root node. For example, in Figure 1, the base DN is “DC=fs, DC=com”.
OU: Organization unit. It indicates the organization to which an object belongs. OUs are stored in a tree structure. The top-level OU can contain multiple sub-OUs.
CN: Common name. It indicates the object name. In Figure 1, “CN=User 1” is the object name.
UID: User ID, a number or string that uniquely identifies the user.
Entry
An entry is the basic granule in LDAP, like a word in a dictionary or a record in a database. Additions, deletions, changes, and retrievals to LDAP are all based on entries. For example, “CN=User 1, OU=R&D, DC=fs, DC=com” is an entry.
Object Class
It is an important part of an LDAP entry defining what attributes can be included in an entry and the rules for the behavior of those attributes. In LDAP, every entry must contain at least one object class attribute, and this attribute needs to be assigned at least one value.
LDAP Operation Mechanism
LDAP is mainly used to store data that does not change frequently. For example, username, password, email address and other data, users can use LDAP binding and query operations to complete user authentication and authorization. LDAP based on the client/server structure provides directory information binding and querying, and all the directory information is stored on the LDAP server.
LDAP Messages
Message | Description |
bindRequest | Client sends a bind request to the server, including the admin user DN (e.g. CN= User1, OU=People, DC=fs, DC=com) and password. |
bindResponse | Server responds to user binding request. |
unbindRequest | After all LDAP operations completes, client sends an unbind request message to request the server to end the session. |
searchRequest | The client sends a query request to the server, including the query based DN (e.g., DC=fs, DC=com), search scope (e.g., sub), and filter (e.g., (uid=john)). |
searchResEntry | Server responds to user query request. |
searchResDone | The server returns the search status to the client.
|
abandon Request | If the client decides to give up waiting for the result before the operation completes, it can send an abandon request to cancel the operation. |
LDAP Authentication and Authorization Process
LDAP defines a variety of operations to perform functions, and the major operation to realize the user's authentication and authorization are binding and querying. The message exchange process between the User, Device and the LDAP server is as follows.
Before a trusted connection established, the LDAP client first connected to the LDAP server over TCP.
Figure 2. LDAP Operating Diagram
The user enters the username and password to issue an authentication request to the switch.
After getting the authentication information, the switch uses the admin DN and password to send a bindRequest message to LDAP server.
LDAP server receives the message, validates the relevant information of the admin, and if the information matches, the binding is successful, and the LDAP server sends a bindResponse message to switch.
After received the bindResponse message, the switch sends a searchRequest message to LDAP server according to filter conditions.
Once the LDAP server receives the searchRequest message, it queries the user DN according to query origin, query range, and filter conditions in the message. If the query is successful, it sends a search response message to the switch. The user DN can be one or more.
The switch sends a bindRequest message to the LDAP server based on the user DN and the password.
When the LDAP server received the user bindRequest message, it verifies whether the password entered by the user is correct.
If the password is correct, the switch will send bindResponse message for successful response message.
If the password is incorrect, the switch will send binding failure response message, and the switch continues to send bindRequest to the LDAP server with the next user DN until one DN binds successfully. If all user DNs fail to bind, the switch notifies the user of the authentication failure.
After successful authentication, the switch notifies the user of successful login.
Copyright © 2024 Pica8 Inc. All Rights Reserved.