February 28, 2021
Hot Topics:

Introduction to LDAP (Lightweight Directory Access Protocol)

  • By Manning Publications Co.
  • Send Email »
  • More Articles »


LDAP is an access protocol that shares data using a particular information model. The data to which it provides access may reside in a database, in memory, or just about anywhere else the LDAP server may access. It is important that the data be presented to an LDAP client in a way that conforms to LDAP's information model.

LDAP is being used for an increasing number of applications. Most of these applications are appropriate—but some aren't. To get a better idea what LDAP should and shouldn't be used for, we begin this section with an overview of LDAP limitations that make it a bad choice for certain types of applications.

LDAP is not:

  • A general replacement for relational databases
  • A file system for very large objects
  • Optimal for very dynamic objects
  • Useful without applications

1.2.1 LDAP is not a relational database

LDAP is not a relational database and does not provide protocol-level support for relational integrity, transactions, or other features found in an RDBMS. Applications that require rollback when any one of multiple operations fails cannot be implemented with the current version of LDAP, although some vendors implement such functionality when managing their underlying datafiles. LDAP breaks a number of database normalization rules. For example, 1NR states that fields with repeating values must be placed into separate tables; instead, LDAP supports multi-valued data fields.

Some LDAP server vendors proclaim that directories are somehow faster than relational databases. In some cases, this is true. In other cases, databases are both faster and more scalable. Nothing inherent in the LDAP protocol makes it in any way faster than other data access mechanisms, such as Open Database Connectivity (ODBC). Everything depends on how the underlying data store is tuned.

LDAP lacks features found in relational databases even in cases where LDAP sits on top of a relational data store, as is true with Oracle and IBM directory server products. The LDAP protocol currently has no standard for transmitting the type of information necessary to take advantage of the powerful relational and transactional capabilities present in the underlying data store.

1.2.2 LDAP is not a file system for very large objects

LDAP provides a hierarchical way of naming information that looks remarkably like that found in most file systems. Many people see this aspect of LDAP as an indication that it might be a great way to centrally store files to make them accessible over a network.

In fact, LDAP is not a great way to do network file sharing. Although it allows information (including binary data) to be transmitted and stored, it does not have the locking, seeking, and advanced features found in most modern file-sharing protocols. Figure 1.2 shows some of the disadvantages of using LDAP in this manner.

Figure 1.2
LDAP is not a network file system. Here you see that if you stored a large file using LDAP, clients would need to read the entire file via LDAP rather than page through the applicable sections. If either client died in midtransfer, it would need to start again from scratch.

The Network File System (NFS) and similar file-sharing protocols have this advanced functionality and are well-tested and accepted for use on local intranets. Web protocols such as the HTTP and File Transfer Protocol (FTP) are more appropriate when you're providing Internet access to data on local file systems.

In a similar vein, LDAP is often only marginally useful to store serialized objects, large structured documents (such as XML), and similar types of data in the directory. Because the LDAP server may not know how to parse these blobs of data, it will not be able to search on attributes within them.

For example, if you store XML documents in the directory, you will not be able to search for all XML documents in the directory that implement a particular document type unless you also store the document's type in the directory. Such a process involves duplicating information already stored in the XML document.

Without storing this metadata, the XML document is an opaque object that can only be stored and retrieved in full. By contrast, a good file-based XML parser has the ability to seek through parts of the XML document and retrieve or manipulate only those sections that are pertinent to the current operation. This situation may be changing as LDAP vendors become increasingly XML savvy and begin supporting such functionality as XPath searching.

Note that because the LDAP protocol is separate from the data to which it provides access, it is possible for a particular LDAP server to be extended to handle particular types of objects more intelligently. For example, the server might include an XML parser that indexes XML documents for easier search and retrieval with LDAP. We'll explore this process briefly in the context of attribute syntax and matching rules in chapter 2.

1.2.3 LDAP is not optimal for very dynamic objects

Generally speaking, LDAP is not the place to store very dynamic information. For example, there are a number of reasons it would be unwise to write extensive audit logs to an LDAP entry each time a user accesses a system.

First, most LDAP servers optimize for search performance at considerable cost in write performance. Updating a single attribute in some LDAP environments generally takes a longer time than comparable updates to a well-designed database.

Second, even with high write performance, LDAP as a protocol does not have facilities to ensure that a set of transactions will happen in the right order. This complicates even the simplest updates to dynamic information involving multiple applications or threads. Even a simple counter can get corrupted when two applications try to update it simultaneously.

Finally, even if a particular server supports tuning for updates and adds proprietary protocol extensions to support better locking that allows for better multiapplication updates, using these special features may avoid a major benefit of LDAP. This benefit is the ability of application developers to use LDAP without having to take note of the server implementation being used.

