LDAP: Use as Directed By Tim Howes, Netscape , Data.com Feb 1, 1999 (12:00 AM) URL: http://www.networkmagazine.com/article/DCM20000502S0039 When it comes to LDAP, I'm not exactly an impartial observer. As co-author of the lightweight directory access protocol, I'm more than marginally interested in the claims and counterclaims being made for it. And I've noticed something surprising: LDAP is often misunderstood by both proponents and detractors. It's time to set the record straight. Directory services are fast becoming the key to the enterprise, allowing applications to locate the resources they need and enabling net managers to authenticate end-users. Corporate networkers need to be clear about what LDAP is capable of, where it's headed, and what it was never intended to do. Let's start with that last item. LDAP isn't a replacement for relational databases (and never will be). It's not a substitute for a file system. It wasn't built to knock DNS (domain name server) out of the ring. LDAP began life as a low-cost, PC-based front-end for accessing X.500 directories. When the ISO standard proved too cumbersome and overhead-intensive to be widely adopted, LDAP emerged to fill the gap, expanding its original role. The IETF (Internet Engineering Task Force) spec rapidly became the solution of choice for all types of directory services applications on IP nets. LDAP apps can be loosely grouped into three categories: those that locate network users and resources, those that manage them, and those that authenticate and secure them. Net managers who want to put the protocol to work need to dig deeper, coming to terms with standard components and features (including the directory replication and access control services still under development). LDAP can save companies time and money. It can help net managers keep pace with the rising demand for directory services. New apps appear every day. But there are limits to what the protocol can do for distributed computing. It can't store all the types of information that network applications need. Knowing the difference between LDAP facts and fiction is the only way to avoid potential pitfalls. LDAP Limitations The place to start our LDAP evaluation is with what it can't do. First, the protocol cannot and will not supplant relational databases. It lacks the heavy update, transaction processing, and reporting capabilities of these products. Nor does it offer two-phase commits, true relational structure, or a relational query language like SQL. Using LDAP to implement an airline reservation system, for instance, would be a serious mistake. Second, it's not reasonable to expect LDAP to serve as a file system. Its information model is based on simple pairings of attributes and values. Thus, it's not well suited to the BLOB (binary large object) data that's managed by typical file systems. It's also not optimized for write performance and is unable to furnish byte-range access to values, both critical features of a file system. Finally, it doesn't have the locking semantics needed to read- and write-protect files. Third, LDAP is not a stand-in for DNS, which may well be the world's largest distributed database. Although LDAP's abilities are more or less a superset of DNS's-whose biggest job is translating names like home.netscape.com into IP addresses-there's a very good argument for leaving DNS alone: It's working just fine. Also, LDAP can't contend with the connectionless transport that DNS usually runs over. Ultimately, LDAP may have a role in managing and augmenting the information found in DNS. For example, it could link contact information to host information, but it cannot take the place of the DNS database itself. Looking into LDAP So what is LDAP and what can it do for network architects? The current spec comprises eight features and functions for defining or performing directory-related tasks like storage and retrieval (see Figure 1). Information model organized according to collections of attributes and values, known as entries, this model defines what kinds of data can be stored and how that data behaves. For example, a directory entry representing a person named Babs Jensen might have an attribute called sn (surname) with a value of "Jensen." The information model, inherited almost unchanged from X.500, is extensible: Almost any kind of new information can be added to a directory. LDAP schema Defines the actual data elements that can be stored in a particular server and how they relate to real-world objects. Collections of values and attributes-representing objects such as countries, organizations, people, and groups-are defined in the standard, and individual servers can define new schema elements as well. Naming model Specifies how information is organized and referenced. LDAP names are hierarchical; individual names are composed of attributes and values from the corresponding entry. The top entry typically represents a domain name, company, state, or organization. Entries for subdomains, branch offices or departments come next, often followed by common name (cn) entries for individuals. Like the LDAP information model, the naming model derives directly from X.500. Unlike X.500, LDAP does not constrain the format of the namespace; it allows a variety of flexible schemes. Security model Spells out how information is secured against unauthorized access. Extensible authentication allows clients and servers to prove their identity to one another. Confidentiality and integrity also can be implemented, safeguarding the privacy of information and protecting against active attacks like connection hijacking. LDAP functional model Determines how clients access and update information in an LDAP directory, as well as how data can be manipulated. LDAP offers nine basic functional operations: add, delete, modify, bind, unbind, search, compare, modify DN (distinguished name), and abandon. Add, delete, and modify govern changes to directory entries. Bind and unbind enable and terminate the exchange of authentication information between LDAP clients and server, granting or denying end-users access to specific directories. Search locates specific users or services in the directory tree. Compare allows client apps to test the accuracy of specific values or information using entries in the LDAP directory. Modify DN makes it possible to change the name of an entry. Abandon allows a client application to tell the directory server to drop an operation in progress. LDAP protocol Defines how all of the preceding models and functions map onto TCP/IP. The protocol specifies the interaction between clients and servers and determines how LDAP requests and responses are "formed" (how the bits look on the wire). For example, the LDAP protocol stipulates that each LDAP request is carried in a common message format and that entries contained in response to a search request are transported in separate messages, thus allowing the streaming of large result sets. Application program interface (API) Details how software programs access the directory, supplying a standard set of function calls and definitions. This API is widely used on major development platforms running C/C++, Java, Javascript, and Perl (among others). LDAP data interchange format (LDIF) Provides a simple text format for representing entries and changes to those entries. This ability helps synchronize LDAP directories with X.500 and proprietary directories (or a company's HR directory, which is often a source of useful information). LDIF and the LDAP API, along with scripting tools like Perl, make it easy to write automated tools that update directories. Those are the basic LDAP building blocks. As with any technology, however, evolution requires updates and modifications. The IETF currently has two working groups tackling just that. The LDAP Directory Update (LDUP) working group is hammering out a standard replication service that will facilitate directory replication. The LDAP Extensions working group is charged with creating standard extensions to LDAP version 3, LDAP access control, and the LDAP APIs. Other groups have been formed to tackle deployment and schema issues. LDAP Looking Back LDAP itself can be confusing for newcomers. Another mystery can be the relationship between LDAP and X.500. This was fairly clear in the beginning. LDAP was a simpler way for clients to access X.500 directories; it furnished a subset of X.500's functionality. But as LDAP has matured, it has added features not found in X.500 and moved into areas not addressed by the older spec, like APIs and data formats. A little history is in order here. X.500 was meant to serve as a universal, standards-based directory service. But it proved overly complicated and ran only on high-powered Unix machines, while most would-be users had PC-class platforms. More Links The logical alternative was to create a cheaper, easier way for small, TCP/ IP-based machines to access the X.500 directory. The first such protocols were Dixie specified in RFC 1249 (request for comments 1249) and DAS, the directory assistance service (RFC 1202). Clients spoke Dixie or DAS to a gateway server, which translated TCP/IP requests into corresponding X.500 operations. In 1992, the IETF's OSI Directory Services working group set out to specify a standard version of Dixie/DAS that would work with all versions of X.500. The result was LDAP, which was approved as a proposed Internet standard in 1993 and introduced as a draft standard in 1995. Eventually, lack of support for X.500 and OSI prompted LDAP developers to create slapd, a standalone LDAP server. The idea behind slapd was to enable LDAP directories (servers) to grow from the ground up, learning about clients and network resources as they are needed, without being tied to X.500's top-down scheme. LDAP version 3, as it is known, was approved as a proposed Internet standard in December 1997. LDAP Adapts Today, LDAP and X.500 remain largely compatible. Virtually all X.500 directory access still occurs via LDAP, and both use the same basic information and naming models. Both directories look very similar, but there are a few key differences. For example, LDAP offers security features not available in X.500, such as confidentiality. These result from the fact that LDAP uses the extensible simple authentication and security layer (SASL) and runs over transport layer security (TLS, also known as secure sockets layer, or SSL). LDAP also supports multiple directory services protocols and metadirectories (overarching views of multiple directories), something X.500 can't match. For example, LDAP allows URLs (universal resource locators) to be used in directory lookups. What's more, the protocol specifies standard APIs and data formats, both of which are missing from X.500. But it's not all advantage LDAP-at least on paper. X.500 is still out ahead when it comes to standard server-to-server protocols. It defines the optional directory information shadowing protocol (DISP) for replication, directory system protocol (DSP) for chaining requests between servers, and directory operational binding protocol (DOP) for negotiating things like replication agreements between servers. X.500 also specifies a standard access control scheme, basic access control (BAC). LDAP work is ongoing on replication and access control, with specs expected within a year. LDAP Goes Long LDAP describes what a directory looks like and how it acts from a client's point of view. But the directory itself can be distributed across many servers. Each of these can maintain a version of the entire directory, which is replicated periodically so that all servers know where data is to be found. (LDAP products do offer replication. It's just that a standard way of handling this chore has yet to be defined.) An LDAP server that receives a request from an application takes responsibility for it. It may pass the request to other servers until it can be fulfilled, or it may refer the client to other servers. Replication of directory data is also required for high availability networks. Consider a directory supplying the authentication database for a business-critical Web application. If the directory is down, the Web application can't authenticate users, which means lost business. One way to reduce the risk is to make two or more copies of the directory data, each served by a separate machine. If one copy becomes inaccessible, the other can take over. Right now, though, there is no standard way to replicate servers. Some directories handle replication via LDAP itself. Some rely on the capabilities of the underlying data store. Others use X.500. The catch is that none of schemes allows true multivendor interoperability. The problem, in part, can be traced to loopholes in earlier directory standards. For example, X.500 makes replication entirely optional. Developers are free to implement all, none, or selected pieces. Once the LDUP working group has completed its efforts, however, multivendor replication will be possible, just as it's now possible to access different vendors' directories using LDAP. Standard access control is also MIA for the time being. LDAP currently offers a standard way for servers and clients to authenticate each other (via the bind operation). But there's no standard way to use this information to control access to specific directory data. Thus, there's no standard way for LDAP to ensure that each database replica follows the same rules for access control. This isn't to say that LDAP completely lacks access control. As with replication, different LDAP directories take different tacks. Some vendors implement proprietary access control schemes. Others rely on the capabilities of the underlying database or on a system like X.500. The LDAP schema itself also needs more work. LDAP defines basic elements for a number of fundamental applications (such as white pages, e-mail, and user and group management). But as directories become increasingly prevalent and the number of applications relying on them increases, there is a corresponding need for new schema. The Directory Enabled Networks (DEN) initiative, supported by numerous network software vendors, is a promising start. DEN is an effort to define models and schema for network-level devices and services, such as routers, switches, and VPNs (virtual private networks). Through DEN, these devices and services use LDAP to implement authentication and policy services, allowing guaranteed end-to-end quality of service (QOS) and other features. LDAP At Work While it's not possible to describe all of LDAP's uses, a representative sampling conveys an idea of its versatility. LDAP location apps are becoming widespread. In this capacity, LDAP directories play the role of network-accessible database, organizing and indexing information. For example, the address book in most e-mail clients employs LDAP to locate addresses. Every time a user browses the member directory at a Web site, or a consumer scans the bestseller lists of an online bookstore, an LDAP directory is probably working behind the scenes. A simple but compelling example of LDAP's value as resource locator is the online corporate phone directory. Because it can be updated regularly-often by users themselves-an online phone directory increases the accuracy of available information. And because it can eliminate costly printing, an online phone directory can save a large corporation thousands of dollars a year. LDAP directories and operating systems are melding to create intelligent environments that can locate network resources automatically. One example is the Active Directory component of Windows NT from Microsoft Corp. (Redmond, Wash.). Hewlett-Packard Co. (HP, Palo Alto, Calif.) is integrating an LDAP directory in the next release of HP-UX; Sun Microsystems Inc. (Mountain View, Calif.) is doing the same with Solaris, and Silicon Graphics Inc. (Mountain View) and Compaq Computer Corp. (Houston) are following suit with Irix and Digital Unix. In this new role as operating system add-on, LDAP furnishes a way to locate printers, file servers, and other network services. LDAP makes these services standard, more accessible, and in many cases, more powerful and flexible. LDAP also is starting to play a critical role in network management, where it can be a godsend to system administrators. Without LDAP, corporate networkers have to maintain duplicate user information in dozens of application-specific directories across the network. With LDAP, it's possible to centralize this information in a single directory accessed by all applications (see Figure 2). Of course, replacing legacy applications with LDAP-enabled ones takes time, but big changes are already under way. Manufacturing companies with many suppliers or branch offices can use LDAP directories to deploy Web-based applications that integrate sales, inventory, and delivery processes. One repository-which can even be shared among different companies-eliminates the need for separate directories and complicated synchronization. Of course, centralized directories aren't always efficient. For instance, companies don't want to have to update an entire directory infrastructure every time a new person is hired or fired from a branch office. Instead, LDAP allows net managers to "delegate" the maintenance of this information to distributed local directory managers. LDAP also has an important role to play in tighter security, with the directory acting as gatekeeper and deciding who has access to what. In this capacity, LDAP performs two critical jobs. First, it serves as an authentication database. Second, once the identity of a user has been established, it controls access to resources, applications, and services (using stored policies and other information). LDAP also permits corporate networkers to use their directories to implement PKI (public key infrastructure) security. From the user's point of view, LDAP provides the directory in which the certificates of other users are found, enabling secure communication. From the administrator's point of view, LDAP directories are the way in which certificates can be centrally deployed and managed. Tim Howes is chief technology officer, server product division, at Netscape Communications Corp. (Mountain View, Calif.). He is co-author of LDAP and LDAP API, co-chair of the IETF LDAP Extensions working group, and member of the Internet Architecture Board.