In the old days of client/server development we only had to deal with single-server homogenous solutions. Today, however, we are building network-centric distributed applications spanning multiple network operating systems and multiple platforms, not to mention the Internet.

An important problem in dealing with a multitude of systems is locating and using network-accessible resources, such as application or database servers, devices, and files. What's more, we need to provide details about each resource to those who would care to use it, as well as security to protect the resources from the unauthorized hordes.

A directory service is a mechanism that provides for the location, identification, use, and authorization of network resources. The idea is to provide a single point of entry for applications, and support the use of a shared set of directory and naming service standards. In other words, directory services help you find your way among the thousands of resources available to your application.

The road to the right directory service for your application infrastructure is not yet clear. Several products compete for your interest today. However, they take very different approaches to the directory service concept, they have varying degrees of platform support, and they have their own ways to support de facto directory service standards. Although this may sound discouraging, consider how far we've come in just the last few years. As applications become more distributed in nature, this progress is going to continue.

The Value

Directory services give you the ability to build applications that can intelligently find resources on the network. Directories know where to find these resources on behalf of the applications, and they track these resources as they are reconfigured, moved, or deleted. For instance, an email application can locate a user group, a word-processing application can find a printer, and a client/server application can find a database regardless of where these resources exist on the network.

Application objects exist on the network, rather than on certain servers, so it's essential that developers have a common infrastructure for locating the object. Both objects and data may be registered with the directory service, or even reside in the directory.

If you've been feeling sorry for your network administrators as their responsibilities become more distributed, you'll be happy to know that directory services provide a central place to add, change, or delete users without forcing the administrator to synchronize those changes throughout the application infrastructure. End users will be happy to know that they only need to log in once to the directory server to gain access to all applications and application resources. When using directory services, applications share security and user information automatically.

Foundations

Directory services are, in fact, nothing more than an orderly way to classify resources on a network. We've all seen examples of this in real life. For instance, biologists classify all living creatures by kingdom, phylum, class, order, family, genus, and species. Using this same approach, directory services are able to classify and identify computer systems by moving down a hierarchy using a naming system to determine direction at the branches.

In the world of networks we have directory services such as the Domain Name System (DNS), Novell Inc.'s NetWare Directory System and Novell Directory Services, Netscape Communications Corp.'s Directory Server, Microsoft Corp.'s Active Directory, and X.500. DNS is a directory service that provides all Internet users with the ability to resolve server names (such as www.dbmsmag.com). DNS has been doing a great job for years, but it's limited to that one simple function. If the Internet is to thrive, we need something more.

In 1988, the Consultative Committee on International Telegraphy and Telephony (CCITT) published the first of two versions of the X.500 Directory Services standard. (There is an updated version from 1993 as well.) X.500 was a repository of global directory information, storing such nuggets as user names, passwords, photos, locations, and access control mechanisms. X.500 was sold as a replacement for DNS and as a mechanism to allow applications to locate resources. X.500 was more flexible than DNS, and its directory service users have many more features and functions.

The X.500 Directory Model is a distributed grouping of systems that cooperate in providing a logical database of information. Using this information, directory service users can access a global Directory Service to Directory subscribers. X.500 is also able to define the information model used in the Directory Service. All the information in the X.500 directory exists in "entries." Each entry belongs to at least one "object class."

Directory services depend on namespaces. Namespaces provide an efficient referencing and retrieval of groupings of related information (such as name, email address, and organization). Within the X.500 world, the namespace is presented as a logical hierarchical directory. X.500 deals with the structure of the entries in the namespace, and not the presentation of the information to the user. All entries in the X.500 Directory Information Tree (DIT) are really a collection of attributes. X.500 defines object classes for directories such as alias, country, locality, organization, organization unit, and person.

Attribute types include: Common Name (CN), Organization Unit Name (OU), Organization Name (O), Locality Name (L), Street Address (SA), State (S), and Country (C).

For example, to find me you may (if this really worked) try: C=US, O=Ernst_Young, OU=CTE, CN=Dave. This address would run the X.500 hierarchy presented in Figure 1.

In this example, the directory-enabled application accesses the Directory using a Directory User Agent (DUA). The DUA transfers the request to a Directory Systems Agent (DSA) using Directory Access Protocol (DAP). The DSAs may communicate among themselves to share information or perform a "referral" to a specific DSA.

If X.500 is that useful, why aren't we using it today? X.500 also has many limitations. First of all, X.500 searches tend to take a great deal of time. This is attributable to the huge size of the Directory database and the overhead of the Directory Access Protocol for database access. Second, DAP uses the OSI stack to link through the network. The use of the OSI stack, including directory services, requires a great deal of memory and other resources. Although some vendors declared X.500 as their standard, most of them took the limitations seriously, and, as a result, X.500 sat on the shelves of IT organizations for many years.

