Lightweight Directory Access Protocol (LDAP)
This chapter is from the book
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.