NOTE: This article is an archived copy for portfolio purposes only, and may refer to obsolete products or technologies. Old articles are not maintained for continued relevance and accuracy.
December 15, 1996

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.

Novell's Market-Leading Directory Services

PROS: Excellent third-party support; extensible management console; aliased resources; best client support; integrated Network Information Service (NIS); 15-level X.500-style naming; gives users simultaneous access to multiple independent trees; robust replication capabilities; excellent performance; market leader

CONS: Weak device management tools; weak service management tools; weak server-platform support; poor performance without careful planning; no support for Domain Name System (DNS) or X.500 as directory locator protocols

Best Used In: Corporate networks that need to establish hierarchical network directories, with absolute control at the top and distributed authority through the organization; companies with heavily mixed network infrastructures that need to manage resources across platform lines

The primary reason Novell Directory Service (NDS) is the market leader—and the reason it has a huge base of third-party support—is that it comes from Novell. Although it does not provide all the features of the other products we tested, it does provide exceptional integration with third-party offerings and a broad base of services—elements derived from Novell's relationships with the industry's key players—as well as backward support for NetWare 3.x.

Though NDS has the strongest base of third-party support for integrated security and directory services, it does not support everything we would desire in a directory. Most of NetWare's own management tools and services do not take advantage of NDS, much less most of the products that support NDS by way of NetWare 4.x's bindery emulation capabilities.

Additionally, although the underlying NetWare 4.x OS provides the highest level of system integration services of any NOS, the directory service itself is available only on UnixWare, Novell's formerly owned Unix subsidiary.

NDS is exceptionally well-architected, offering 15 levels of resource segmentation and flexible replication options. This lends itself to incorporation in complete, top-to-bottom corporate infrastructures that support millions of users and resources. However, because there are few services for joining multiple directory trees dynamically, these trees must coexist on the network with duplicated accounts and security restrictions.

Still, NDS was the only directory we tested that provides a Web-based view of the directory. However, this directory is not searchable, and offers only rudimentary information about the data in the directory.

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.

Banyan's Self-Managing StreetTalk For Windows NT

PROS: Self-managing directory; good third-party support; broad client base; wide server platform support; platform-neutral directory interfaces; "Universal StreetTalk" source code available; "home" servers; "aliased" resources; support for X.500 attributes; integrated message transport services

CONS: No device management; incomplete service management console; client interfaces are non-native; three-part naming hinders superscalable distribution of resources; no hierarchical joining of directories; no support for Domain Name Service (DNS) or X.500 as directory locator protocols

Best Used In: Organizations that need to provide autonomous islands of resources—over which they can maintain authority while preserving enterprisewide accounts and security controls—and that do not have to interconnect directly with other organizations

StreetTalk is the only self-managing directory service we tested. That is, it is the only directory service that automatically adapts to the environment it is running in.

This automatic adjustment ability extends throughout the organizational levels of the directory. If you have offices in New York and Los Angeles running StreetTalk, then as soon as a WAN connection is brought up between them, they will instantly see each others' servers, groups, users and resources. This would be great for an organization that requires global access to autonomously managed resources. But it also puts a serious burden on companies attempting to interconnect their various networks.

Moreover, this sort of scalability just isn't going to work with the two million networks on the Internet. Unless you're a masochist, you probably don't want to attempt automatically cataloging the resources on all these networks. Instead, you would no doubt prefer to use DNS or X.500 as a resource-locator protocol, querying them to find the servers responsible for your specific destination. Unfortunately, this support is not available in StreetTalk, which seriously hampers its potential as a cross-organizational application deploymentplatform. However, as a distributed network service that runs within an organization's internal networks, StreetTalk is tremendously appealing, thanks to its low maintenance and highly adaptable nature.

StreetTalk also has broad client support, letting you use just about any OS you want on your desktop. And it has some of the broadest cross-platform server support of any NOS on the market. There may not be a lot of third-party support for it, but there is enough to realize a modicum of benefits, should you deploy it.

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.

IBM's Directory And Security Server For OS/2 Warp

