Historical Background
X.500
The first widely recognized directory service was the X.500
Directory Access Protocol. This was a very powerful, all-purpose
directory service that incorporated many good ideas about what a directory
service should be able to do.
X.500 organizes directory entries in a hierarchical name space capable
of supporting large amounts of information. It also defines powerful
search capabilities to make retrieving information easier. Because
of its functionality and scalability, X.500 is often used together with
add-on modules for interoperability between incompatible directory services.
Unfortunately, X.500 proved to be ill-suited for deployment on the Internet.
It was difficult to implement and was too complicated for many of the simpler
tasks that seemed like logical candidates for directory services.
X.500 specifies that communication between the directory client and the
directory server uses the directory access protocol (DAP). However,
as an application layer protocol, the DAP requires the entire OSI
protocol stack to operate. Supporting the OSI protocol stack requires
more resources than are available in many small environments. Therefore,
an interface to an X.500 directory server using a less resource intensive
or lightweight protocol was desired.
X.500 is described in RFCs 1274
through 1279.
Early LDAP
The complexity of X.500 lead to the development of a simplified
front-end designed to hide some of its uglier features. This work
resulted in the Lightweight Access Protocol described in RFCs 1484
through 1488.
This protocol depended on an X.500 server for all real directory processing
and merely provided a more tractable interface for programmers and directory-enabled
applications.
The Directory Access Protocol was eventually replaced by the Lightweight
Directory Access Protocol (LDAP v1) which was first formally described
in RFC 1777.
Developed at the University of Michigan at Ann Arbor in conjunction with
the Internet Engineering
Task Force, LDAP is an Internet standard directory service that runs
over TCP/IP. LDAP databases can be distributed across multiple platforms
to increase availability to directory data.
The LDAP directory service is based on a client-server model.
One or more LDAP servers contain the data that make up the LDAP directory
tree. An LDAP client connects to an LDAP server and submits a query
regarding the directory data. The server responds with the answer,
or with a referral to another LDAP server where the client can possibly
have the query serviced.
LDAP was designed to provide 90% of the functionality of X.500
at 10% of the cost in terms of complexity and overhead. It can be
thought of as "fat-free X.500".
Modern LDAP
LDAP was accepted much more readily by the computer industry
than X.500. Its dependence on an underlying X.500 server was eventually
replaced by full stand-alone capabilities. LDAP version 2 offered a more
complete programming environment and was much easier to integrate with
existing applications.
It was at this point that LDAP started to
be recognized as a viable network-based service that justified the cost
of its implementation.
LDAP v2 is described in RFC
1823.
Multiple LDAP servers can contain identical directory entries using
a mechanism called replication. If you configure your LDAP servers to use
replication, one and only one LDAP server is responsible for modifications
to the directory. This server is known as the supplier server. Other
LDAP servers that receive replicated directory data are known as consumer
servers. All consumer servers refer modification requests back to the supplier
server.
LDAP v3 is described in RFCs 2251
through 2256.
|