Finally ... LDAP

---

The Lightweight Directory Access Protocol (LDAP) was developed as an alternative to the heavyweight DAP. LDAP simplifies the conversation between the server and the client while leaving out the seldom-used and rather esoteric features of DAP. The most significant advantage of LDAP is that it runs on top of the TCP/IP protocol stack.

The first LDAP applications used a gateway between the client and the directory server, as seen in Exhibit 5. The gateway is called the "LDAP server." For communication between the LDAP server and the client, the less-resource-consuming LDAP protocol is used. Communication between the LDAP server and the directory server continues to rely on DAP, thus freeing the client from the burden of supporting the OSI stack and placing it on the LDAP server instead. The server now has to know to communicate using both TCP/IP-enabled LDAP to communicate with the client and OSI-enabled DAP to access the directory.

Exhibit 5: Gateway to Access an X.500 Server

The problem of the gateway solution was that it was not possible to use the LDAP protocol in an environment that did not support the OSI protocol. There were also a number of companies that simply did not wish to install an X.500 server on their networks just to be able to use LDAP. To solve this problem, an LDAP server was developed that worked in a pure TXP/IP environment and instead of acting as a gateway, used LDAP on its front end and accessed the directory on its back end, as seen in Exhibit 6.

Exhibit 6: LDAP Server in a Pure TCP/IP Environment

Most of the LDAP work was coordinated at the University of Michigan. The first protocols are defined in RFC 1202, "Directory Assistance Service," and RFC 1249, "DIXIE Protocol Specification." These are not proposed standards but, rather, only informational RFCs. The first LDAP specification was RFC 1487, "X.500 Lightweight Access," which was later replaced by the final version RFC 1777, "Lightweight Directory Access Protocol." This RFC version, also referenced as LDAP (v2), has been qualified as a draft standard by IETF. The exact details about this protocol and its extensions can be found in following RFCs:

• RFC 1777, "Lightweight Directory Access Protocol"

• RFC 1778, "The String Representation of Standard Attribute Syntaxes"

• RFC 1779, "A String Representation of Distinguished Names"

• RFC 1959, "An LDAP URL Format"

• RFC 1960, "A String Representation of LDAP Search Filters"

As the popularity of LDAP grew, more and more applications began to use LDAP services. An improved version has been defined in RFC 2251, "LDAP (v3) Protocol." Instead of being a "draft standard," like the LDAP (v2) protocol in RFC 1777, the LDAP (v3) protocol defined in RCF 2251 has been assigned the "proposed standard" status. If you want to consult the official protocol definitions of LDAP (v3), refer to the following RFCs:

• RFC 2251, "Lightweight Directory Access Protocol (v3)"

• RFC 2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions"

• RFC 2253, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names"

• RFC 2254, "The String Representation of LDAP Search Filters"

• RFC 2255, "The LDAP URL Format"

• RFC 2256, "A Summary of the X.500(96) User Schema for use with LDAP (v3)"

• RFC 2829, "Authentication Methods for LDAP"

• RFC 2830, "Lightweight Directory Access Protocol (v3):Extension for Transport Layer Security"

• RFC 3377, "Lightweight Directory Access Protocol (v3): Technical Specification"

Version 3 has a number of improvements over Version 2. These improvements are listed here and discussed in greater detail in later chapters, such as in Chapter 3, where we discuss the theory behind the LDAP models. This information is taken from RFC 2251. Interested readers should consult this RFC.

• Most protocol data elements can be encoded as ordinary strings.

• Referrals can be returned. This means that a directory server not containing the requested data can ask another directory server for that information and turn it back to the client.

• SASL (simple authentication and security layer) mechanisms can be used with LDAP to provide associated security services.

• Attribute values and distinguished names have been internationalized through the use of the ISO character set (10,646 characters).

• The protocol can be extended to support new operations, and controls can be used to extend existing operations.

• The schema describing the data structures found in the directory is published in the directory for use by clients.

In this section, we learned that the Directory Access Protocol (DAP) is useful for accessing directories. However, DAP proved to be too heavy for implementation on client machines. Furthermore, not all environments had X.500 (DAP) servers available or had the ability to implement the required OSI protocol on the network. The TCP/IP-compatible lightweight alternative became the Lightweight Directory Access Protocol (LWDAP), available at the time of this writing as LDAP Version 3.

---