LDAP System Administration [Electronic resources] نسخه متنی

1.2 What Is LDAP?

The best
place to begin when explaining LDAP is to examine how it got its
name. Let's start at the beginning. The latest
incarnation of LDAP (Version 3) is defined in a set of nine documents
outlined in RFC
3377. This list includes:

RFC 2251-2256

The original core set of LDAPv3 RFCs

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"

1.2.1 Lightweight

Why is LDAP considered lightweight? Lightweight compared to
what? (As we look at LDAP in more detail, you'll
certainly be asking how something this complex could ever be
considered lightweight.) To answer these questions, it is necessary
to look at LDAP's origins. The roots of LDAP are
closely tied to the X.500 directory service; LDAP was originally
designed as a lighter desktop protocol used to gateway requests to
X.500 servers. X.500 is actually a set of standards; anything
approaching thorough coverage of X.500 is beyond the scope of this
book.^[2]

^[2] Understanding X.500The
Directory, by David W. Chadwick, provides a good
explanation of X.500 directories. While the book
itself is out of print, an HTML version of it can be accessed from
http://www.salford.ac.uk/its024/X500.

X.500 earned the title
"heavyweight." It required the
client and server to communicate using the Open
Systems Interface (OSI) protocol stack. This seven-layered stack was
a good academic exercise in designing a network protocol suite, but
when compared to the TCP/IP protocol suite, it is akin to traveling
the European train system with four fully loaded
footlockers.^[3]

^[3] For a quick, general comparison of the
OSI model and the TCP/IP protocol stack,
see Computer Networks, by Andrew S. Tannenbaum
(Prentice Hall).

LDAP is lightweight in comparison because it uses low overhead
messages that are mapped directly onto the TCP layer (port 389 is the
default) of the TCP/IP protocol stack.^[4] Because X.500 was an application layer protocol (in terms
of the OSI model), it carried far more baggage, as network headers
were wrapped around the packet at each layer before it was finally
transmitted on the network (see Figure 1-1).

^[4] A
connectionless version of LDAP that provided access via UDP was
defined by an Internet-Draft produced by the LDAP Extension Working
Group of the IETF. However, the current draft expired in November,
2001. You can access the group's web site at
http://www.ietf.org/html.charters/ldapext-charterl.

Figure 1-1. X.500 over OSI versus LDAP over TCP/IP

LDAP is also considered lightweight because it omits many X.500
operations that are rarely used. LDAPv3 has only nine core operations
and provides a simpler model for programmers and administrators.
Providing a smaller and simpler set of operations allows developers
to focus on the semantics of their programs without having to
understand rarely used features of the protocol. In this way, LDAP
designers hoped to increase adoption by providing easier application
development.

1.2.2 Directory

Network directory services are nothing new; we're
all familiar with the rise of DNS. However, a directory service is
often confused with a database. It is easy to understand why.
Directory services and databases share a number of important
characteristics, such as fast searches and an extendable schema. They
differ in that a directory is designed to be read much more than it
is written; in contrast, a database assumes that read and write
operations occur with roughly the same frequency. The assumption that
a directory is read often but written rarely means that certain
features that are essential to a database, such as support for
transactions and write locks, are not essential for a directory
service such as LDAP.

At this point, it's important to make the
distinction between LDAP and the backend used to store the
persistent data. Remember that LDAP is just a protocol;
we'll discuss what that means shortly, but
essentially, it's a set of messages for accessing
certain kinds of data. The protocol doesn't say
anything about where the data is stored. A software vendor
implementing an LDAP server is free to use whatever backend it
desires, ranging from flat text files on one extreme to highly
scalable, indexed relational databases on the other. So when I say
that LDAP doesn't have support for transactions and
other features of databases, I mean that the protocol
doesn't have the messages that you would need to
take advantage of these features (remember, it's
lightweight) and doesn't require that the backend
data store provide these features.

The point is that the client will never (and should never) see or
even know about the backend storage mechanism (see Figure 1-2). For this reason, LDAP-compliant clients
written by vendor A should interoperate with an LDAP-compliant server
written by vendor Z. Standards can be a wonderful thing when
followed.

Figure 1-2. Relationship between an LDAP client, LDAP server, and data storage facility

It has been suggested that an LDAP server
could be used as backend storage for a web server. All HTML and
graphic files would be stored within the directory and could be
queried by mutiple web servers. After all, a web server typically
only reads files and sends them to clients; the files themselves
change infrequently. While it's certainly possible
to implement a web server that uses LDAP to access its backend
storage, a special type of directory already exists that is better
suited to meet the needs of serving files, namely a filesystem. So,
for example, while an LDAP directory might not be a good location for
storing spooled files in transit to a printer, using it to store
printer configuration settings (e.g.,
/etc/printcap) shared among clients would be a
big win.

This brings up two good points about the intended function of
LDAP:

LDAP is not a generalized replacement for specialized directories
such as filesystems or DNS.




While storing certain types of binary information (e.g., JPEG photos)
in directories can be useful, LDAP is not intended for storing
arbitrary "blobs" (Binary Lumps of
Bits).

What about storing individual application settings for roaming users
on an LDAP server? It is a judgment call whether this is better
served by a filesystem or a directory. For example, it is possible to
store basic application settings for Netscape Communicator in LDAP.
Such things as an address book, a bookmarks file, and personal
preference settings are certainly appropriate for storage in a
directory. However, using your directory as a location for browser
cache files would violate rule #2.

1.2.3 Access Protocol

All of this talk of directory services makes it is easy to forget
that LDAP is a protocol. It is not uncommon to hear someone refer to
an LDAP server or LDAP tree. I have done so and will continue to do
so. LDAP does provide a treelike view of data, and it is this
treelike view to which people refer when speaking of an LDAP server.

This introduction won't go into the specifics of the
actual protocol. It is enough to think of LDAP as the message-based,
client/server protocol defined in RFC 2251. LDAP is asynchronous (although
many development kits provide both blocking and nonblocking APIs),
meaning that a client may issue multiple requests and that responses
to those requests may arrive in an order different from that in which
they were issued. Notice in Figure 1-3 that the
client sends Requests 1 and 2 prior to receiving a response, and the
response to Request 3 is returned before the response to Request 2.

Figure 1-3. LDAP requests and responses

More aspects of programming with LDAP operations will be covered in
Chapter 10.