Long, long ago (at least in Web years), in a place far, far away, a guardian of the counting beans assumed a new position. The guardian’s new task was the administration of supplies for the director of manufacturing, a mission sought by all junior-grade members in the bean-counting community.

After initializing her personal cyber-terminal, the guardian supplied the appropriate inputs necessary to access the supply-management system, to which the terminal responded, “Access Denied!”

“How can that be?” the guardian cried. “I’ve made an appropriate application for access to the director of the binary wires. How could it deny me so?”

The guardian immediately picked up her vocal communication portal and punched in the numeric address of the assistance pod. After a short routing period filled with musical sounds of the season, a helpful assistance technician connected to the vocal channel. After describing her difficulty to the technician, the guardian asked what the issue might be.

“Well,” the technician responded, “let me take a look. According to my records, access to that particular functional complex requires 22 separate management definitions, all of which are under the control of different directors. If you would like to remain on the line, I can begin investigating which definition may be in error.”

After some grumbling from the guardian, the technician went on to say, “One option may be to use the access coding assigned to your immediate predecessor. It may then work properly, since it often takes months to remove someone from the system and seldom is that person ever removed completely.”

“Is there a better way?” The guardian asked the technician. “Absolutely,” was the reply, “We could have a directory!”

Is this a common situation in your own environment? Virtually every system, server, application, network device, workstation, and even the voice-mail system, has its own way of defining users and what they are able do. In my own very small shop, we maintain separate user directories in a production Microsoft Windows NT server domain, a test NT domain, four iSeries systems, a separate email system, a remote access server, and several software applications. Adding and removing users is a significant task and often requires a lot of calendar time to get all of the nuances and interrelationships right.

This is, however, not a new issue, and there was a realization in the IT community long ago that a common management point for users, applications, and resources is a good idea. Just think how simple things would be if a departing staff member could be disabled from all company resources, right down to the voice-mail system, with a single entry, in a single location. Such a capability is called a directory. In this article, I will discuss a bit of the directory’s history, outline the current state of the directory, and mention some of the things you might want to be thinking about as you make system and application decisions.

X.500 Gets Things Started

In 1984, a study group that became the International Telecommunication Union proposed the concept of a standardized directory. One of the key reasons for creating a directory was to allow users within an organization and among organizations to easily locate the email address of another individual—and to do so in a standard fashion. It was a dream for worldwide electronic white pages.

The final definition of the X.500 directory standard was published in 1988 and extended in 1992. It defined the databases and protocols that would allow applications and users to communicate within a directory. Another key aspect of X.500 was the ability of directories to connect to each other, which would allow an organization to recognize the authority established by another.

X.500 was a good thing, but it was also a complicated thing. It required specific

databases and was based on the Open Systems Interconnection protocol model (remember that?), and therefore it was not widely used. Although there was still a need for directories, few organizations were willing to take on the challenges of implementing the X.500 standard.

So the Internet standards community, still wanting a set of directory services, yet realizing the complexity of X.500, set out to define an all-IP implementation, known as
X.500 Lite. The result was RFC 1487, which defined the Lightweight Directory Access

Protocol (LDAP). Accepted in 1993, LDAP, unlike X.500, did not define a specific database and the elements within that database; it defined a way of communicating with a directory database and the protocols to be used in such communications. Vendors could now implement directories as they wished, and there could be a common means of accessing those directories. This was a noble concept that created its own set of issues, which I’ll discuss a bit later.

Following quickly on the heels of RFC 1487, in 1995, was RFC 1777, which defined LDAP 2.0. The 2.0 version of LDAP addressed some shortcomings in the original specification, particularly some significant performance bottlenecks.

Despite the improvements in 2.0 LDAP is not static. RFC 2251, which defines LDAP 3.0, was published as a proposed standard. It adds some functionality in the way LDAP addresses security, provides support for Unicode characters, and allows for more extensibility than that which is available in LDAP 2.0.

Then in 1994, Novell rocked the IT community with the announcement of its Netware Directory Services (NDS). Those who understood what NDS meant for a network of servers were ecstatic about the announcement, although many in the community were still wondering what a directory was. With NDS, you could manage all of your organization’s Novell users and resources from a single place. Users were no longer defined individually to each server. Define them to NDS, associate them with the resources they are allowed to access, and all was good. The primary alternatives in the file- and print- sharing segment of the industry at the time were the IBM OS/2 LAN Manager and the Windows NT Server, both of which used a domain management model, not a true directory.

NDS was, and still is, a good thing, but it primarily finds its home in managing a network of shared files and printers. Not many application programs use its services, and Novell only recently made an LDAP-compatible interface available.