As DNS ages (consider the Internet DNS hiccup of late July 1997), almost everyone agrees that we need a more advanced directory service to solve the problem of nonglobal, nondistributed Internet directories. In an attempt to improve on X.500, the Lightweight Directory Access Protocol (or LDAP) was created in 1993 at the University of Michigan. LDAP takes the best of X.500, providing access to the Directory database but remaining efficient and small by using only a portion of DAP. The end result is a directory service that knows how to get out of the way of an application and that can access portions of the Directory information. However, LDAP performs less comprehensive searches on behalf of the directory service user. As always, it's a tradeoff.

Enter LDAP

Now that we know where we are heading, let's look a bit more closely at what we find once we arrive. LDAP is able to leverage TCP or other transport layer protocols, bypassing most of the overhead of the session and presentation layers.

If you understand X.500, you won't have much of a problem understanding LDAP. It's based on the X.500 directory model entries, using a distinguished name to refer to an entry. However, instead of using the highly structured X.500 data encoding mechanisms, LDAP uses a simple string-based approach for representing entries. Thus, the application's directory service requirements are simplified because the strings use a subset of the Basic Encoding Rules. LDAP entries are typed using an object-class attribute, which results in a much easier method of searching the directory database. (For instance, you may restrict searches to very granular queries.)

At first, LDAP was built to allow the client using TCP/IP to interact with a single LDAP server, which communicates with a single server or group of X.500 servers using OSI. The original LDAP specification was RFC 1487, but it did not provide for communication between LDAP servers, for replication, or for advanced security. LDAP still depends on the X.500 protocols to provide the interaction and maintenance of the directory tree.

LDAP matured into version 2 (LDAPv2) through the IETF standards process (see RFC 1777 on the Web at ds.internic.net/rfc/rfc1777.txt). The latest LDAP specification, LDAPv3, is now a draft. LDAP is also becoming Web-ready. The LDAP URL format is defined in RFC 1959, and it allows Web browser users to access LDAP directory searches as standard URLs. For example: "ldap://ldap.abccorp.com/ou=mis, o=abccorp, c=us?dave" will use the directory tree to perform the LDAP directory search.

Security is an issue as well. LDAP provides simple authentication using a clear text password, and it supports Kerberos as well. Version 3 (LDAPv3) is supposed to provide enhanced security, supporting strong authentication using X.509. This feature will allow LDAP to store public keys.

So what's the bad news? Well, LDAP only provides a subset of the directory search capabilities of X.500. For example, DAP provides several ways to process queries. DAP can send the Directory information to the client for sorting, or if the directory server can't process the query, it is able to kick off a search on another server or refer the client to the server that can satisfy the request. At present, LDAP can't handle this. However, LDAPv3 is going to address these features. LDAP is also not able to use multiple trees to find out more about the information stored on other servers. The next version of LDAP will allow master servers to build indices of their contents dynamically and replicate them to other master servers. This process is known as forwarding indexes.

Despite the lack of other options, LDAP is not the ultimate directory service. As new features -- such as replication -- become part of the standard, the key to the success of LDAP is vendor support. So far, Lotus Development Corp. and IBM, Novell, Microsoft, and Netscape have all pledged allegiance to LDAP, adding support for LDAP in their proprietary directories. The idea is that LDAP will bind together all the information held in these directories to form a powerful global directory service mechanism. For this reason, it's helpful to examine a few examples of LDAP-enabled directory service products. Let's look at Microsoft's Active Directory, Netscape Directory Server, and Novell Directory Service.

Active Directory

Microsoft's Active Directory finally brings hierarchical domain architecture to its current flat model. Although proprietary in nature, Active Directory will support LDAP as a communications protocol for the exchange of directory information with other directories such as those from Novell and Netscape. Active Directory lets you control several domains inside an instance of a hierarchy.

Using ActiveX, the Active Directory Service Provider Interface provides the interconnectivity between Windows NT and external proprietary directory services. The idea is to provide Service Provider Interface as a common layer of integration for both Microsoft and third-party vendors, allowing them to plug in and manage other directory services such as the Novell NDS bindery. Administrators control Active Directory through Microsoft Management Console. The benefit of Active Directory is its support of Windows 95 and Windows NT, both of which now dominate the desktop market and are making inroads into the server world. The drawback is Active Directory's inability to provide the same level of support for non-Windows platforms.

Netscape Directory Server

Netscape Directory Server, a component of SuiteSpot, provides a directory service using LDAP as the infrastructure. Netscape also supports LDAP in Netscape Communicator (and Navigator 4). Directory Server is a part of Netscape's directory strategy to recruit partners and lead the standards effort. All of this effort is wrapped around LDAP. Directory Server is a crucial piece of the strategy.

