Article

A Missing Link: Administration by LDAP Directory Services

Francisco M. De La Vega

The full-service intranet model envisions a corporate information infrastructure built on standards-based services and Internet applications. Among the obvious advantages of such an infrastructure are reduced cost, vendor independence, multi-platform support, and interoperability. While Web interfaces to corporate data are the highlights of intranet technology, there are other important supporting services from the MIS perspective that would ensure the scalability and successful management of such an investment. A directory service is a key component for the coherent and unified management of any information infrastructure. A corporate directory stores information of persons and organizational units. Ultimately, the directory server is a specialized database manager optimized for at least a 10-fold difference in reading to writing access. IS departments have been using customized proprietary databases to handle this information. Information in the directory ranges from users' telephones and email addresses to application preferences and public-key certificates.

Until recently, widely used practical implementations of directory services were of proprietary origin, e.g., the Novell Directory Service (NDS) or the Microsoft NT directory. Now, however, there is an open standards-based implementation called Lightweight Directory Access Protocol (LDAP). Developed at the University of Michigan, LDAP can provide the missing link in the intranet application chain that is needed to unify a complex, corporate client/server application environment. LDAP is an open standard adopted by the Internet Engineering Task Force (IETF) to support directory services in the Internet. LDAP allows the interoperation of directory database applications and consumers through a common communications protocol. LDAP client/server protocol builds upon OSI's X.500 standard, reducing some of the complexity in the original protocol and using TCP/IP as the transport mechanism. Netscape adopted the LDAP directory model to centralize all user management in its product line through a support agreement with the University of Michigan LDAP group. Since Netscape adopted LDAP into its intranet product line, many vendors, including Microsoft and Novell, have announced LDAP compatibility in future releases of their products. Thus, LDAP is clearly heading towards the directory service standard of intranet technology. Among the first commercial LDAP products released was the Netscape Directory server, part of Netscape's Suitespot product line. Other vendors are also shipping compliant products. The University of Michigan distributes a free UNIX LDAP server and related tools.

LDAP directory servers can be used to provide information regarding corporate members to intranet users and applications through either Web gateways or dedicated LDAP clients. The LDAP directory clearly compensates for the lack of embedded directory services in Internet email protocols like SMTP and IMAP. LDAP also simplifies the effort to administer other intranet applications. An LDAP directory enables the use of this database to deploy access control to corporate servers without duplicating information in each server's local database. Further, when deploying a corporate public-key infrastructure for security and confidentiality, LDAP services support certificate servers' duties by identifying users applying for public-key certificates, establishing expiration terms, publishing newly-issued certificates, and publishing certificate revocation lists.

LDAP Service Architecture

A directory service (DS) is a database application designed to manage descriptive, attribute-based information of persons, organizational units, application servers, and so on. Because the directory database is read much more often than it is written, the database is tuned to give quick-response to high-volume lookup or search operations. Consequently, directories don't usually implement the complicated transaction or rollback schemes regular databases use for doing high-volume complex updates. Directory updates are typically simple all-or-nothing changes, if they are allowed at all. The database may be replicated to other servers in order to increase availability and reliability while reducing response time. It is also possible to introduce access control lists to restrict access or write privileges to the database or any of its parts.

The LDAP directory service data model, or schema, is based on entries as described in the X.500 standard. The schema ensures that LDAP clients can recognize entries in the directory. Data in the directory is arranged in a tree hierarchy; the hierarchy begins at a single point (the root) and branches down to the location of the directory entries. The string representation of an entry's location in the database is known as a distinguished name (DN). The DN is used to refer unambiguously to an entry in the tree hierarchy that makes the directory database. Each entry in the directory is a collection of attributes that have a type and one or more values. The entry's objectclass describes the attributes it can have associated with it. As an example, an entry describing my personal data in a directory is shown in Listing 1, using LDAP Data Interchange Format (LDIF), a representation of directory entries in text form. For a more detailed discussion, see the sidebar entitled "X.500 (DAP) Distinguished Names Syntax and Object Classes."

Since X.500 was intended to be a global directory service, the goal of the DN naming syntax is to represent in a unique form every object in the global database. In practice this is not always accomplished in LDAP since the service can be implemented independently by many parties and there is not a guarantee of uniqueness in DN, in contrast to DNS names. This is indeed a problem since DN syntax is being used to identify people and servers in cryptographic certificates (X.509), among other applications that in theory would require unique naming. Thus, planning of the LDAP data tree must take into account these issues to avoid inconsistencies within large organizations, and follow X.500 naming rules more precisely if large scale naming consistency is desired.

