Managing Identity Information Between LDAP Directories and Exchange Server 2003

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 2003 environment. The Enterprise version of MIIS 2003 contains MAs that support synchronization to LDAP directories. Consequently, a good understanding of LDAP concepts is required before synching 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 may 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 ATM or 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 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:// Server1.fastportfolio.com/CN=LSomi, ,OU=Users,O=fastportfolio,C=US

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 enables 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.

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

LDAP 3 defines a number of improvements that enable a more efficient implementation of the Internet directory user agent access model. These changes include

• 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 client-defined searching and sorting controls

• Stronger security through an SASL-based authentication mechanism

• Extended operations, providing additional features without changing the protocol version

LDAP 3 is compatible with LDAP 2. An LDAP 2 client can connect to an LDAP 3 server (this is a requirement of an LDAP 3 server). However, an LDAP 3 server can choose not to talk to an LDAP 2 client if LDAP 3 features are critical to its application.