A System Administrator's View of LDAP

Bruce Markey is a Senior Systems Administrator in the IntranetServers group at Netscape Communications Corporation.

Recently, here in Netscape's IS group, we've been using LDAP ("Lightweight Directory Access Protocol") directory services on our internal network. This should not be surprising because Netscape's server products and Netscape Communicator use LDAP for sharing information. Although LDAP will help developers and end-users, systems administrators may reap the greatest benefits from LDAP deployment. However, to reap those benefits, system administrators will want to have a good understanding of what LDAP can and can't accomplish, become familiar with LDAP basics, and then begin to transition to directory-enabled utilities.

Why LDAP?

At a recent BayLISA meeting, LDAP was being correctly described as a system for distributing information like lists of users. A concerned sysadmin was quick to ask, "With all of the user lists that I manage already, why do I want to have another one?" A fair question, I thought, and one that hints at why system administrators should pay close attention to LDAP's development.

LDAP has the potential to replace existing application-specific lists and consolidate information. This means that changes made on an LDAP server will take effect for every directory-enabled application that uses this information. Imagine adding a variety of information about a new user through a single interface once. Immediately, the user will have a UNIX account, NT account, mail address and aliases, membership in departmental mailing lists, access to a restricted Web server, inclusion in job-specific restricted newsgroups, and be included in the company's phone list, mail address book, and meeting calendar system. When a user leaves, access can be disabled for all of these services, again from a single operation.

That sounds wonderful, but at the same time far-fetched. How can we expect operating systems and applications from different vendors to agree on one system for looking up information, and why would LDAP be perceived as the key to making this possible?

First, let's look at what LDAP is and isn't. Developed at the University of Michigan, LDAP is now an Internet standard for directory services that run over TCP/IP. One or more LDAP servers contain the data that make up the LDAP directory tree. An LDAP client connects to an LDAP server and submits a query to request information or submits information to be updated. If access rights for the client are granted, the server responds with an answer or possibly with a referral to another LDAP server where the client can have the query serviced.

An LDAP server is not simply a form of database, but a specialized server for directories. A directory can be distinguished from a general-purpose database by the usage pattern. A directory contains information that is often searched, but rarely modified. Hostnames or usernames, for example, are assigned once and then looked up thousands of times. LDAP servers are tuned for this type of usage, whereas relational databases are much more geared to maintaining data that are constantly changing.

Another difference is that relational databases store information in rows of tables, whereas LDAP uses object-oriented hierarchies of entries. One could think of this hierarchy as being similar to DNS. Because an LDAP directory could hold host name information, it might seem that LDAP could be a replacement for DNS. However, DNS is very specialized, and LDAP was not designed to address the same set of problems for which DNS has been groomed. Still, DNS maintenance can benefit from an LDAP-based strategy.

By designing for this usage pattern, current directory servers with a million or more entries can respond to hundreds of search requests per second from a single server. Replication is also possible, which makes LDAP very scalable.

Reducing load on the authoritative server is not the only reason for using replica servers. As with YP, putting replicas on subnets can avoid network traffic through routers and reduce latency. However, unlike YP, the synchronization scheme features incremental updates that can be pushed immediately to the replicas rather than periodically transferring all of the data. For Netscape's internal mail hubs, we are also experimenting with running replicas on the local host. Although this really isn't necessary, it does allow Netscape Messaging Server to do lookups locally with very little overhead to maintain synchronized data.

LDAP Basics

Before going any further with architecture issues, let's look at how LDAP organizes information. LDAP introduces a lot of new terminology, but the only terms you need to understand to get started are entries, object classes, attributes, and distinguished names.

An LDAP server contains entries. Each entry's type is defined by an object class. Object classes define which attributes are required and other optional attributes that can be associated with an entry of that class. Each entry is uniquely identified by a distinguished name or DN in LDAP parlance. These DNs are organized in a hierarchy.

For example, I am at a company in the United States. The top entry in the hierarchy for my entry has the DN "c=US". This entry is of the object class country. A country entry has one required attribute for c which has the value of US. o=Netscape Communications Corp., "c=US" is the DN for an entry of the object class organization. This requires the attribute o which in this entry is "Netscape Communications Corp." Notice that the parts of the DN are separated by a comma.

At this point, what we have would likely be the BaseDN for this server. A BaseDN defines the top of the namespace that the server is responsible for much like a DNS zone. As we add entries further down the hierarchy, the DNs will become longer. Remembering a long DN is not an issue for end-users because client applications will be doing the searches then displaying the attributes the user needs to see. For most applications, the full DN does not need to be exposed to the end-user.

Now that the groundwork has been laid, let's look at an entry for an individual.

"cn=Bruce Markey, o=Netscape Communications Corp., c=US"

This is of the object class inetOrgPerson, which requires a cn for the common name. It also requires an sn for the surname, which is an example of a required attribute that is not the attribute included in the DN. The inetOrgPerson class also defines about 50 other attributes that can be associated with a person, such as uid, title, manager, phone, pager, email address, and other information you would likely want to associate with a person in an organization that has access to the Internet. It even has attributes for jpegPhoto and audio, which are possible because attributes can be declared to be encoded into different syntaxes, including binary data.

