Directory Services: Big Burdens Face Today's Network Managers

We've all heard the claim: Directory services can break the chain of network drudgery and bring unprecedented rewards through increased productivity and management. Then why aren't you running them on your network, instead of slaving to find ways to keep things going in their current state? Many organizations don't regard a directory service as a critical component of the network. and, let's face it, most of us don't have the time or budget to tackle the task of rebuilding our corporate networks just so we can see network resources, like devices, applications and users, differently.

Nevertheless, a good directory service will help you build a much more efficient network. Directory services are not frivolous--they are powerful platforms that make administering and using the resources on your network faster, easier, more secure and more cost-effective.

In fact, if you hope to build any semblance of a managed environment these days, you just about have to use some sort of directory service. If not, you're only creating extra work, since you'll have to build and manage your network around the independent "directories" already in use on your network. By using a directory service that integrates your environment into a consistent, uniform platform, you'll still have to build and manage these services--but because you can use a single, shared, networkwide repository, your control goes up and your maintenance goes down.

The effort required to build these directories is by no means trivial, so it's important to choose one that will yield a significant return on your investment and can grow along with your needs. Though many vendors have striven to incorporate valuable directory services within their network operating system, they fall short of this goal simply because none has managed to deliver a satisfactory solution that works with the variety of systems and services found in today's typical heterogeneous networks. Furthermore, network application vendors have been loath to support a specific directory service, preferring to provide directory-independent services and management tools.

Fortunately, many NOS vendors have come close to providing a directory-centric interface to the network. Therefore, depending on the exact nature of your environment, you should be able to achieve a level of interoperability that well exceeds your current installation. Four vendors, in particular, have achieved admirable levels of functionality, at least within their own product lines: Novell's Novell Directory Services (NDS); SunSoft's Network Information Service Plus (NIS+); Banyan Systems' StreetTalk; and IBM's Directory and Security Server (DSS) for OS/2 Warp.

To help you fully appreciate the potential value of these services, we put these four products to the fire in our San Mateo, Calif., labs over a three-month period, exploring their various strengths and weaknesses. Although they all held up fairly well in our tests--they came out about even, in terms of features and robustness--each displayed distinctive strengths that made it especially appropriate for specific environments, as well as telltale weaknesses that made it a poor choice for others. For example, Novell's NDS proved to be the best directory for companies that need centralized control, while Banyan's StreetTalk is more appropriate for companies with distributed management centers that want to interconnect departmental resources. NIS+ is the best choice for Unix-centric networks, while IBM's Distributed Computing Environment (DCE)-based DSS is the best platform for building cross-organizational, business-to-business, network-centric applications.

