Directories

Directories are the key to global networking; they're also a major thorn in network managers' sides.

With the advent of multiuser computing systems came the need to control who gets to do what on the system. The need for restraints and controls arose not only for reasons of basic privacy, but also because it's extremely risky to let inexperienced users have access to everything on the system, including critical system files.

On most mainframe and minicomputer operating systems, it's been standard practice for decades that before a new user can gain access to the system, an account must be created for that user. As part of creating the account, the system administrator must specify which file systems, file system directories, and individual files the user can access. This information about the account is then stored in the system's Access Control List (ACL) or an equivalent security database.

At the start of each computing session, the user logs in to the system using the established account name and password. The system then looks up the account in the ACL and checks the user-entered password against the previously stored password to see if they match. If the passwords don't matchor if no such account can be found in the ACLthe user's login attempt will be rejected, in which case, the user may try again, depending upon the established account constraints. If everything matches up, the user will be given access to the systembut only to those system resources previously defined in the ACL.

Enter Networking

As computer networkinganother form of multiuser computingdeveloped and matured, developers of network OSs adopted essentially the same form of security architecture. However, one difference between network computing and the earlier mainframe style of computing is that with mainframes, the "system" (the computing system) is often one big computer (or a cluster of computers acting as one big one) that is time-shared among all users. All the users log in to the same system, and the system knows about each user. It's a clich, but it bears repeating: Mainframe-style computing is a homogeneous, centralized model.

In the network computing model, which typically employs client-server architecture, the system is a complex collection of many different computers, some acting as clients , some as servers, and some as both (as "peers" in other words).

The decentralized form of today's networked computing systems is at once their greatest strength and their major weakness. The ability to add servers and divide up computing responsibilities makes networks inherently scalable and precludes the mainframe problem which is that even the most powerful computer is brought to its knees if you add enough users. But administering a collection of clients and servers can be a challenge, particularly if your enterprise encompasses hundreds or thousands of servers and tens of thousands of users. The administration problem is not due simply to the multiplicity of servers in a networked environment; most client-server applications have their own access control schemes, as well. For example, Oracle Server has its own security system, as do Lotus Notes and cc:Mail.

For users, it's a hassle to have to log in to each server they want to use. To relieve some of the pain, it's possible to "synchronize" passwords, so that users' single passwords are the same for all servers. This reduces the number of passwords users need to commit to memory. But it's still necessary for users to log in to all of the servers they need to access.

A Promise And A Threat

While directories present administrative problems, they are also playing an increasingly important role in client-server computing, particularly as the Internet brings all networks togetheronce you have video conferencing capability, you'll want the ability to reach someone. But even for the more prosaic, nonvideo-enhanced e-mail of today, there are times when you want to message someone but don't know that person's address. So, the strategy with directories must be to take advantage of their strengths, while finding ways to mitigate their drawbacks.

To illustrate the directory problem, consider Novell's NetWare (prior to version 4.0). It used what Novell called the NetWare "bindery" as the security database for NetWare servers. To give someone access to a NetWare server, a network administrator would have to create a user account and define what directories the user should have access to. This information would be stored in the bindery on that server. If there was more than one NetWare server and you wanted the user to have access to multiple servers, you would have to repeat the account-creation process on each server.

Network Users Gang Up