Netscape's Implementation

The implementation of the Netscape directory server (DS) set-up and configuration illustrates the steps required for the implementation of an LDAP service. Implementation of the Netscape DS requires:

Unpacking the software distribution

Running the ns-setup script to install the software and provide initial configuration

Configuring and starting the server through a Web-based forms interface

Entering some directory data including the directory tree structure

Constructing control access lists to provide the desired access to the data

As with all Suitespot products, the DS is administrated by a series of HTML forms through a dedicated HTTP server that is running with root privileges, bound at a user-defined TCP port. The execution of the ns-setup script asks the administrator for a basic set of parameters, including the server DNS name, administration port, user ID, and password for the administration server. After the initial setup, configuration continues through the administration server (called server manager) using a Web browser.

Figure 1 shows the basic setup configuration form. The well-known TCP port for LDAP is 389, but if SSL encryption is enabled to provide secure directory access, port 630 is normally used instead. The server identification string is only an internal administrative reference of the server. The user name is the user ID the system uses to run the server, and it is advised to use a specially created, blocked account without shell (never root). The database sub-tree specifies the branch of the global X.500 hierarchy that is served in the present database, and is used as base suffix in all the entries. Finally, the administration of the server relies on an unrestricted user whose entry must be included in the database. The customary name for this user is "Directory Manager." A password is needed to provide authentication and is independent of the root user and password, or any other password used in the system.

Configuration parameters entered through the server manager are stored in the slapd.conf file, located at $NSHOME/slapd-serverID/config directory, where serverID is the identification name of the server provided at setup. This file can be edited directly if required. The same directory also contains the files which describe the server's data schema:

slapd.oc.conf file, containing the definition of the directory's object classes, and

slapd.at.conf file, containing information of the possible classes attributes.

New object classes and their required and optional attributes can be defined here. Listing 2 contains example contents of the configuration files.

Data Entry and Access

After the DS setup is completed and the server is started from the server manager, the database can be populated and searches can be performed on the database. LDAP defines operations for adding, deleting, and modifying entries from the DS. For this purpose Netscape DS includes two types of tools:

Command-line LDAP clients for entering, modifying, and searching data: ldapadd, ldapsearch, ldapdelete, ldapmodify, and ldapmodrdn

A Web-based directory server gateway using CGI scripts and implementing a JavaScript-enhanced, HTML forms interface

The command-line tools can enter data into the DS using the LDIF format (See Listing 1). For bulk operations a file is provided which contains multiple entries in LDIF. This file can be generated from other databases' contents through an appropriate output filter. In order to be able to modify the contents of the DS database, the client must bound the server as a user with enough access rights. Normally this user will be the unrestricted user, the Directory Manager, but it is also possible to grant other users specific access rights to some branch of the DS data hierarchy. Note that in this context users are any entity that can be authenticated with a DN to the DS; in practice this means entries of actual people (the administrator) or other servers with access privileges. For instance, a certificate server in the intranet can have access rights to add public-key certificates data to an entry when a certificate is requested by an user, or to delete such a value when the certificate is revoked.

However, LDAP is used primarily to search for information in the DS. LDAP search operations allow the user to search branches of the DS data hierarchy for entries that match some criteria specified by a search filter. Listing 3 shows some examples of an ldapsearch command-line client used to search the DS. The first example shows the search for a specific CN (cn=Francisco M. De La Vega) in the DS named ribozyme (option h), starting in the base DN o=CINVESTAV, c=MX - the full data tree of an organization (specified by the option b). Since the client is not specifying a particular DN, the search is anonymous, and as such it is possible that restrictions imposed by the administrator preclude the access to some entries or attributes. The search filter is included in quotation marks. The DS returns the requested entry if available, including the values of the defined attributes. Note that some information is encoded, like the user password which is encrypted with the SHA algorithm. In the second example, a different filter is applied: a search for entries whose CN finishes with Vega and whose mail attribute value begins with fvega. The third example is a variation where the mail attribute may contain the string gene; option A is used to recover only the DN of those entries. More complex search filters including nested Boolean operators can be constructed and included in a file. Also, the base DN to search can be set such that only specific branches of the data tree are searched.

While the command-line LDAP clients can be useful for the administrator and exemplify the way LDAP protocol is used, corporate users would normally access the DS data through more friendly user interfaces, either standalone or incorporated in other tools. The Netscape DS includes a Web-based DS gateway that allows users to search or modify the contents of the database. Figure 2 shows the data entry form of the DSGW; modification operations to the database are allowed after appropriate authentication to the server, also provided through Web forms. In Figure 3 the advanced search form exemplifies the typical search operations that can be performed with the DSGW.