Directory Server is available on several platforms including SGI, IRIX, Solaris, AIX, HP-UX, as well as Windows NT. Administrators manage Directory Server using an HTTP-based administration server found in all Netscape servers. Directory Server provides a replication mechanism that enables administrators to organize units on master servers in various geographic locations. The idea is to group on the same server users that would typically seek each other out while allowing the server to query other master servers when the information users need is not local. This provides the best performance along with the ability to provide global directory services as well. Directory Server also lets administrators combine master servers into replicas that can make up all master directories, thus providing users with a map of the entire directory.

Directory Server provides a customizable database so that administrators can add keys or fields. The trick is to customize the directory, leaving the LDAP standard attributes alone. LDAPv2 won't know what to do with a nonstandard directory schema.

NDS

Novell Directory Service (NDS) provides Novell-based networks with a global view of the entire enterprise Novell NetWare network. NDS is able to maintain resource information including users, groups, printers, volumes, and other devices in a hierarchical tree structure. Thus, NDS is able to present a simple, logical view of a complex enterprise network. Administrators need only work with the branches of the tree.

To provide fault-tolerant login and administration from anywhere on the network, NDS is replicated. To offer the fault-tolerant features, the directory is broken into manageable pieces and distributed across the network using a sophisticated replication service. The NDS database is extensible, providing users with the ability to customize NDS to fit the exact needs of the enterprise or application.

NDS provides a hierarchical administration feature that lets administrators define security for particular branches of the NDS tree. Thus, all objects on that branch take on the base set of security features. An authentication service controls access to the network using the RSA public key/private key-encryption technology.

NDS provides a variety of distributed services including file services, print services, and security services. Using these services, administrators are able to control user access to network applications centrally. What's more, without leaving their workstations, administrators can install or upgrade new or existing applications on network clients.

Database vendors such as Oracle Corp. are learning to work directly with NDS. Oracle integrates its database software with NDS, providing single sign-on and native naming capabilities to its users. This feature automatically authenticates users to an Oracle database based on their operating system login. The native naming feature lets users connect to an Oracle database by specifying the database object name in the directory tree instead of specifying an Oracle service name.

Java Directions

We are "Javafying" everything, and directory services are no exception. The JavaSoft division of Sun Microsystems Inc. is now working on a Java directory standard known as Java Directory and Naming Interface (JDNI). JDNI is a native Java API providing naming and directory services to Java applets and applications. JDNI is able to store and retrieve named Java objects, and it provides methods for performing standard directory operations.

JDNI is independent of any particular directory service. It allows Java applets or applications to access different naming and directory services using a common API. The idea is to allow JDNI-enabled applets or applications to link into most directory services including LDAP, NDS, DNS, and Network Information Services (formerly Yellow Pages).

Meanwhile, Microsoft is working on its own Java standard as well. In May 1997, the company licensed NCware Technologies' Java implementation of the Lightweight Directory Access Protocol and plans to integrate this technology into the Active Directory Service Provider Interface.

Finding Your Way

The bottom line for developers is that they need to understand directory services -- at least conceptually. Many small workgroup applications (such as those built by small businesses) don't need an orderly mechanism to look up and access global network resources, but ultimately such applications are becoming scarce.

Today we are building enterprise-level applications that span buildings, cities, states, and countries. They may use hundreds of network-accessible resources and support thousands of users. The difficulty arises not only in knowing how to build such applications, but in assuring that all of the components, objects, and data bind together effectively on a global network. What's more, we need mechanisms to allow for the easy maintenance of these networks such as user configuration, a single sign-on mechanism, and advanced security.

Directory service products and standards solve these problems. However, as with any set of standards and their use in seemingly proprietary products, the expansion of directory service products is more an evolution than a revolution. It's going to take time before we have a common set of directory service products using standards upon which everyone can agree. Complex distributed applications typically won't wait for infrastructure, so instead we are pressing ahead in development without an orderly way to manage the resources. This practice is risky.

Figure 1.

In this X.500 hierarchy, you can move up the tree to locate the target.

---

David S. Linthicum is the author of David Linthicum's Guide to Client/Server and Intranet Development from John Wiley & Sons (1997). He's a widely published author, speaker, and a senior manager with Ernst and Young's Center for Technology Enablement. You can email David at

Netscape Communications Corp., Mountain View, CA; www.netscape.com/comprod/server_central/support.faq/directory_faq.html. Novell Directory Services, Provo, UT; www.novell.com/products/nds/index.shtml. Microsoft Corp., Redmond, WA; www.microsoft.com/ntserver/info/activedirectory.htm