Lightweight Directory Access Protocol (LDAP) Overview

Reader Rating    from ratings

Because DAP is too heavyweight and difficult to easily implement, the University of Michigan, with help from the ISODE Consortium, designed and developed Lightweight Directory Access Protocol (LDAP). LDAP is a protocol that defines a directory service and the access to that service. It is designed to remove some of the X.500 burden from clients by removing DAP overhead and little-used features, emulating its complex operations, and simplifying its access. As a result, LDAP queries are much smaller than DAP's and its source code is about 4.4 times smaller than DAP's. This means that the directory is now accessible on most platforms.

LDAP is simple to work with and has features that enable it to support any kind of application. It allows directory information to be queried and managed. It has searching capabilities that allow complex searches on portions of the directory. In addition, it has an extensible information model that allows the stored information to be dynamically extended. LDAP's defaults are set in such a way that applications make very few calls to set session options.

LDAP simplifies DAP in four areas:

• Transport-- LDAP runs over the TCP/IP protocol stack.
  
  
• Functionality-- LDAP simplifies DAP's functionality by leaving out infrequently used and redundant operations. This means that it lacks some of DAP's functionality, but it also means that PCs and Macintoshes can run the LDAP protocol to access and manipulate X.500 directory services. PCs and Macintoshes can also be more easily used to store a directory service.
  
  
• Data representation-- LDAP uses strings to represent data. DAP uses a more complex data representation.
  
  
• Encoding-- LDAP uses a simpler version of X.500's Basic Encoding Rules (BER). LDAP v 2 restricts BER to use only the definite form of length encoding and encode all bit string, octet strings, and character strings in primitive form only. Clients should be able to display non-binary values with little or no translation.
  
  

Overall, the LDAP data and name space model is essentially the same as X.500's. Like X.500, the LDAP data model is based on entries that contain information about objects. The entries are composed of attributes that have a type and one or more values. Each attribute has a syntax that determines what kind of values it allows, such as ASCII characters, octet strings, or jpeg, and how those values behave during directory operations. And, like the X.500 name space, the LDAP name space is hierarchal and uses similar object classes such as country and organizational unit.

LDAP Communication Model

LDAP uses a client/server request/reply model. That is, clients send a request describing a desired operation to a server. The server then performs the operations on the directory that are necessary to complete the request. The server then responds to the client with the results. Figure 1 illustrates this communication model.

Figure 1: LDAP client communicating with X.500 directory services.

In Figure 1, the LDAP server maps LDAP APIs and protocols to the X.500 directory service's APIs and protocols. As I explain later, this is the model used by Novell's LDAP Services for eDirectory. LDAP Services is really an LDAP interface that runs on a Novell server.

LDAP is becoming widely accepted as a stand-alone directory service. In this case, the communication model is the same, except that the LDAP client queries an LDAP directory service as the next picture shows. As with any distributed directory service, the reply always references the same entry, regardless of which server is queried.

Figure 2: LDAP client communicating with LDAP directory services.

LDAP Application Model

LDAP supplies APIs for:

• Searching and retrieving entries from the directory
  
  
• Adding new entries to the directory
  
  
• Updating entries in the directory
  
  
• Deleting entries from the directory
  
  
• Renaming entries in the directory
  
  
• Binding operations
  
  
• Abandoning operations
  
  

LDAP uses its search function to emulate the more complex X.500 operations such as list and read. LDAP's search function is very similar to the DAP search. You specify a base object to be searched for and the portion (or scope) of the tree to search. A filter specifies which conditions must be met in order for the search to match a particular entry. The LDAP search operation offers identical functionality to DAP's, but is encoded in a simpler form.

The LDAP API allows applications to perform operations either synchronously or asynchronously depending upon whether you want to wait for one operation to complete before receiving the return value of a previous function. All LDAP operations in LDAP Services for eDirectory are asynchronous.

LDAP applications typically perform 5 general steps:

1. Open a connection to the LDAP server. This step involves initializing the session, setting session preferences and binding to the server. Usually the session preferences involve defining:
   
   
   • maximum number of entries returned in a search
     
     
   • maximum number of seconds spent on a search
     
     
   • how aliases are handled
     
     
   • how referrals are handled
     
     
   • whether the client is threaded
     
     
   • security preferences
     
     

Once the application is bound to the server it receives a connection handle to use for the remainder of the session. The use of connection handles allows a client to have several connections open at once. LDAP v 3 negotiates and opens Secure Socket Layer (SSL) connections at this point.

2. Authenticate to the server. The client can authenticate either anonymously with public rights, or fully with a password. Novell's LDAP Services v 3 requires an SSL connection for full authentication. By default, Novell LDAP Services v 3 will not allow passwords over an open or non-secure connection.
   
   
3. Perform the operations and obtain the results. This step usually involves searching the directory services data. It frequently also involves manipulating the directory services data as well.
   
   
4. Process the results. This step involves making use of the returned information. Applications often have very little work besides parsing.
   
   
5. Close the session. This step involves unbinding from the server and disposing the session handle.
   
   