The DSGW is based in a series of CGI-bin scripts that are served by a standard HTTP server. Thus, to set up the gateway, it is necessary to follow some simple steps:

Install any HTTP server in the DS machine; for example, Netscape Enterprise Server or NCSA httpd.

Configure a CGI-bin directory that corresponds to the DSGW binaries path ($NSHOME/sldap-serverID/dsgw/bin).

Create URL prefix aliases to DSGW HTML templates (http://dotted.server.ip/ds to $NSHOME/slapd-serverID/ \dsgw/html).

The templates of the DSGW can be configured through the $NSHOME/slapd-serverID/dsgw/conf/dsgw.conf file, shown in Listing 4. Thus, options like period of credentials validity, authentication DN, correspondence between new entries and their specific objectclasses, and the default options presented in the HTML forms are configured here. It should be noted that Netscape DSGW uses JavaScript enhancements, and therefore browsers without JavaScript interpretation are unable to use the gateway.

Another example of a user-friendly interface to access the DS data is the Directory Search option embedded in the Netscape Communicator email client (see Figure 4). In this software, the address book capability of the mail tool is augmented with LDAP lookup, consistent with Netscape commitment of integrating all their attribute-value databases of their product line to LDAP directory services. Thus, email users can search through different directory services as configured in their preferences to obtain mail addresses of persons registered in these DSs. Database services such as www.four11.com and www.whowhere.com are now providing LDAP access to their data.

LDAP Server Management

There are many administrative tasks that should be carried out for proper DS function and availability. Once the DS is running, an access control policy must be established - by default, access is provided only to the Directory Manager unless otherwise configured. The access policy of the directory should be based on read, write, delete, compare, and search privileges, and implemented by means of Access Control Lists. For example, if an anonymous search is going to be provided, it is necessary to create an ACL that includes read, search, and compare rights to anonymous users. An ACL is another type of entry in the DS data tree, relating specific DNs with access privileges to specific sections (base DNs) of the data tree, and even to a specific entry's attributes (for example, userCertificate for a certificate server client). Netscape DS v3 uses a Java applet as the user interface to configure ACLs in the database. This is loaded when the "Restrict access" option is selected from the server's administration console. Figure 5 shows one of the various windows the ACL applet can produce. ACLs are stored in the directory database itself, and not as a separate database. Thus, when backing up or replicating the DS database, ACLs are also recovered.

In the Netscape DS the database can be backed up either in binary database format or as a LDIF file in plain ASCII. This file can be used to populate other directory services' databases in a simple manual replication scheme. However, the DS includes other, better options to replicate DS data to increase availability in a load balance schema or to distribute DS information in locations near to the consumers. At this moment, LDAP replication follows the master-slave paradigm, with all the writing operations needing to be performed on the master server. Replication uses the LDAP protocol, and can be initiated by either the master or the slave server. The initiating server acts as a LDAP client in the process, and replication, which can be scheduled, can comprise the whole data tree or a specific branch of the database. When a writing operation is requested on a slave server, this server simply refers the client to the master database.

Referrals can also be used as a means of directing clients to other DSs when the data request cannot be satisfied. At this moment, LDAP protocol uses only hardwired referrals specified by the server administrator. This passive mechanism has several disadvantages:

The referred server may not be able to satisfy the requirement.

The referred server can in turn refer the request to another server.

This can lead to long lookups when requests are made to root servers, and there is no guarantee that the request will be satisfied.

Loops can be produced during the referral process.

Therefore, is safer to use a master-slave architecture within corporations to avoid these problems. New mechanisms that promise a more efficient, intelligent, referral mechanism (forward indexes) are being investigated by the LDAP working group at the University of Michigan, and will be released in future versions of the protocol.

Other Intranet Services

A single database for user management implemented on an open, standard protocol can be extremely useful in medium-to-large intranets. A simple example of the usefulness of this approach can be taken from Web server administration. In an intranet environment, Web servers provide access to corporate databases and documents. In such an environment, it is common to implement ACLs to regulate access to specific information assets.

As the intranet information infrastructure continues to grow, multiple Web servers are usually deployed either to distribute authoring and data origin (i.e., the Web server is best located near the data authors), to distribute load, or to distribute tasks (e.g., separate servers for CGI-bin processing vs. document serving). Traditional Web server management requires each server to access a local user database. This database is relevant only to each server, and only very primitive database replication schemes exist to distribute the data (export and import the data into each server). To overcome this limitation, IS Departments at some large sites have developed proprietary user management solutions backed by RDMS. While this solves the problem at hand, the resulting proprietary approach involves considerable development, as each new intranet application requires user management.

A much better approach is the use of a single LDAP DS database (which can be replicated for availability) to support Web server ACLs. New-generation HTTP servers are being released with support for LDAP protocol. One such product is the Netscape Suitespot 3.0 server. This server uses an LDAP DS to provide user management and access control. The Netscape server General Administration console is now where user and group management takes place (see Figure 6). ACLs can be created for each of the administered servers using a DS as the database management system. The administered servers can range from HTTP, Certificate, and even SMTP Mail servers. Thus, the same database can be used for enabling user "licenses" of certain intranet services, configuring mail preferences for users (e.g., IMAP or POP delivery, aliases, etc.), providing public-key certificates of users for authentication, private messaging, and so on. User groups can be created in the DS as the basis to implement specific ACLs for Web servers. In fact, every intranet application server also belongs to a specific group of LDAP entries in this schema, providing a place for server authentication management (e.g., a certificate server can bind to the directory server to add a new certificate or to revoke another as a specific DN entity). This infrastructure is now much easier to administer and presents the intranet for the first time as an integrated set of applications of diverse origin, running on diverse platforms, competitive with other proprietary corporate information infrastructures like Lotus Notes and Microsoft NT environment. In support of a secure enterprise environment, Netscape DS can provide secure SSL access to the directory data, after proper authentication with X.509 public-key certificates.

Remaining Problems

LDAP directory service is the missing link in the intranet application chain needed to unify a complex corporate client/server application environment based on the Internet open standards. From the Internet perspective, LDAP can also play a useful role in enabling practical implementations of personal information databases in a global scale. Still, some problems remain.

X.500 DN syntax is being used to provide the naming standard for X.509 certificates. In a security-anxious Internet, public-key certificates are becoming increasingly important. However, in contrast with DNS names, there is no guarantee a given DN issued in a X.509 certificate is unique, as the original X.500 schema required. Thus, naming conflicts are likely to appear. The appearance of a new naming space parallel to the well-known and tested DNS does not seem justified to many, and it can be an obstacle for implementation. There are a few proposals to avoid discrepancy of both naming spaces by including DNS names in LDAP data hierarchy. Microsoft is implementing this approach in NT 5.0 directory services, which will be LDAP-compatible.

Integrating LDAP and DNS naming services can be facilitated by special LDAP URLs. For example, the URL ldap://directory.gene.cinvestav.mx represents the use of LDAP protocol in that specific server. The URL ldap://directory. \gene.cinvestav.mx/o=CINVESTAV, ou=Biblioteca Area Biologica?one issues a base object search for the people working at the Biological Area Library of CINVESTAV. It is also possible to include a DNS record with a pointer to a LDAP directory URL, and is possible to add DNS entries to a LDAP server.

Many corporations already have a huge investment in proprietary directory schemes, such as Windows NT user databases and Novell directories. Netscape DS NT version includes utilities to import NT users to the LDAP DS. Alternatively, most vendors are about to release new "LDAP-enabled" versions of their products using gateways. Finally, new programming APIs and developing environments for intranet services (NSAPI, ISAPI, Java, and COBRA) are likely to embrace and include LDAP operations in the near future, thus transforming LDAP in a truly universal directory standard. While LDAP provides a practical way of implementing the elusive X.500 directory protocol, it does not yet fulfill the promise of a unique global directory. LDAP does, however, allow their organizations to leverage investments and provide unified intranet services within the enterprise boundaries.

References

Howes, T. LDAP: Programming Directory Server Enabled Applications with Lightweight Directory Access Protocol. McMillan Tech Publishing, 1997.

LDAP Documentation at the University of Michigan:

http://www.umich.edu/~rsug/ldap/doc

Netscape Communications Directory Server Documentation:

http://home.netscape.com/eng/server/directory/3.0/ag

Wahl, M. LDAP FAQ at Critical Angle:

http://www.critical-angle.com/ldapworl/ldapfaq.html

About the Author

Francisco M. De La Vega has been Assistant Professor and Head of the Computer Unit at the Department of Genetics and Molecular Biology of CINVESTAV, an academic research center located in Mexico City. He has been CINVESTAV's Webmaster since 1994, designer of a digital library, Solaris fan and system administrator, and private consultant on Internet/intranet technology. In May 1997, he moved to California and is now a Senior Systems Consultant with Bluestone Consulting Inc. He can be reached at: http://www.paco.com.mx, email: paco@paco.com.mx.