The four products exhibited an ability to manage and publish network information within a single database that could be replicated among a variety of different servers within an organization; products unable to provide this basic level of service were excluded from our testing. The latter group includes Microsoft Windows NT Server, which does not provide an integrated database that can be replicated across an organization. (IBM's LAN Server, initially eliminated, later was reinstated as a platform that supports DSS.)

We also excluded products that were pure directories, instead focusing on those that also provide network services. For the majority of networks, a $200,000 super-duper, high-end, Yellow Pages-like directory service that does nothing but advertise resources on other systems is an unlikely purchase. Such products generally appear only in the largest worldwide enterprises, and offer little value to those administrators managing the remaining 99 percent of the world's networks. They're of even less value to users who simply want to print a document without having to query a far-off database of worldwide resources. For our purposes, if the directory service could not be directly integrated into the client environment--supporting immediate and direct file, print and network service access--we excluded it. We set up the directories in our labs and analyzed their strengths and weaknesses.

Choosing a Directory Service

A directory is nothing more than a list of resources--for instance, the physical devices on the network (such as PCs, servers, printers, routers and communications servers), the services available on a specific device (OSes, applications, shared-file systems and print queues) or the users who have accounts on those services. Such lists can be stored just about anywhere and often are. A good directory service combines the lists into a database of network resources that separates them into natural classes, then makes them available to any user or service that needs them.

There are four critical areas to examine when choosing a platform on which to build a unified network services directory. First and foremost is flexibility of data types: Does the directory provide tracking mechanisms for the resources on your network? Your directory should be able to track these resources, let you manage them and let users access them without jumping through hoops.

The second consideration is cross-platform support. How many client systems are supported, using their native network tools and applications? How many platforms does the directory itself run on? If you can provide services to only half your users, or if you can integrate only half your systems, you're not going to get the full extent of the rewards you might have expected.

The third criterion is how well the directory provides bidirectional services, both at the operational and managerial levels. For example, it's not enough for a system to show you print queues; users also should be able to print to them--and you should be able to manage them--without having to load additional software. Although these services are typically provided by application gateways or the underlying NOS, without them the directory itself is useless.

Finally, in the unlikely event that multiple products offer the exact set of capabilities you require, you'll want to examine the architecture of the directory itself. Some of the limitations to watch for: Does the directory architecture support any industry standards, such as the Lightweight Directory Access Protocol (LDAP) or X.500, or directory gateways, so you can publish your directory for outsiders to see? What kind of limits can you set on that access?

Tracking Resources

Suppose you want a unified directory that defines workstation access filters for client logins. First, you'll need to define the workstations on your network, then the servers that will be logged into and the users who will log into them. These three levels of resources--physical devices, network services and users--are the fundamental building blocks of the network; without them you cannot implement any reasonable enterprisewide directory or any other services that depend on consistent management of this information.

At the physical level, you face myriad details that must be tracked. You will have hardware addresses for systems on your network, protocol-specific addresses, and the details that go along with each of the specific protocols--such as IP route, Domain Name Service (DNS) server, AppleTalk zone and NetBIOS domain. Although products exist that do this already, they keep this information in their own databases, which doesn't do you any good at all.

By contrast, having a directory that stores information about the devices on your network means services, such as those independent-minded asset-tracking programs, could use it as a repository. Other services, like the NOS login security system, also could take advantage of it. Unfortunately, most directories lack these resource-management mechanisms, forcing administrators to manage this duplicated information in multiple instances.

By design, NIS+ lets administrators track the devices on a network--but only those devices running TCP/IP. SunSoft's SolarNet PC-Admin, an add-on product, can manage the IP addresses of those devices, but its support is similarly limited to those systems running only PC-Admin client software. PC-Admin is actually a comprehensive product, providing a tremendous amount of functionality to the PC-Admin clients that can use it.

DSS automatically collects information about Distributed Computing Environment (DCE)-based systems, but it does not manage the transport protocols underneath the DCE services. Since DCE is protocol-independent, it leaves management of the underlying protocols to tools specific to them. Consequently, it doesn't make for a strong resource-management platform, even though additional IBM Warp Server products provide integrated DNS-Dynamic Host Configuration Protocol (DHCP) management tools that solve the problem for IP systems interoperating with IBM's directory tools. Additionally, some vendors sell remote DCE configuration tools to manage the DCE-specific configuration information on those systems, with the changes reflected in the DCE directory.

NDS is rather weak in this area. Although NDS automatically locates any NetWare 4.x servers in the current tree, you cannot configure the network portions of the servers using these tools. Instead, you must use external tools that can vary wildly from server to server. Also, although you can manually add other devices, such as PCs or NetWare 3.x systems, to the directory, you can't do much with the information. NetWare's own security and backup technologies don't tap into these manually built databases, rendering the process of building it a complete waste of time.

Banyan Systems StreetTalk servers automatically add themselves to the directory--and some StreetTalk clients can be configured to register automatically with the directory, thereby making themselves visible to administrators. However, StreetTalk does not allow for the remote configuration of the remote system's network-specific settings, requiring you to visit each and every system on the network when you want to change a transport parameter. We could find no mechanisms in StreetTalk for adding foreign devices to the directory manually.

Service Management

Besides managing the devices on your network, an effective directory service also should be able to manage the services available on each device. These services may be applications installed on a PC or vertical functions, such as a router or mail gateway configuration, or just about anything else. Since the services are what makes your network work, this level of functionality is central to providing an effective platform for distributing network services.

Service management is also the most difficult aspect of building a truly unified directory. Since each of the directory services we tested provides its own management platform, you have to use proprietary management widgets to access and configure the resources on the network. This means using NDS-aware snap-ins when trying to manage services via NetWare Administrator, using NIS+ applications with SunSoft's Solstice tools, using OS/2-based programs with DSS and using Explorer- or Enterprise Network Services (ENS) Management Tool (MT)-aware components with StreetTalk.

This is not an impossible condition--quite a few products include these add-ons with their systems. The problem is, you cannot find appropriate add-ons for all the services on your network. You might be able to find fax-server management software that plugs into NDS' administrative console, but you may not be able to find router management tools that plug in equally seamlessly. This leads to a situation where you can directly manage some of your services from the directory's administration console, but everything else must be managed via external tools.

In terms of third-party application support, NDS is the hands-down winner. It has more add-on products that directly support NDS' administration console than any other NOS directory we tested. The range of products extends from external print servers to e-mail systems and desktop-management applications. Unfortunately, the range of service management tools is nowhere near ubiquitous. As illustrated by the lack of protocol configuration services, Novell doesn't even support many of its own utilities that use NDS' management platform. By showing such a lack of enthusiasm for the platform, Novell has unwittingly encouraged other vendors to ignore it as well. If not for the tremendous base of NetWare customers, there would likely be no snap-ins for NDS whatsoever. Despite this, you can do more with NetWare Administrator--and find more third-party modules for it--than you can for any other directory management tool on the market.

NIS+ administration tools also are widely supported by a number of third parties, largely because it's so easy to do. Rather than write software that interfaces directly with NIS+ or Solstice, vendors simply write Solaris-based configuration tools that users can link to the Solstice console if they want to. Although there are few Solstice-specific applications--you cannot manage most of Solaris' native services, for that matter, not even with Solstice AdminSuite--there are thousands of Solaris-based network applications that can be easily integrated within Solstice.

StreetTalk is in the midst of a transition to a 32-bit Windows-based console called Explorer, designed to be far easier to use than Banyan's legacy DOS-based management tools. Banyan offers a 16-bit Windows program, called ENS MT, that offers an easy-to-use console for managing StreetTalk services. But StreetTalk for Windows NT includes some extended services that cannot be managed via ENS MT, and these are tasks Explorer is designed to perform. For managing all the services available on a StreetTalk system, the DOS-based MANAGE program and ENS MT both provide extremely comprehensive configuration tools.

Meanwhile, Explorer is still a work-in-progress and, as such, there is little you can do with it. For example, although you can create file shares with it, you cannot set security permissions for that share. As a result, you are practically forced to use the DOS- or 16-bit-Windows-based administrative tools for most of the detail work. In addition, we could find no third-party products that plugged into Explorer, nor any way to extend Explorer's interface to support external application calls.

DSS offers a set of templates for vendors seeking to develop DSS-aware applications, although the platform itself is so new not many vendors have had the time to do so. Also, there is such an overwhelming lack of third-party DCE-aware applications that many vendors won't even consider this a viable expenditure. The majority of applications apt to link into DSS likely will be those written in-house to control internal network-centric applications that run over DCE.

In the future, platform-specific management agents may not even be necessary. With the advent of Lightweight Directory Access Protocol (LDAP)-aware, Java-based management tools, an off-the-shelf plug-in may prove able to work with any directory service, regardless of the OS on which the management console runs or the back-end directory service in use. Using LDAP to request information from the directory, a Java-based tool could locate relevant information--and make necessary changes--without taking the underlying OS or the directory service into consideration. Until such a time, however, administrators will need to choose network products that support a specific management platform.

Account and Security Management

Once you've addressed device and service management, you'll want to look into controlling user access to these services and making sure access for authorized users is clean and seamless. For example, if you have a dial-in server used for remote access to your network, you would not want to have to build another list of users and passwords within that system, but probably would prefer to be able to tap into the networkwide directory of user accounts.

Also, rather than have your users sign in to multiple systems and applications to access network services, you'd like them to be able to leverage single sign-on technology so that connections are authenticated by the directory instead of the users. Multiple accounts have long been the bane of network administrators and users alike, often resulting in sidestepped security measures. Improving network security without creating more hassle to users should be one of your primary objectives in seeking directory services.

In terms of after-market products, NDS again leads the pack, with the broadest base of third-party support for NetWare's native security mechanisms. There are thousands of applications and systems that will use the NetWare login for access control, ranging from dial-in servers to terminal emulators. Note that much of this benefit comes from NetWare 4.x's support for bindery emulation, which lets these systems authenticate against a NetWare 3.x or 4.x server without having to work with NDS explicitly. Giving credit where it's due, this is as much a benefit of NDS as anything, since it is capable of emulating the NetWare 3.x bindery for these purposes.

External systems aware of NIS+ also are extremely rare. Finding an external fax server that supports NIS+ authentication can stretch your equipment acquisition time into a multiple-month event. NIS+ authentication support for applications running locally is one of the best in the business, although this is more accidental than deliberate: Since database clients and other applications need query only the OS for the user information (and not NIS+ explicitly), applications can take advantage of NIS+ without writing to it directly.

DSS also offers extensive support for centralized maintenance and use of network accounts through its support for Kerberos, a by-product of its DCE support. In theory, any DCE-aware or Kerberos-based application should be able to authenticate users against DSS, but as is the case with the DSS console, there are so few of these applications--and so few vendors providing them--that finding this support in any mildly esoteric product is next to impossible. There is a groundswell of activity surrounding Kerberos lately, however, that shows no signs of abating. Many operating systems support Kerberos, thereby indirectly supporting the applications used (NIS+ benefits from the Unix shell, and so do Kerberos-enabled Unix, VMS and MVS installations). Basing an enterprise's single sign-on strategy around Kerberos could prove to be a very smart move.

Technologies that address the distributed login and single sign-on objectives are under development in several industry segments. However, most of these technologies are actually complicating matters because they entail yet another list of accounts that administrators and users must work with. Until all vendors implement mutually acceptable authentication mechanisms, there is likely to be little hope of a single point of network authentication.

Client Platform Support

Client operating systems and applications should integrate seamlessly with the directory, making users' access to resources as invisible as possible. If the client can't see the resources--or, worse, if it can see them but cannot access them--then the directory benefits only the network administrators. Users looking to access files, printers, user lists, e-mail accounts and other network resources should have direct and immediate access to these lists without having to load monolithic directory agents or external access utilities, or being required to login manually to another remote system. Requiring users to modify the way they perform routine tasks, even a little, usually results in their not doing anything at all, thereby wasting your investment resources.

In terms of direct support for client OSes and their native network tools, NDS and StreetTalk are both exceptional. They offer, each in varying degrees, native support for Windows 3.x, Windows95, Windows NT, OS/2 and Apple Macintosh clients.

For example, Macintosh clients attached to NDS servers can access network resources using the native Chooser (just as NetWare 3.x does), but without benefit of NDS' advantages, such as single sign-on or directory query capabilities. The direct NDS support is implemented in a separate set of utilities that offers this functionality and more, but these utilities are not where they would normally be on a Mac. Instead, the single sign-on and directory browsing capabilities are provided through external resources. Although smooth and well-designed, they are not located where casual users would expect to find them.

For its part, DSS' support for DCE and IBM's own LAN Server make it usable on a variety of client platforms, although the extent of its ability to integrate services can't match that of NDS or StreetTalk. There are DCE clients for all popular client OSes, but the implementations vary widely in terms of features and functionality, and some of DSS' strengths (such as its integrated DCE-application launcher) are lost if you don't use OS/2 Warp as a client. Nevertheless, DCE's directory services are accessible to almost every OS on the planet, making it a smart choice for companies developing in-house applications that rely on a universally available directory service.

NIS+ is not widely supported outside of the Unix world it was developed for, and that's too bad. SunSoft's SolarNet PC-Admin is a comprehensive NIS+ client for Windows 3.x that provides everything from desktop management to user authentication, but this product is available only for Windows 3.x and Windows95 systems. Since the product relies on SunSoft's PC-NFS TCP/IP stack, there is no support for Windows NT, OS/2 or Macintosh clients. However, there are numerous third-party TCP/IP suites for a variety of platforms that do offer access to NIS+ services, so you may be able to implement at least a rudimentary solution on all of your network clients, if not a comprehensive one. Third-party products also exist that integrate NIS+ directory information (such as NFS file and print access) into these other platforms, providing users of those platforms with immediate and invisible user access.

Integration With Other Server Platforms

Granted, it's important for users to access a directory with their native tools, but it's equally important that additional back-end systems be integrated into the overall directory. Even if all your clients can access the directory, if they can communicate only with services that run on one proprietary OS, then the overall advantage of the directory is diminished.

Rather, you should be able to run the directory services server on the major back-end platforms your organization uses, and maintain the same level of service management and integration you get on the native platforms. You should be able to manage the devices, services and accounts on these other platforms just as easily as you can on the native ones. If the other back-end systems in your organization can't take advantage of the directory you choose for your network, you'll still be stuck with multiple points of management and users saddled with multiple accounts and service access methods.

Among the technologies we tested, DCE is the most readily available, at least in terms of support for back-end systems. DCE network services exist for everything from mainframes and minicomputers to popular desktop clients, so you can guarantee high availability of content and access, and provide a consistent and well-integrated set of directory and security services across platform lines. Unfortunately, the dearth of third-party products that will take advantage of this information drastically limits DCE's usability in smaller shops.

On the other hand, although NIS+ has not been ported to as many platforms as DCE, its predecessor (plain-vanilla NIS) has--but again, few fully implemented NIS servers exist outside the Unix space. You can get NIS servers for the Unix variants offered by IBM, Hewlett-Packard Co. and Digital Equipment Corp., but you can't get it for these vendors' non-Unix, midrange products. One exception is Novell, which has ported NIS to NetWare and made it a standard part of IntranetWare, providing another point of integration for NIS-centric environments.

Unlike NIS+, StreetTalk has not only been ported from its original Unix-based VINES platform to other flavors of Unix, including Solaris, HP-UX, AIX and The Santa Cruz Operation's SCO Unix, it also has been ported to run on NetWare and Windows NT server platforms. However, most of these implementations are languishing a full revision behind the 7.0 release of VINES with no upgrades in sight. For now, administrators can build a strong, cross-platform, enterprisewide directory using all these releases, but this may not still be true next year when the various implementations further diverge.

Of all the products we tested, NDS offers the poorest cross-platform back-end support. It is available only on NetWare and SCO's UnixWare platforms. Novell promises to change this soon, and already has announced deals with Sun, HP and Caldera, all of which plan to port NDS to run as native services on their respective Unix offerings. Similar deals with IBM and other vendors have been hinted at, but no formal announcements have been made. In addition, Novell says it plans to port NDS to run on NT by mid-1997.

It's interesting to note that Novell also has announced plans to make the source code for NDS freely available in early 1997 to encourage OS and application vendors to incorporate NDS directly into their offerings. If this comes to pass, NDS could become as ubiquitous as DCE, while retaining its advantages in third-party support and integrated services. It's worth noting that Banyan tried something similar with StreetTalk, but Universal StreetTalk--the source code for the directory service for which Banyan charges a royalty rather than making it free--has met with minimal success.

It seems more likely to us, however, that vendors will continue to use the tools and service they have historically preferred, and that they will choose to put LDAP interfaces onto their proprietary offerings rather than orphan their customers' investments in technology. We see no hope of a standard directory service implementation on every platform anytime soon.

Bidirectional Service Gateways

Verifying that a directory service supports your clients' native views and integrates your various servers' services, however, doesn't guarantee interoperability between those clients and servers--you might be able to show them each others' stuff, but getting them to use it is another matter. Most likely, you'll either have to implement system-neutral services between them or cross-map the different services so everybody sees everything in their native formats. This is where bidirectional service gateways can help.

For example, if you want your Macintosh clients to send print jobs to Unix-based queues, you not only need to publish those queues so the clients can see them, but you also need to set up the queue so the Mac systems can print to them using their native services. Similar steps must be taken to provide other functions as well, including file access, vendor-specific e-mail addressing and delivery, and access to services such as network faxing and shared databases. Cross-platform access to resources is so critical that if these services aren't present or don't work, then the directory that publishes them becomes completely irrelevant. Although the NOS beneath the directory usually provides the bidirectional service gateways that handle such jobs as making a Unix print queue look like a Mac print queue and making other cross-platform services appear "native" to the various clients that use them, a plethora of third-party products also is available to fill in almost any gaps in the cross-platform services provided to users.

When it comes to supporting native client systems, the NetWare operating system stands out, allowing an administrator to create file systems and print queues that support client access using native NetWare, AppleShare and Network File System (NFS) out-of-the-box, with add-on support available for Service Message Block/NetBIOS-over-TCP/IP (SMB/NBT), such as Windows95/NT and Samba systems, Systems Network Architecture (SNA) and even Open Systems Interconnect (OSI) FTAM systems. Furthermore, these file or print resources can exist on any of these platforms, so a remote Unix print queue can look like an AppleShare printer, for instance. Nor is this support limited to file and print sharing; there are services that let you integrate your NDS directory with NIS, so you can provide cross-platform directory services as well, a feature unmatched by any of the other platforms.

Indeed, by itself, the Solaris platform is weak in this regard, offering only NFS and other IP-specific services to clients of its own ilk. However, there is a phenomenal base of SunSoft and third-party add-on products that provide network services for various clients and servers, so administrators can mix and match. Whether you need cross-platform support for NetWare, AppleTalk, SMB/NBT or even DCE systems, you can find it without difficulty.

IBM's DSS is available for OS/2 Warp and AIX, and provides bidirectional integration with both systems' native services, which means LAN Servers and AIX clients can be synchronized with the DCE directory as if they were DCE clients, giving them access to DCE applications and services. Given the variety of clients for LAN Server--and the tremendous assortment of DCE servers--you can put together components for a successful installation quite easily.

Banyan has taken a different approach to the interoperability question. Rather than make services appear to the various clients as native services, Banyan makes services appear to be VINES resources; a NetWare file system with StreetTalk functionality and service management doesn't look like an NFS file system, it looks like StreetTalk File services. Though this provides a single name space across your entire network, it eliminates much of the differentiation and value that the various clients bring to networking. There are also backup considerations that come into play: You may not be able to back up all of the native file systems completely. On the other hand, you will have the luxury of being able to restore a StreetTalk file system to any StreetTalk server on your network. It's a valid trade-off, and possibly one many administrators will welcome. A few add-on products provide bidirectional service gateways for a handful of platforms, but there are nowhere near as many as you can get for NetWare or Solaris.

Architectural Concerns

Understanding how directories distribute the data they contain is an important part of building a distributed network, and choosing the wrong directory could mean having to rewire your entire WAN to accommodate the directory's architecture. All of the products we tested allow for the replication of directory updates, in lieu of redistributing the entire directory database. Also, they offer hierarchical directory structures that can be managed by different administrators and restricted to different users and groups. But there are implementation variances among them that can significantly affect their day-to-day operation.

StreetTalk's three-part naming scheme uses resource@location@organization to identify elements within the directory; every "location" portion of the directory has a home server that stores information regarding that portion of the directory. Servers are aware of the home server for every location, so when a client requests a resource, the query is forwarded to the appropriate home server. Resources can be aliased into other locations, allowing users to refer to resources locally--the requests still get forwarded to the correct home server. Since the directories are not propagated or replicated, they can be filled with massive amounts of data without overloading your WAN with updates, although user access time and reliability may be adversely affected. Anyone who wants to replicate the directories can do so in the form of "shadowing." Although shadowing improves overall performance and reliability of the network, it makes StreetTalk susceptible to scalability problems.

Architecturally, NDS is based loosely on the X.500 naming scheme, providing up to 15 levels of directory nesting, except that the entire tree is managed as a single entity. NDS relies heavily on replication to distribute copies of the database to servers across the network. Many users have reported performance problems with very large directories, but it is possible to segment the database into multiple containers, each with its own replication scheme. To build extremely large directories, you have to segment the directory into multiple containers to keep performance at a usable level. However, AT&T's WorldNet service is the world's largest directory and it's based entirely on NDS, proving that NDS can indeed work with millions of entries.

Similarly, DCE leans heavily on the concept of master and replica servers, where directory updates are sent to the master server, then replicated outward to the replica servers. If you have a network that spans from California and New York, for maximum efficiency you would want to put the master somewhere in the middle, or at least somewhere with fat pipes going to the main offices. The directory model supports the concept of a smart client that can keep full copies of the directory locally, providing local access without having to query the nearest replica server.

Though greatly enhanced over NIS, NIS+ echoes its predecessor's orientation toward providing access to system files like /etc/passwd that needed to be shared across an organization. Far from being a liability, this feature actually makes NIS+ an extremely flexible platform for distributing consistent information across an enterprise network. New features in NIS+ include hierarchical subdomains and distribution of authority among those subdomains, which enables administrators to define independent regions of authority and content. All updates are made to the master database within the subdomain, where copies are sent to the secondary servers within that subdomain.

A viable directory service should support other directories and name services that run on the network. You should be able to unify multiple instances of the same directory service and interface with other directory services on your network. Finally, you must be able to connect to other organizations' directories through public networks, especially as companies begin automating business-to-business transactions.

In this regard, DCE offers the most flexible implementation among the directories we tested. DCE's cell-based directory structure lets administrators build isolated networks while simultaneously connecting to the rest of the world through global directory interfaces. DCE supports X.500 and DNS as locator protocols, letting you work easily with external DCE directories. DCE's trust-relationship model (not to be confused with NT's trust model) lets you define which remote cells (whether internal or external to your organization) will be accessed and at what level, so you can build cross-organizational applications and security without entering information about every user or group in the remote cell.

With NDS, administrators can build disparate directory trees that coexist on the network. This means organizations can create entirely separate directories, if needed, but still let users log in to multiple trees simultaneously. External connectivity is not so simple with NDS, however, as capabilities do not exist for mapping NDS trees into DNS or the global X.500 directory. Since NDS is dependent on IPX or NetWare/IP for transport, you can connect only to systems that use these same protocols. Novell promises to include native IP support in the platform-independent version of NDS to be released next year, but until then, this is a major roadblock for companies looking to build cross-organizational applications or services. One advantage of IntranetWare over other platforms, though, is that it supports the browsing of the directory with Web browsers, allowing you to provide a weak Yellow Pages-type of interface to the services registered there. Novell promises to deliver a Java interface to these tools.

Likewise, NIS+ offers comprehensive intra- and interorganizational connectivity. It is entirely possible to run multiple NIS+ domains on your network, and have users logged into both systems simultaneously, reaping the expected rewards. Because NIS+ assigns fully qualified identifiers to resources (for instance, my account name is ehall.SanMateo.nwc.com), the chances that different users on different networks will share common identifiers is all but nil, another major enhancement over NIS. Furthermore, although NIS+ does not support X.500-style naming, NIS or NIS+ directories can be conjoined using DNS, the global X.500 directory or a local DCE CDS directory.

Meanwhile, we uncovered problems with StreetTalk with regard to intra- and interorganizational connectivity. The resource@location@organization model works well inside complex organizations with overlapping departmental and geographic boundaries, but the model rapidly falls apart when the aim is joining different organizations--or even different directory trees. For example, since servers are always kept in the SERVERS organization, any time multiple trees are joined, their server-specific services cross-populate into the SERVERS organization, causing operational problems. On another note, although the directory model itself is not based on X.500, StreetTalk can assign X.500-specific attributes to any entry in the directory. As a result, you can interface the entries with other X.500-based directories, although StreetTalk's reliance on VINES IP or VINES-over-UDP will severely restrict the number of systems you can communicate with.

Pick a Directory, Any Directory

Once you apply these filters to your environment, it's highly unlikely that more than one of the directory services we tested will meet all your criteria. In fact, we'd go so far as to say that it's highly unlikely that any of them will meet all of your criteria.

But that shouldn't stop you from trying. As the computing industry moves toward increasingly network-centric services, the need for directory services will only get more pressing. You may not be able to integrate your systems and services into a single, unified directory, but you will be able to tie together at least some of the elements.

A new class of products--metadirectories--already is being positioned to address these integration issues, but the products aren't yet mature enough to warrant serious consideration as potential directory services. And although LDAP offers respectable functionality in terms of client-to-server query and update capabilities, it is unclear whether it will blossom into a protocol capable of providing server-to-server communications.

Written by Eric A. Hall.
Copyright © 1996 CMP Media, Inc. Used with permission.