Updating a distinguished name provides a simple example of this five-step model:

1. The client application requests a session and binds to the LDAP server. The LDAP server returns a connection handle to the client application.
   
   
2. The client application submits a request to modify an entry. The request contains the connection handle, the distinguished name of the entry, the updated attribute information and any other pertinent information to the LDAP server.
   
   
3. The LDAP server uses this information to locate the entry and performs the modify operation to update the entry. It returns the result to the client.
   
   
4. The application processes the results to determine whether the attempt was successful or unsuccessful.
   
   
5. The application then closes the session, unbinds from the server and disposes of the session handle.
   
   

Differences between LDAP Versions 1, 2, and 3

LDAP v 1 (defined in RFC 1487) did not define inter-server communication, replication or provide strong security. It also depended on the DAP protocols to maintain the directory tree and to update the servers.

LDAP started being widely accepted with v 2, defined in RFCs 1777 and 1778. As LDAP v 2 became more widely accepted, its limitations became more apparent. Because it had only limited security and did not support references, protocol extensions, and internationalization, it was not promoted to the status of a full Internet standard.

LDAP v 3 was designed to overcome those limitations and was promoted to Proposed Standard status by the Internet Engineering Steering Group (IESG) in December 1997.

LDAP v 3 includes these new features:

• Referrals
  
  
• Security enhancements
  
  
• Unicode character support
  
  

LDAP v 3 also improves compatibility with X.500 directory services and specifies LDAP interactions with non-X.500 and standalone directories.

Referrals

X.500 specifies that whenever a server cannot find the requested information within its own directory services, its reply can contain a referral to another server that does have the desired information, if the original server knows about it. The client then makes a new request to the other server. For example, if the directory services server at ACME Industry receives a request for information from State University, the ACME industry server can refer the client to the directory services server at State University. In this way, two directory services can appear to be a single directory service.

LDAP v 2 does not support referrals. If the LDAP server cannot find the requested information in its own directory, it fails the search and returns an error. The University of Michigan created an extension to LDAP that allows LDAP v 2 to return referrals to clients as an error message. This adds complexity to the client because it must follow the referrals, but the server retains simplicity.

LDAP v 3 supports referrals by specifying that the LDAP server must either return the referral to the client or resolve the referral and return the desired information to the client. Figure 3 shows both models of referral resolution.

Figure 3: LDAP server resolving the referral.

Figure 4: LDAP client resolving the referral.

LDAP v 3 does not provide a method that allows multiple trees to learn about each other and their contents. Currently, any index or referral information is configured manually.

A server might also use a referral to allow the client to communicate with a closer replica of the data, as shown in Figure 5.

Figure 5: Referral to closer replica.

Security and Enhancements

As LDAP became more and more accepted, its authentication and security limitations became more pronounced.

LDAP v 2 defines a simple method for authentication. It uses clear text passwords and Kerberos v 4. (Kerberos is a secret key authentication method developed by MIT. For more information see http://web.mit.edu/kerberos/www/.) Version 2 LDAP servers can be set up to restrict permissions to the directory. Before LDAP clients can ask an LDAP server to perform an operation, the client must authenticate by supplying a distinguished name and password. If the client does not have sufficient rights to perform the operation, the server fails the operation and replies "unsuccessful."

LDAP v 3 unlike LDAP v 2, LDAP v 3 supports SSL connections, strong authentication with X.509 certificates, and supports Access Control Lists (ACL).

LDAP v 3 also provides minimal authentication using only a clear text password, but it is not recommended to use this method over an open network with no authentication or encryption. Version 3 supports both anonymous and full authentication. If the client is using anonymous, or no authentication, it must choose the simple authentication method and use a null password. Typically, the Distinguished Name (DN) is also null, as well. An anonymous authentication grants only public rights. Some operations, such as general searches, only require public rights and therefore only need an anonymous connection, not a fully authenticated connection. To authenticate as a specific user (a fully authenticated connection), the client provides the user's DN and password. This authentication grants clients their specific rights.

If you are using a connection-oriented transport, such as TCP/IP, version 3 allows you to use simple authentication with a clear text password and the Simple Authentication and Security Layer (SASL) standard to secure access between the LDAP client and server. SASL enables full user authentication, data encryption and data integrity.

In this model, once a client authenticates to a server and negotiates the protection of subsequent interactions, a security layer defined by SASL is inserted between the LDAP protocol and the connection protocol. This picture shows the placement of SASL. After the client and server negotiate the use of a SASL layer, they send all subsequent data to be sent over the wire through this layer.

Figure 6: Client/Server communication protocol without the SASL.

Figure 7: Client/Server communication protocol with the SASL.

By default Novell's LDAP Services v 3 for eDirectory requires an SSL connection for a full authentication using a password. SSL is a type of SASL.

Unicode Character Support

LDAP v 2 did not support internationalization. Version 3 allows internationalization by supporting the ISO 10646 character set (popularly known as Unicode), transported in UTF8 format.