Network managers and administrators have been grappling with directories for almost a decade now, and the problem's been growing as networks have increased in scale. The Network Application Consortium (NAC) is one organization that's been working to change the directory services arena. Founded in 1990, NAC is composed of several dozen major users of networks. The list includes the Australian Bureau of Statistics, Carolina Power & Light, MCI, Nynex, Pacific Bell, Pacific Gas & Electric, the United States Marine Corps, and the University of Michigan. The NAC champions interoperability among diverse computing systems in general, and in the directory services arena, the organization encourages the use of the X.500 standard and the Lightweight Directory Access Protocol (LDAP) that derived from it. (LDAP was developed at the University of Michigan, so I'm not surprised to see the NAC championing it.)

The developers of network OSs have heard the cries from the user community and have taken steps to address the problembut the issue is a big one, and it won't yield easily or quickly.

The term "Access Control List" implies a simple file (perhaps nothing more than a text file) that lists user account names , passwords, and permissions. For many systems, this is all an ACL is. But, driven primarily by the administrative burden created by having a multitude of noninteroperable ACLs, developers have come to envision a directory that would hold all account- related information for all users and resources on a network. This directory could handle user authentication when a user first logs in to the network. Whenever the user wishes to run an application, the application could consult the directory to see whether the user has the necessary permissions. Because of the amount of information it would need to contain and because of the need to organize it in some logical fashion, this directory would probably be closer to a database system than a simple text file.

Some Solutions

Wouldn't life be much easier if there were only one directory and all the various network OSs and applications used it? The company that took the first steps in that direction was Banyan Systems. Banyan's StreetTalk directory is a centralized resource that all Banyan VINES servers in a given network consult for access permissions. StreetTalk is a directory that has an overarching, all-encompassing view of all the servers and users in a VINES network. Users log in once to StreetTalk and thereafter have access to all servers that the administrators permit them to access.

Banyan has expanded StreetTalk's charter by using it to manage other NOSs, as well. Banyan's Enterprise Network Services (ENS) can now manage NetWare, Windows NT, and Unix (Hewlett-Packard's HP-UX and IBM's AIX).

Not to be outdone, Novell developed its own Novell Directory Services (NDS), which debuted with NetWare 4.0. Patterned after the X.500 directory standard, NDS uses X.500-style nomenclature for users and resources.

X.500

Although network vendors are taking some steps toward consolidating directories, most of these initiatives are occurring within the vendor's own product family. But, if we're going to standardize on one directory, which will it be? Each vendor wants its own to be the standard. Vendor-independent standards are what's really needed.

Created in 1988, X.500 was intended to establish a standard for directories. One of the ISO protocols, X.500 is extremely ambitious and some would say over-engineered. X.500 can take some significant computing resources to implement, and for many years , there were debates about whether it could be implemented. Although X.500 directories haven't set the world on fire, the standard has been extremely influential in setting the general direction of directory development ( witness Novell's use of X.500-style naming). Components of the standard include the Directory Access Protocol and Directory System Protocol specifications.

Seeing an opportunity to shed some of X.500's excess baggage, developers at the University of Michigan radically pared down X.500 and produced a "fat-free" version, which has now been standardized as the Lightweight Directory Access Protocol. To be precise, LDAP is a simplified version of the Directory Access Protocol.

As its name implies, LDAP provides a standard way to access and update directory information. In theory, any LDAP-compliant client (an LDAP-compliant Web browser, for example) should be able to access any LDAP-compliant directory, for purposes of adding, deleting, or modifying directory information.

In contrast to X.500, LDAP has proven wildly popular, and most major players in the world of networking have pledged support for the protocol. Some have even shipped such support. Netscape Communications' Directory Server was designed from the ground up as an LDAP-compliant directory. Netscape Navigator is an LDAP-compliant client. Novell recently shipped an NLM that makes NDS LDAP-compliant.

This doesn't make LDAP a silver bullet that solves the world's directory problems, but the standard should promote interoperability between various directories and clients, regardless of the vendor. This doesn't mean that things will necessarily converge on a single directory, however. There's now a multiplicity of directories, and that will continue, but LDAP will make it easier for them to interoperate .

While LDAP standardizes the directory access method, there's yet another problem that directory clients face when trying to access a directory. The client needs to know how to read the directory, which means it needs to understand the directory's schemathe basic organization of the directory. If all goes according to plan, the next release of LDAP (version 3) should include a method for clients to get the schema for any desired directory.

Also, the NAC is pushing the concept of a standard baseline schema, and work is under way to define the Lightweight Internet Person Schema (LIPS).

Are We In Sync?

If the world won't converge on a single directory, perhaps a different approach is needed. One possible approach is directory synchronization. Synchronization involves running some process that looks at two or more directories and gets them "in sync." This process works by adding any entries that are in one directory but not in the other, and replicating any other changes, such as a password change in one account to the corresponding account in the other directories.

NetVision's Synchronicity for NT synchronizes NDS and the Microsoft NT Domain Controller. It brings NT domains under the management of NDS and lets network administrators manage both their NT and NetWare servers from the NWAdmin program. NetVision, which is based in Orem, UT, has also announced Synchronicity for Lotus Notes. (For a review of Synchronicity for NT and Zoomit's VIA, see "Tying Directory Services without Knots," August 1997, page 102.)

Yet another approach is one jointly proposed by The Burton Group and the NAC. They've fostered the idea of a metadirectorya "virtual directory" formed by combining all the information contained in a network's various directories. A metadirectory would allow an organization to manage all of its directories as a whole. The first implementation of such a metadirectory is VIA by Toronto-based Zoomit. [Editor's note: Microsoft acquired Zoomit in 1999.]

Clearly, we haven't reached directory nirvana, yet. But, as the saying goes, a journey of a thousand miles begins with a single step. We've taken quite a few steps (not all of them in the same direction), and we're at least starting to see the lay of the land. We've got quite a way to go, so I hope you're enjoying the sights.

This tutorial, number 109, by Alan Frank, was originally published in the September 1997 issue of Network Magazine.