1.2.4 LDAP is not useful without applications

LDAP lacks an SQL-like general reporting language of the kind found with most general-purpose databases. Such reporting languages can often be used to generate sophisticated reports from a database. Because directories are used for more generally useful information, such as account information usable by many applications, this lack of report generation support is insignificant.

Lack of generalized report generation makes it even more important that LDAP directories be built around the notion that applications will be using them. In addition, it's important that LDAP directory services be designed and deployed with full cooperation from the application developers who will use the service.

Although it lacks a general report-generation language, LDAP offers a number of powerful APIs. Many of these APIs are based on well-documented industry standards whose wide acceptance has been one of the strongest drivers of early LDAP adoption. Unlike databases, directories using LDAP have a wire protocol that can be used without using special vendor drivers, making directories important for information that can benefit many applications that otherwise have nothing in common.

Thanks to the ease with which these APIs can be used, a large number of applications now provide native support for LDAP where it makes sense. You can find some of these LDAP-enabled applications, such as those providing shared address book or white pages functionality, on the Internet and in nearly all modern email and web browser software.

LDAP is now mature technology used by a wide variety of applications for many critical purposes. These applications include everything from authentication, authorization, and management of application and operating system users to routing of billions of email messages around the world. New applications are developed every day that ensure that LDAP's importance will continue to grow.


As we just discussed, successful directory services depend on application support. In this section we begin to examine the types of applications that normally leverage LDAP-enabled directories.

1.3.1 White pages

One of the first uses of enterprise directories was to provide electronic shared addressbooks, called white pages (see figure 1.3). LDAP has long been used to provide accessto information that enables white pages functionality. In fact, white pages applica-tionsare the most widely deployed and visible LDAP-enabled applications.

Click here for a larger image.

Figure 1.3
This screen from the Outlook Express email client is an example of a white pages application.

Both Netscape and Internet Explorer have built-in support for searching LDAP directories and presenting the results in the form of an address book. Most email applications released in the past few years provide this same functionality, although some still support their own proprietary standards to remain compatible with legacy workgroup-oriented directories. Figure 1.4 shows how such a client might talk to a directory to retrieve this information.

Click here for a larger image.

Figure 1.4
An address book client talks directly to an LDAP server.

A quick chat with most corporate intranet webmasters would reveal that the most frequently accessed application on an intranet is usually a corporate contact database. Everyone from the mailroom clerk to the CEO needs to be able to locate their peers; therefore, it is the simplest application available to demonstrate the power and simplicity provided by directory access.

Web-based white pages applications are useful for extending LDAP information to points beyond an intranet environment when firewalls or a lack of installed clients prevent pure LDAP communication. Figure 1.5 shows how a web server might act as a gateway for white pages requests from an end-user's web browser.

Click here for a larger image.

Figure 1.5
The same directory shown in figure 1.4, with a web application rather than the end-user's client communicating via LDAP.

Most people already have an LDAP-enabled browser or email client, or can access white pages via a web interface. This simplifies deployment and allows for more widespread access.

In fact, creating an application that can search for information in LDAP is not particularly difficult. The following is a full code listing in Java using the Java Naming and Directory Interface (JNDIJ) for a program that can search for information in an LDAP-enabled directory service:

import javax.naming.directory.*;import javax.naming.*;import java.util.Vector;import java.util.Enumeration;import java.util.Properties;public class SearchLDAP {  public static void main(String[] args) {    String base = "";    String filter = "(objectclass=*)";    Properties env = new Properties();    env.put(DirContext.INITIAL_CONTEXT_FACTORY,            "com.sun.jndi.ldap.LdapCtxFactory");    env.put(DirContext.PROVIDER_URL,"ldap://localhost:389");    try {        DirContext dc = new InitialDirContext(env);        SearchControls sc = new SearchControls();        sc.setSearchScope(SearchControls.OBJECT_SCOPE);        NamingEnumeration ne = null;        ne = dc.search(base, filter, sc);        while (ne.hasMore()) {          SearchResult sr = (SearchResult) ne.next();          System.out.println(sr.toString()+"\n");          dc.close();       }    } catch (NamingException nex) {        System.err.println("Error: " + nex.getMessage());    }  }}

The results of this code are not pretty, but they show how easy it is to tie LDAP into a new or existing application for white pages or other lookup functionality.

Another benefit of using a web-based white pages application is that whereas most browsers and email clients enable LDAP searches, a web-based application can offer a point of self-administration for contact information. Information such as phone numbers and mailing addresses can be managed using a simple interface that is integrated with the search tools. This approach makes it easy for someone to change his or her information quickly when necessary.

Page 2 of 6

This article was originally published on April 25, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date