With directory services, you're supposed to be able to find anything, anywhere. Do they work?
Paul Korzeniowski
A network is a haystack. The printer you want to send your file to is a needle. If the haystack has two or three straws, no problem. But have you ever seen a pint-size haystack?
The key to needle hunting lies in an effective directory system that can locate and identify users, servers, files, and other resources. But it's not simple -- the problems with administration and synchronization alone often appear insurmountable, and competing standards form another haystack as nightmarish as your network. The solution may lie with the ISO's X.500 specification. But until X.500 gains more acceptance, you're left with directory systems that often weren't designed to handle the load they carry.
The Administrat
ive Nightmare
Many users never get beyond their own network's neighborhood and don't realize there's a problem. For them, everything works fine. Not so for the network administrators, who maintain the directories that store user names and addresses in flat-file structures or DBMSes. As users join, leave, or move, each change requires a directory update.
With networks growing, the number of directories has also skyrocketed, and manually monitoring a dozen or more directories is time-consuming, impractical, and prone to error. There's also a time lag. In many organizations, technicians enter new information only weekly or monthly. Until the next update, the network is vulnerable to security breaches.
Most companies want to automate the updating process, but automation raises complex technical problems and trade-offs. "Directories are one of the most difficult issues to solve because they touch applications, networks, and users," notes Aaron Con, a product manager for Microsoft Ex
change (Bellevue, WA).
What's in a Name? Or a Directory?
Most companies want at least one global directory of all users, plus smaller directories throughout the network. How much global information should be stationed in the remote directories? As more information is stored, response times slow. For vendors, the challenge is to create a structure that's flexible but fast.
Also, vendors have to include mechanisms to ensure that each directory is aware of any change; this process is called
directory synchronization
. As networks grow, so do synchronization problems. Maintaining changes on a network with two dozen directories and 10,000 users can bring the system to its knees.
What's worse, today we rely on directories for sophisticated tasks such as network security. Consequently, they need to be flexible enough to support a wide range of uses.
"The major issue companies face with networks is cost of ownership," says David Eckert, the NetWare Director
y Service (NDS) product manager at Novell. "Without robust directory services, a technician can service only 100 or so users. With robust services, he can handle 500."
The Gallup Organization (Lincoln, NE) supports 2000 users worldwide. In 1992, the company began to build a WAN. Tim Gilkerson, Gallup's director of worldwide network operations, says the organization examined Banyan Systems' Vines and NetWare. "We determined that Vines was easier to maintain and required fewer technicians than NetWare."
Then, NetWare supported only simple directory services with its bindery, which stored addressing information on one stand-alone server. A technician had to relay each change to all network directories. Banyan's StreetTalk directory service automatically transmits changes to servers.
With distributed directories, a user can walk up to any machine on a network, enter a password, and begin working. With stand-alone directories, users can access information only when they are connected to a part
icular server. "Many employees travel, so we wanted to make it easy for them to work on the road," Gilkerson says.
Banyan is offering directory services to NetWare users, and Novell is trying to catch up. With NetWare 4.0, the company added a robust global-naming service. Novell's Eckert notes that the service lets technicians divide directories however they wish.
Microsoft has been well behind the other network OS (NOS) vendors in terms of directory services. It offers a rudimentary directory with Windows and plans to add global capabilities with the Cairo release of Windows NT, scheduled for next year.
Directing E-Mail
E-mail suppliers have developed sophisticated directories. Gallup users work with Lotus's cc:Mail and its directory services as well as with StreetTalk. "When we installed our network, cc:Mail was the only robust mail package running on Vines," Gilkerson explains.
The Lotus product features Automatic Directory Exchange (ADE), which automati
cally updates all cc:Mail user addresses. Two years ago, Pathfinder (Waltham, MA) migrated from stand-alone PCs to a NetWare LAN and selected cc:Mail. "Many employees work in third-world countries, so we needed a mail system that supported a variety of transmission types," notes John Talbot, systems manager at Pathfinder. Managing updates to 15 remote directories is simple; ADE automatically transmits each new entry to all locations.
Microsoft Mail 3.0 got distributed-directory capabilities in 1992. It updates E-mail systems, gateways, and personal directories at programmable time intervals.
Multivendor, Multiproblem
The Lotus and Microsoft products keep their own directories in sync. But many companies have multiple E-mail systems to synchronize. Unfortunately, many vendors designed incompatibilities into their directory services. One product may support addresses with three fields of eight characters each, while a second works with four 10-character fields.
One
way to solve this problem is open APIs, as with cc:Mail and Microsoft Mail. Users and third parties can then design translation programs. But few corporations are willing to take on this job. "A company we work with supports 23 different mail systems, so it's looking for ways to minimize directory management rather than take on new chores," notes Con.
These companies turn to third-party tools. For example, Soft*Switch's (a division of Lotus) Directory Synchronization Protocol (DS/P) translates directory information among Banyan, Digital Equipment, IBM, Lotus, Microsoft, Verimation, and Wang Laboratories mail systems.
Most directory-exchange programs offer only the least-common-denominator function set. For instance, one directory system may support authentication, but the synchronizing software doesn't. The result? Good-bye security.
At Prudential Insurance (Roseland, NJ), 50,000 users work with Digital's All-in-1, IBM's OfficeVision, Lotus's cc:Mail and Notes, Microsoft Mail, and Novell'
s MHS mail systems. Prudential had been seeking a directory-synchronization system since the early 1990s, says Randi Mather, an associate systems manager. In 1993, Prudential began testing Lotus's Enterprise Messaging Exchange (EMX). The company found it flexible enough to synchronize Prudential's many mail systems and put it into service in 1994. EMX sends between 100 and 500 administrative and address changes through the system each day. "Since EMX was introduced, Lotus has delivered add-on modules, which have made management of our mail systems simpler," Mather notes.
What Kind of Directory?
EMX is geared only to E-mail systems, so users must maintain other directories. "A LAN OS houses one directory, a mail system has a second, and the phone system operates a third," says Rapport Communications' Dan Blum. "They're all growing, so management is becoming more difficult. Long term, companies want to consolidate all their directories into a single system."
Consolidation
would ease software development as well as user administration. Applications developers often have to build their own directory services. "Developers would prefer to focus on applications features, not basic networking items such as directories," notes Michael Wixon, who is Banyan's director of partnerships.
In April, Banyan unveiled
Universal StreetTalk
, which is a directory service available free of charge to software and hardware suppliers. Cisco Systems, Collabra Software, Oracle, and SAP AG have all indicated they will incorporate it in their products.
While such work represents a step in the right direction, Universal StreetTalk is still proprietary and requires at least one Vines server. Users would prefer a standards-based solution, such as X.500 (see the sidebar "X.500: The Once and Future Answer"). But standards-based technology can be painfully slow. X.500 work was begun in the mid-1980s, and there's still no fully compliant product on the market.
Anothe
r directory service vying for contention is Network Information Services Plus (NIS+), from SunSoft (Mountain View, CA), which is also bundled with Unix OSes from Hewlett-Packard, IBM, Novell, and The Santa Cruz Operation (SCO). NIS+ is built on Sun's earlier NIS (also known as Yellow Pages), which was eventually licensed by all OEM Unix vendors and became the de facto standard for directory services. NIS was itself designed to attack the shortcomings of Domain Name Service (DNS), notably in the areas of database synchronization and security. NIS+ works with Sun's SolarNet and management tools for Microsoft's LAN Manager and NetWare.
Like DNS, NIS+ uses tree-structured hierarchical directories. DNS provided central control of the directory space but also allowed administrative responsibility to be distributed. NIS+ builds on this by giving every organization control over its domain namespace. NIS+ keeps directories synchronized between name servers by transmitting only changes; its predecessor had to se
nd the entire directory map.
The Users Revolt
Historically, vendors developed separate proprietary solutions to network directory problems and then marketed the differences as advantages. Users had to evaluate competing standards and systems, often trading one feature for another.
After a while, big users realized that vendors might not come up with the solutions they wanted. A number of organizations formed the Network Applications Consortium (NAC), which today has 26 members, including Compaq, Nike, Texaco, and the U.S. Marine Corps. During the past few years, the group has met with key suppliers, issued position papers, and tried to forge consensus early in the development cycle.
In April, NAC met with Banyan, IBM, Lotus, Microsoft, and Novell to discuss directory issues. Larry Gauthier, director of network services at the University of Michigan and current NAC chairman, says, "We don't want to end up with another situation like we had a few years ago, when Lot
us was pushing Vendor-Independent Messaging (VIM) and Microsoft was backing MAPI."
The University of Michigan outlined a solution to a critical problem: X.500 is too complicated to run on PCs. The university slimmed down the X.500 client protocol, calling its new protocol Lightweight DAP (LDAP). Lotus's Greg Loux was impressed with the work and said LDAP could become the dominant way for client systems to access X.500 services. However, no vendor now offers LDAP support.
"A lot of users think X.500 will emerge as the solution, but I'm not sure they fully understand the problem yet," notes Novell's Eckert. "There just hasn't been enough customer experience to determine how practical it is to implement and what benefits customers receive from it."
A Series of Compromises
Directory services are generally so entrenched that a company rarely eliminates one, even for a better solution. Instead of trying to cut administrative chores, organizations are more interested in
causing the least disruption for users. Gallup's Gilkerson is interested in using Banyan's Intelligent Messaging but notes the company has a large investment in cc:Mail.
The local installed base -- whatever it is -- exerts a tremendous braking force on efforts to change, to simplify, to standardize. Although the benefits of centralizing directory services are quite clear, achieving and implementing the changes is profoundly difficult and moves with glacial speed. Still, we can do a number of things to deal more effectively with the directory systems we have right now (see the table
"Tips for Managing Multiple Directories"
).
And there's a new factor. Internet access and the World Wide Web are growing at incredible rates, and they don't use X.500 or LDAP. The Internet IP addressing scheme and the Web's complex but widely used uniform resource locators (URLs) are primarily addressing conventions, not directory systems. Still, they're based on the Unix world's DNS. And clearly
, they'll have a big impact on the future of network addressing.
So where will we go with network directories? How will we find out how to address a message to Joe in our Podunk office? For now, the most practical solution is sometimes to call up Joe on the telephone and ask for his E-mail address.
WHERE TO FIND
Banyan Systems, Inc.
Westborough, MA
(800) 222-6926
(508) 898-1000
fax: (508) 898-1755
http://www.banyan.com
Lotus Development Corp.
Mountain View, CA
(800) 448-2500
(415) 961-8800
fax: (415) 961-0840
http://www.lotus.com
Microsoft Corp.
Redmond, WA
(800) 426-9400
(206) 882-8080
fax: (206) 936-7329
http://www.
microsoft.com
Novell, Inc.
Provo, UT
(800) 453-1267
(801) 429-7000
fax: (801) 429-5155
http://www.novell.com
SunSoft, Inc.
Mountain View, CA
(800) 786-7638
(415) 960-3200
fax: (415) 336-2473
http://www.sun.com
-- Identify
how many directories there are in your organization.
-- Determine
how much addressing information is duplicated in the
directories.
-- In the short term,
identify the vendor that has the most directory
links with your current configuration and begin using its tools
to consolidate directories.
-- For the long term,
start learning about X.500 and ask vendors
their X.500 support plans.
screen_link (43 Kbytes)
Banyan's StreetTalk is a widely used, flexible directory service that's also easy to administer.
Paul Korzeniowski is a freelance writer in Malden, Massachusetts, who specializes in networking issues. You can reach him on the Internet at
6841944@mcimail.com
or on BIX c/o "editors."
Needle Hunting