The Microsoft Factor

As I have noted, Microsoft used a domain-based user-management system with its NT server product line. The concept was developed for the OS/2 LAN server and was a directory of sorts. The domain directory was not LDAP-compliant and had difficulty operating whenever communication was lost between the server and the domain server (an issue specifically addressed in the LDAP specification). Applications could not use domain services for resource management, so things like email accounts and database authorities had to be defined elsewhere.

Microsoft was taking over a huge share of the server market with Windows, but Novell was still hanging in there, due in part to NDS. I suspect that in the interest of gaining even more market share, Microsoft made the release of Active Directory Services (ADS) a large part of its original Windows NT 5.0 (eventually renamed Windows 2000) server announcement. ADS would now provide the sort of services that were previously available only in NDS, and it would also support standards like LDAP.

But Microsoft needed to address the directory issue in order to compete with Novell, even though one of the positive effects of the ADS announcement was a renewed interest in directories and in the services they could provide an organization.

What’s in There?

A directory is simply a well-defined place to put information about users, applications, and resources. This information is then associated in a way that manages a user’s authority to resources and to the components of an application.

The database of a directory needs to be flexible. It must be able to adapt to the specific needs of the resource as well as the organization. LDAP makes this happen through schemas. A schema is defined and loaded into a directory. Management records are then loaded into the directory using the defined schema. An application or resource can query a directory, using a common API, and determine whether a user is authentic and whether the association (or lack thereof) between a user and a resource is authentic.

LDAP directories are organized hierarchically like an inverted tree. There is a root node, followed by nodes that may represent organizations or applications. The next layer could contain departments or application components, under which another layer could contain users and application functions. The depth of the hierarchy depends on the implementation of a vendor’s schema.

LDAP queries can search up through the hierarchy and back down again in order to locate the appropriate resource information. Through this query mechanism, users associated with one part of an organization can either have access to resources in another part of the organization or have his access limited to only specific parts of the tree.

Variable schemas make LDAP very flexible but can also cause problems. Vendors are free to define their own schemas, and, in fact, Microsoft took some freedom with its definitions within ADS. There was a sort of de facto schema used within many LDAP implementations, including the OS/400’s, that made it possible to at least guess where information might be located, but Microsoft chose to add another unique layer in its hierarchy. Current applications that work with LDAP servers likely will need some modification to operate with ADS.

The Java community recognized the necessity of directories within its standard. A set of classes under the title of Java Naming and Directory Interface (JNDI) supplies a means, from within a Java program, of accessing LDAP directories, as well as other naming services, such as Domain Name System (DNS). JNDI is technically directory- independent, although most implementations rely on LDAP.

LDAP in OS/400

Since V4R3, LDAP has been included free in OS/400 as part of Directory Services for OS/400. Check to see if you have Option 32 of 5769-SS1 installed. If you do, there is an LDAP server available, along with a complete set of LDAP clients and utilities.

The LDAP server uses DB2/400 for storing the directory information and is configured using Operations Navigator. OS/400 commands are not available for managing the server, other than the ones for starting and stopping it. The server is started and stopped either through Operations Navigator or by using the *DIRSRV option of the Start TCP/IP Server (STRTCPSVR) and End TCP/IP Server (ENDTCPSVR) commands, respectively.

The OS/400 LDAP client supports the accessing of any LDAP server from all of the OS/400 ILE programming languages: C, COBOL, and RPG. The standard API set is implemented, so LDAP skills developed in an ILE application will transfer to other platforms. An LDAP client for Windows is included with OS/400 Client Access, and a Java client is included in OS/400’s support of JNDI.

Also included is a set of command line utilities for accessing an LDAP server from Windows and OS/400. These utilities are compatible with the LDAP utilities provided for other operating systems, and they allow you to search, add, modify, and delete directory information.

The OS/400 LDAP server and database are separate from the traditional OS/400 directory, although a replication mechanism is available for keeping either the local LDAP directory or any other LDAP directory in sync with OS/400. The Operations Navigator server properties dialog box contains a Directory Update tab. On that tab is a list of resources that can be synchronized into the directory, one of which is Users. With this option configured, users are added to and removed from the LDAP directory, as the traditional directory changes, by using the Work with User Profiles (WRKUSRPRF) command.

Unfortunately, there is not yet a way—except in a completely custom environment—to use the LDAP directory exclusively within OS/400. I expect this will change at some time in the future as OS/400 moves away from the green-screen. Such a move would also be consistent with IBM’s commitment to Internet standards.