In order to maintain authoritative information, access control needs to be imposed for privileges to read, write, search, or compare. Access control can be done on a subtree, entry, and/or attribute type and granted to individuals, groups, or "self," which allows authenticated users to access their own entries. This allows a great deal of flexibility. For example, you might want to allow only people in a human resources group to change the title or manager attributes, allow administrative assistants to change office location and pager number information for just their department, and allow individuals to modify home phone number, license plate, etc. for their own entry.

More Than a Protocol

Understanding how to maintain the data alone is not enough to put LDAP to use. There are four well-defined pieces of the overall system that simplify implementing LDAP. The LDAP open standard, the API, the LDIF text format for data, and the object class definitions. Let's look at why each of these is important.

LDAP

RFCs 1777 and 1778 define the protocol that enables clients from different developers on any platform to talk to any type of LDAP server. Many vendors have announced support for LDAP. Notables include Netscape, Microsoft, and Novell, each of which already offers directory-enabled servers and clients. The University of Michigan, where LDAP evolved, has source code for its original slapd server and other tools available for download.

API

One of the important factors for LDAP to succeed is that developers should be able make use of information from an LDAP server without having to write and debug a lot of code. A well-defined Application Programming Interface mitigates this problem. You may be familiar with SOCKS and socksifying an application. With LDAP, directory enabling is a very similar process. For a program that could make use of directory information, include the API libraries in the source directory, modify the program's code to call the API functions at the point where the information needs to be looked up, and then recompile. The most recent version of sendmail already includes the API and has options to look up information through LDAP.

LDIF

Another piece of the puzzle that I've found to be remarkably important is the LDIF file format. This ASCII text format is used for exporting and importing data to and from LDAP servers. This not only makes it easy to migrate data from one server to another, but also allows you to write scripts to create LDIF files from other data sources. You can then verify and manipulate the LDIF file before committing the data to the server. Because command line tools like "ldapsearch" return data in LDIF format, you can save some or all of your data to a file, make global changes, then import the new data back into the server.

Object Classes

One other piece that is important to portability is object class definitions. If a client needs some attributes that aren't in the well-known object class definitions, a new object class could be created as an extension of a similar object class. The client could then work with any LDAP server so long as the server has been given this new object class definition.

Transitioning to LDAP

Even with a solid understanding of LDAP concepts, switching to LDAP won't happen instantly. There are two distinct ways to put information to use. One is by using applications that are already directory enabled, and the other is to gateway the information from LDAP into a format used by existing applications.

Here at Netscape, we first used a corporate-wide phonebook that was available through a Web page. This was the beginning of creating an authoritative list of employees on our central Directory Server. Netscape Communicator now includes a window that can do native LDAP searches. Not only can that act as the corporate phonebook, but results can be selected to automatically address email messages.

Once the data are being stored and updated on an LDAP server, other applications can take advantage of this resource.

Many LDAP-based software distributions include command line tools for searching and modifying directory information. This makes it possible to use or manipulate information with simple shell scripts. There are also tools available for programming in Perl, Java, C, etc.

Let's look at UNIX login information as an example of some possible transition strategies. Once attributes for users are stored in a directory server, one useful thing that can be done is to sync up usernames and passwords for multiple environments. We've implemented a system in-house where UNIX and NT account passwords are updated when passwords are changed through our Directory Server interface. This not only simplifies the change for users, but can help to reduce the chances of there being infrequently used accounts with forgotten passwords.

One of the more interesting gateways to date is "ypldap" by Luke Howard of Xedoc. This is an NIS (YP) server that uses LDAP instead of files to look up its information. It supports passwd and group maps along with the other commonly used YP maps. This approach allows using existing YP-based applications without needing to run a script for converting the data.

Eventually, even tools like "ypldap" may become unnecessary when operating systems include directory-enabled /bin/login. Most UNIX versions have a configuration file that tell the O/S where to look for password information. It should be relatively easy for vendors to add LDAP as one of the choices along with NIS and the local /etc/passwd file.

As you can see from this example, LDAP is not an all-or-nothing proposition. Once directory services are available, applications that use the data can evolve.

Further Reading

Tim Howes and Mark Smith have written an outstanding book for using the API, titled LDAP: Programming Directory-Enabled Applications With Lightweight Directory Access Protocol, published by Macmillan Technical Publishing (ISBN: 1-57870-000-0).

Specific information about the protocol is in the RFCs. 1777 defines Lightweight Directory Access Protocol and 1778 details The String Representation of Standard Attribute Syntaxes.

A good starting point on the Web for information about LDAP is at the University of Michigan. See <http://www.umich.edu/~rsug/ldap/>. Information about Luke Howard's "ypldap" can be found at <http://www.xedoc.com.au/~lukeh/ldap/>. Netscape's Web site has several articles about LDAP and information about products that already incorporate LDAP. See <http://home.netscape.com/>.