PROS: Protocol-independent; broad client support; extensible directory; largest server-platform support; Kerberos authentication; robust cell-based architecture; based on trust model that allows for superscalability; uses Domain Name Service (DNS) and/or X.500 directory-locator protocols

CONS: No device management tools; very few third-party applications; non-native client interfaces

Best Used In: Companies that need to build network-centric applications and services that span organizational and platform lines

IBM's Directory and Security Server for OS/2 Warp (DSS) is really two products in one box. It can act as a standalone Distributed Computing Environment (DCE) installation (either client or server), or it can act as a LAN Server-DCE gateway, providing LAN Server users with access to DCE resources.

We looked at it in both lights, and were pleasantly surprised by what we found. DSS brings a tremendous level of networking power to the PC platform, especially in terms of application development.

The DCE environment presents local cells of authority that can be interconnected with other cells, either peer-to-peer or hierarchically. With DSS, these cells can be "real" DCE user databases or they can be LAN Server accounts synchronized into the DCE cell directory server.

The local cells can be connected to another DCE installation by way of DNS or the global X.500 directory, depending on the protocols used by the cell. To access resources in another cell, the server queries DNS or the global X.500 directory for the location of the remote cell's directory server, and then redirects your system to it.

Clients can keep full-blown copies of the directory on local storage, making the network more efficient.

There are DCE clients and servers for practically every major system, ranging from mainframes to Apple Macintosh clients. However, one of DSS' biggest problems is there are no DCE services that run on NetWare, meaning that those accounts are not integrated into the cell.

Another major problem for DCE is that there are very few third-party applications created for it.

These two limitations make DCE a poor choice for an internal directory that's supposed to provide a consistent set of services for network users. But when you consider DCE's interorganizational networking strengths, it wins as the best platform for business-to-business communications (see Unify Your Network Fabric with DCE).

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.

Network Information Service Plus

PROS: Integrated device tracking; integrated user accounts; highly extensible architecture; seamless application security integration; backward-compatible with Network Information Service (NIS); leverages Domain Name Service (DNS), X.500 and CDS for interorganizational communication

CONS: Few third-party products; poor service management tools; not as widely available as NIS; poor client availability; poor server availability on non-Unix platforms

Best Used In: Environments that are heavily Unix-oriented, especially large Solaris installations (NIS+ is not widely supported outside of the Unix space, and even then most of the third-party support is for NIS, not NIS+)

Network Information Service Plus (NIS+) is a new version of the widely installed NIS. It provides a secure, robust and highly distributed repository of information about network resources. Gone are almost all of NIS' limitations that made it unusable across organizational lines.

Although NIS+ servers will support legacy NIS clients and servers, the two are not completely interoperable. This would be irrelevant if it weren't for the vast number of NIS servers on the market. No third parties offer NIS+ services yet, forcing you to implement a mishmash of NIS+ master servers and NIS backup servers.

It should be noted that NIS+ servers do support aliased entries, enabling remote NIS+ resources to appear as local NIS resources. This can eliminate much of the pain in transitioning from NIS to NIS+. But, then again, creating and managing hundreds of aliased user accounts and resources is an unlikely prospect at best, so this service has limited functionality.

One of NIS+'s advantages over other directories is that it has no concept of a fixed data type. Though designed to provide replicated networkwide access to system files such as /etc/passwd, it is capable of making any text file available as a network service. NIS+ also takes advantages of its "invisible" nature, a direct result of its tight integration with the underlying operating system. When a service needs to authenticate a user, it simply asks the OS if the user has rights. The OS, in turn, queries NIS+.

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.

Putting LDAP In Perspective

Although some see the Lightweight Directory Access Protocol (LDAP) as a panacea for all directory service ills, emerging LDAP products will play a more limited role, albeit a valuable one.

LDAP is a slimmed-down way to provide directory access, and its widening acceptance means browser users will have unprecedented access to directories across the Internet and intranets. But LDAP and directories supporting its API don't effectively address the application's limitations of today's directories, and a battle looms to determine the rules of replication and communication among directories that include the LDAP API.