Where ADS Fits

Because of the extreme proliferation of Microsoft servers, many shops will have an ADS server installed at some point in the near future. Doing so places another LDAP server in the environment and replaces the clunky domain-based management system of the NT Server.

The LDAP client in OS/400 could certainly use the ADS server for application security. New applications for the Windows environment will likely use ADS for their security needs, and there may be some opportunity to share a user definition between a Windows application and an iSeries application.

The OS/400 directory also could synchronize with the ADS directory, although I don’t know anyone who’s tried it yet. That could allow user definitions on the iSeries to propagate to ADS for use in other applications. Given Microsoft’s rather unique schema definition, however, I’m not sure it will work.

Another option might be to lobby IBM to include OS/400 support for ADS as the primary directory. Somehow, I don’t believe that will happen soon, but I may be wrong.

A Possible Strategy

LDAP looks like the directory protocol of choice for the foreseeable future. This means that application and platform support for the protocol will expand over time, making it realistic to expect that the use of a single, common directory is an achievable goal.

The first step would be to get comfortable working with LDAP. There are a variety of good resources available on the Web, like Network World Fusion’s Research page for directories (www.nwfusion.com/research/ directories.html). There are also a couple of good books, such as Implementing Directory Services and Understanding and Deploying LDAP Directory Services.

Another step would be to start the server on OS/400, replicate the OS/400 directory into the LDAP database, and start poking around with Operations Navigator or some of the command line tools. That should give you a feel for the structure of a directory and what its possible uses are. There are also a number of directory exploration tools available on the Internet that can supplement the standard ones.

Consider using LDAP for resource management when developing your next application. If you’re using Java, the standard JNDI interface will allow access to an LDAP directory with little or no pain. If your application is in an ILE language, take a look at the LDAP API set. See if it is practical to use the LDAP directory instead of creating your own security mechanism to control access within the application. This could be the fastest way to get a directory into production on your network. Such a strategy may seem difficult initially, but it could pay off in the future.

The addition of LDAP support to many existing directories is making another option practical, that being the concept of a metadirectory. A metadirectory exists as a layer over other directories, typically providing a single user interface that will update the back- end directories based on a set of update rules. This sort of mechanism could keep a series of directories up to date without having to get all applications and platforms talking to a single directory.

Consider asking your application providers what their directory integration plans are. Many commercial products I’ve seen use their own security infrastructures and could simplify the management of their applications through integration to a standard directory. If enough people within the user base ask for LDAP function, there is a good chance of getting it.

Ultimately, standards must prevail. There is some motion in the industry toward a common LDAP schema. As I noted before, there are de facto standard schemas. Vendors just need to get together and settle on a common way. The vendors also need to apply those standards to their products. As always, what Microsoft chooses to do or not do will be the wild card in the standards effort.

Directory support needs to be considered in everything you purchase. That includes devices like phone systems and networking hardware, along with application software and operating systems. Industry initiatives to incorporate LDAP support in traditional hardware devices are underway, and products may become available in the near future.

If you concentrate on developing systems and buying products that support LDAP, it may soon be possible to add a user to every system in your network from a single management point. Likewise, it may be possible to remove or disable that user from a single management point.

The next step beyond implementing directories in your environment is to integrate with other organizations’ directories. The Universal Description, Discovery, and Integration (UDDI) project—supported by IBM, Microsoft, and others—is a comprehensive initiative that should enable businesses to discover each other and to define how those businesses interact over the Internet. Access to directories like UDDI will make B2B e-business applications self-defining yet allow them to remain secure. You can keep an eye on the progress of the UDDI project at www.uddi.org.

A single, common directory will truly be a panacea. It will be simpler to manage and substantially more secure than anything now available. I’d like to write more about it, but right now I have to go to the server room and add a new user to three different directories. Honestly!

REFERENCES AND RELATED MATERIALS

• Implementing Directory Services. Archie Reed. McGraw-Hill, New York City, 2000

• “Introduction to X.500,” Timothy A. Howes, Ph.D., Mark C. Smith, and Gordon S. Good, Cisco Knowledge Suite, May 30, 2000, www.knowcisco.com/matter/ tut1000007

• iSeries 400 Information Center (LDAP): www.iseries.ibm.com/infocenter

• Network World Fusion Research Directories: www.nwfusion.com/research/ directories.html

• UDDI Web site: www.uddi.org

• Understanding and Deploying LDAP Directory Services. Timothy A. Howes, Ph.D., Mark C. Smith, and Good S. Good. MacMillan Technical Publishing, Indianapolis, Indiana, 1999