If you're managing a major directory server, you need to understand LDAP. Since LDAP is both a protocol and an API, there is much confusion over what LDAP does. The following sample chapter clarifies the nuances.

This chapter is from the book

This chapter is from the book

Overview

Lightweight Directory Access Protocol (LDAP) is the core communication and
access protocol behind all major directory server products today, including
Active Directory. LDAP was developed at the University of Michigan in the early
1990s. The first specification was submitted as RFC 1487 in 1993 and the most
recent, LDAP v3, in 1997 as RFC 2252. LDAP is a protocol, but is also associated
with an application programming interface (API), which is defined in the
informational RFC 1823. Since LDAP is both a protocol and an API, there is much
confusion over what LDAP does. The following sections clarify the nuances.

LDAP as a Protocol

As its name implies, LDAP was initially intended to be a lightweight
protocol. LDAP was developed as an alternative to the x.500 Directory Access
Protocol (DAP). DAP is based on the OSI model and as such incorporates many of
the complexities and inefficiencies that come with OSI. The LDAP protocol
defines the transport and format of messages between a client and an LDAP
enabled server or gateway. Initially, LDAP was created to work over TCP, but
later Connectionless LDAP (CLDAP) was defined in RFC 1789 to work over UDP for
implementations that did not want to incur the overhead of TCP.

LDAP was designed to be simple yet extensible so additional features could be
added later while maintaining backward compatibility. LDAP uses a mechanism
called controls, which will be discussed later in the chapter, to define
extensions to the protocol without actually modifying the protocol. Server-side
sorting, paging, and tree delete are examples of enhancements that have been
made to LDAP by the use of controls. New controls generally go through the RFC
process to gain industry acceptance before implementation, but some vendors,
such as Microsoft, have implemented their own controls for use specifically
within their directory products. Appendix C covers the controls implemented in
Active Directory.

LDAP provides read as well as write access to a directory. A typical
directory, such as a phone book, is read much more frequently than it is
written. For that reason, LDAP was optimized for reading rather than
writing.

LDAP is based on the X.500 data model, which is highly extensible and can be
dynamically manipulated. It is also hierarchical, unlike traditional databases,
so relationships and dependencies among data can be easily modeled and
controlled.

LDAP as an API

LDAP is associated with a C API defined in RFC 1823. This is very uncommon
among protocol standards and is one reason why LDAP thrived early on. It is
important to note that RFC 1823 is not a standard or proposed standard, but only
informational. Other APIs that have been written do not conform to the C-style
API. Some examples include the Perl-based Net::LDAP modules and the Java Naming
and Directory Interface (JNDI), both of which are object-oriented.

Most LDAP APIs are composed of three primary groups of functions. Table 3.1
illustrates the grouping along with some of the C-style LDAP functions that are
associated with them.

Table 3.1 Common LDAP Functions

Purpose

C-Style LDAP Functions

Connecting, disconnecting, authenticating

ldap_connect(), ldap_open(), and ldap_bind(),
ldap_unbind()

Searching and retrieving entries

ldap_search(), ldap_first_entry(),
ldap_next_entry()

Manipulating entries

ldap_add, ldap_modify(), ldap_modrdn(),
ldap_delete(), ldap_compare()

What LDAP Is Not

While LDAP is very good at some things, such as being very efficient for
reading data and being more easily distributable than a database, some
limitations have caused problems for implementers. The first warning for anyone
new to LDAP is that an LDAP directory should not be treated like a database.
There is no transactional capability within LDAP, which means it is not possible
to roll back changes or to make a series of changes in a single
transaction as in a traditional database. This makes LDAP directories a
bad choice for systems that depend on transaction or order processing, such as
bank and airline systems.

Lack of a standard replication mechanism is one of the biggest complaints
from enterprise deployers of LDAP. Most LDAP vendors have been required to
develop their own methodology to replicate data among LDAP servers. Many of the
early LDAP servers are only capable of a single master architecture. That means
one server is designated as the master and contains a writable copy of the
directory contents, and the other servers are subordinate or secondary and have
read-only copies. When the master server is updated, it replicates the change to
the other subordinate servers. This model is much simpler and easier to maintain
than a multimaster architecture, but it is also much more limiting especially
for global deployments. Active Directory is one of the first directories to
support true multimaster replication where any number of servers can be updated.
However, having multimaster capabilities does not come without its pitfalls. As
you will read in the Chapter 9, "Site Topology and Replication,"
Active Directory replication is one of the most labor-intensive and troublesome
areas within Active Directory.

Synchronization of disparate directories is another issue for most companies
because of the need to support multiple directories within the enterprise. Most
directories available today perform only one of the major directory functions
very well. For example, Netscape iPlanet is known for having the best enterprise
or application directory, whereas Microsoft and Novell have the best network
operating system (NOS) directories. Since many companies have more than one
directory, there is a need to synchronize some of the data between them.
Currently, there is no standard way to do this. Since a synchronization
mechanism was not included in the LDAP specification, most LDAP vendors have
been reluctant to work together to form a standard. As a result, there has been
a proliferation of metadirectory products. Metadirectories facilitate the
synchronization of data between disparate directories and databases based on
business logic. The primary problem with implementing metadirectories is the
complexity involved in configuring and maintaining the necessary business logic
to keep the various databases and directories in sync.