LDAP-based directories one day may be able to address tasks such as identifying the closest printer to a user—just as they are now commonly touted for their user account and e-mail address lookup capabilities—independent of the directory underneath the LDAP interface. Getting to this point will require that directories be able to communicate with each other, however, something that the current LDAP standards do not allow for easily. Right now, LDAP does not provide a directory-independent set of directory element identifiers, meaning that NDS clients could not communicate with NIS+ servers without the client being explicitly aware of the NIS+ directory format. Getting to where there is a consistent representation of the directory is just the first of many steps needed before LDAP can be useful as a directory-independent lookup protocol.

Single-user sign-on also lies beyond the purview of the protocol. There is no security mechanism within LDAP that lets the protocol determine whether the user submitting the request is authorized to do so. Although most would agree that this is not a function of the protocol but instead a function of the directory, there are no agreed-upon standards for the exchange of user credentials between directories. Although you may use Kerberos authentication on your local network, the remote directory may use RSA certificates instead.

Although LDAPv3 was expected to be approved as a proposed standard at the Internet Engineering Task Force's (IETF) December meeting, the issue of how servers supporting it will interoperate remains unresolved. Tim Howes, at Netscape Communications Corp., says he expects Netscape to submit IETF drafts on issues such as server-to-server replication and that vendors other than Netscape will support those drafts.

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.

Where is LDAP Heading?

Netscape Communications Corp.'s Tim Howes is Interviewed by Christine Hudgins-Bonafield

Q: Does the industry still lack standards for server-to-server LDAP support, including replication? From what I can discern, it will be very difficult, if not impossible, to get any near-term agreement on a replication standard. If I'm incorrect, would you let me know when you expect agreement to be reached on this issue and what the standard is likely to be?

A: You are correct. Netscape is planning to publish our replication solution as Internet Drafts very soon. I've talked to several vendors that are planning to implement what we've done, but I'm sure there will be some controversy, as well. Whether what we've done can be taken into the standards process remains to be seen.

Q: I'm trying to get an appreciation of what LDAP can and cannot do. I'd like to know the number of verbs in LDAP at this point.

A: Here they are: bind, unbind, search, compare, add, delete, modify, modify RDN and abandon. LDAPv3 adds two verbs, one to set a session control and one to transmit an extended operation.

Q: What is the status of Netscape's own LDAP directory?

A: Netscape Directory Server 1.0 on Unix was officially released November 1. Our NT version of the same product went into public beta on November 11; it is scheduled to be released in production by the end of the year.

Q: It's been suggested that LDAP-based directories will solve problems such as helping a user locate the nearest printer and then, independently of the particular OS in use, deliver a print message to that printer automatically through the directory. I don't see this kind of capability in metadirectories today and am a bit skeptical that it's inherent in directories based on the LDAP API. Am I accurate on this point? How long do you think before LDAP will be used in this fashion, if ever?

A: Sounds kinda goofy to me. LDAP is a directory service. It does not do printing, though it might be used to locate printers in an OS-independent way, and store an attribute that provides information on how to access the printer. This part of the process can be OS-independent, but the actual print queue—such as, where what you want printed gets sent and how it's handled once it gets there—would not have anything to do with LDAP.

LDAP can certainly have a role in the printing process, as I described above, but it's a directory, not a print service. While one could imagine a system that tied these two things together, I don't think that would be a good thing.

Q: What are the most important elements still to be defined regarding LDAP, and when do you expect them to reach resolution in the IETF and in products?

A: I believe the important elements have already been defined in the draft LDAPv3 specification—security, referrals, schema, internationalization and sorting, for example. We are on schedule to approve LDAPv3 as a proposed standard at the December IETF (after which it goes to the IESG, who issues last call on it). Things are going well on the list, but you never know what can happen.

I'd expect to see LDAPv3 products start appearing in the year following, but whether that's three months, six months or 12 months, I really could not say.

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.

-- 30 --
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 1996 CMP Media, Inc. Used with permission.