LDAP directories are commonplace
today and can be found in many business environments. UNIX applications
in particular make wide use of the LDAP standard for directories. Along
with this proliferation of LDAP directory structures comes a need to
synchronize the information contained within them to an Exchange Server
2010 environment. The Enterprise version of FIM contains MAs that
support synchronization to LDAP directories. Consequently, a good
understanding of LDAP concepts is required before syncing between the
environments.
Understanding LDAP
from a Historical Perspective
To understand LDAP better,
it is useful to consider the X.500 and Directory Access Protocol (DAP)
from which it is derived. 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 email applications. The 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 services 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, city, and organization. These objects can be files (as in a file
system directory listing), network entities (as in a network naming
service such as NDS), or other types of entities.
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 Asynchronous Transfer Mode (ATM) or Fiber Distributed
Data Interface (FDDI)—and media—such as fiber-optic cable.
Lightweight
protocols also use various measures and refinements to streamline and
speed up transmissions, such as using a fixed header and trailer size to
save the overhead of transmitting a destination address with each
packet.
LDAP is a subset of the X.500 protocol. LDAP
clients are, therefore, smaller, faster, and easier to implement than
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 server platform hosting the
directory.
Active Directory is not a
pure 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.
Active Directory
supports access via LDAP 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 uniform resource
locator (URL) names the server holding Active Directory services and the
attributed name of the object—for example:
LDAP://Server1.companyabc.com/CN=JDoe,OU=Users,DC=companyabc,DC=com
By combining the best of the
DNS and X.500 naming standards, LDAP, other key protocols, and a rich
set of APIs, Active Directory enables a single point of administration
for all resources, including files, peripheral devices, host
connections, databases, web access, users, other arbitrary objects,
services, and network resources.
Understanding How
LDAP Works
LDAP directory
service is based on a client/server model. One or more LDAP servers
contain the data making up the LDAP directory tree. An LDAP client
connects to an LDAP server and asks it a question. The server responds
with the answer or with a pointer to where the client can get more
information (typically, another LDAP server). No matter which LDAP
server a client connects to, it sees the same view of the directory; a
name presented to one LDAP server references the same entry it would at
another LDAP server. This is an important feature of a global directory
service such as LDAP.
Outlining the
Differences Between LDAP2 and LDAP3 Implementations
LDAP3 defines a
number of improvements that enable a more efficient implementation of
the Internet directory user agent access model. These changes include
the following:
Use of UTF-8 for
all text string attributes to support extended character sets
Operational
attributes that the directory maintains for its own use—for example, to
log the date and time when another attribute has been modified
Referrals enabling a server to
direct a client to another server that might have the data that the
client requested
Schema publishing with
the directory, enabling a client to discover the object classes and
attributes that a server supports
Extended searching operations to enable paging
and sorting of results, and clientdefined searching and sorting controls
Stronger security through a
Simple Authentication and Security Layer (SASL) based authentication
mechanism
Extended
operations, providing additional features without changing the protocol
version
LDAP3 is compatible with
LDAP2. An LDAP2 client can connect to an LDAP3 server (this is a
requirement of an LDAP3 server). However, an LDAP3 server can choose not
to talk to an LDAP2 client if LDAP3 features are critical to its
application.
Note
LDAP was built on
Internet-defined standards and is composed of the following Request for
Comments (RFCs):
RFC 2251— Lightweight Directory Access Protocol (v3)
RFC 2255— The LDAP
URL format
RFC
2256— A summary of the X.500(96) user schema
for use with LDAP3
RFC 2253—
Lightweight Directory Access Protocol (v3): UTF-8 string representation
of distinguished names
RFC 2254— The
string representation of LDAP search filters
