To understand Lightweight Directory Access Protocol (LDAP) better, let's discuss X.500 and Directory Access Protocol (DAP).
In X.500, the Directory System Agent (DSA) is the database in which directory information is stored. This database is hierarchical in form, designed to provide fast and efficient search and retrieval.
The Directory User Agent (DUA) provides functionality that can be implemented in all sorts of user interfaces through dedicated DUA clients, Web server gateways, or e-mail applications.
The Directory Access Protocol (DAP) is a protocol used in X.500 Directory Services for controlling communications between the DUA and DSA agents. The agents represent the user or program and the directory, respectively.
The X.500 Directory Services are application-layer processes. Directory services can be used to provide global, unified naming service for all elements in a network, translate between network names and addresses, provide descriptions of objects in a directory, and provide unique names for all objects in the Directory. These X.500 objects are hierarchical with different levels for each category of information, such as country, state, and city, organization.
These objects may be files (as in a file system directory listing), network entities (as in a network naming services such as Novell's NDS), or other types of entities.
A lightweight protocol is any of a class of protocols designed for use on high-speed internetworks. High-Speed Transport Protocol (HSTP), Xpress Transfer Protocol (XTP), and Lightweight Directory Access Protocol (LDAP) are examples.
Lightweight protocols combine routing and transport services in a more streamlined fashion than do traditional network and transport layer protocols. This makes it possible to transmit more efficiently over high- speed networks, such as ATM or FDDI, and media, such as fiber-optic cable.
Lightweight protocols use various measures and refinements to streamline and speed up transmissions, such as using connection-oriented transmissions, such as (TCP/IP) and a fixed header and trailer size to save the overhead of transmitting a destination address with each packet.
Lightweight Directory Access Protocol (LDAP) is a subset of the X.500 protocol. LDAP clients are, therefore, smaller, faster, and easier to implement than are X.500 clients. LDAP is vendor-independent and works with, but does not require, X.500.
Contrary to X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. LDAP is an open protocol, and applications are independent of the of server platform hosting the directory.
The Active Directory is not an X.500 directory. Instead, it uses LDAP as the access protocol and supports the X.500 information model without requiring systems to host the entire X.500 overhead. The result is the high level of interoperability required for administering real-world, heterogeneous networks.
Naming
The Active Directory supports access via the LDAP protocol from any LDAP- enabled client. LDAP names are less intuitive than Internet names, but the complexity of LDAP naming is usually hidden within an application. LDAP names use the X.500 naming convention called "Attributed Naming."
An LDAP URL names the server holding Active Directory services and the Attributed Name of the object. For example:
LDAP://SomeServer.Myco.Com/CN=jamessmith,OU=Sys,OU=Product,OU=Division,O=myco,C=US
LDAP C API (RFC 1823) is an informational RFC that is the de facto standard in C programming for LDAP applications.
By combining the best of the DNS and X.500 naming standards, LDAP, other key protocols and a rich set of APIs, the Active Directory allows a single point of administration for all resources, including: files, peripheral devices, host connections, databases, Web access, users, arbitrary other objects, services, and network resources.
Applications
Every email program has a personal address book, but how do you look up an address for someone who's never sent you email? How can an organization keep one centralized up-to-date phone book that everybody has access to?
That question led software companies such as Microsoft, IBM, Novell, Linux, Lotus, and Netscape to support a standard called LDAP. "LDAP-aware" client programs can ask LDAP servers to look up entries in a wide variety of ways. LDAP servers index all the data in their entries, and "filters" may be used to select just the person or group you want, and return just the information you want. For example, here's an LDAP search translated into plain English: "Search for all people located in Chicago whose name contains "Fred" that have an email address. Please return their full name, email, title, and description."
LDAP is not limited to contact information, or even information about people. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide "single signon" where one password for a user is shared between many services. LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm.
As a protocol, LDAP does not define how programs work on either the client or server side. It defines the "language" used for client programs to talk to servers (and servers to servers, too). On the client side, a client may be an email program, a printer browser, or an address book. The server may speak only LDAP, or have other methods of sending and receiving data—LDAP may just be an add-on method.
If you have an email program (as opposed to web-based email), it probably supports LDAP. Most LDAP clients can only read from a server. Search abilities of clients (as seen in email programs) vary widely. A few can write or update information, but LDAP does not include security or encryption, so updates usually requre additional protection such as an encrypted SSL connection to the LDAP server.
LDAP also defines: Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private. Schema: a way to describe the format and attributes of data in the server. For example: a schema entered in an LDAP server might define a "groovyPerson" entry type, which has attributes of "instantMessageAddress", and "coffeeRoastPreference". The normal attributes of name, email address, etc., would be inherited from one of the standard schemas, which are rooted in X.500 (see below).
LDAP was designed at the University of Michigan to adapt a complex enterprise directory system (called X.500) to the modern Internet. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service "for the rest of us."