Exchange Standard

Directories, the heart of all corporate networks and the foundation for applications such as e-mail, have created problems for federal network managers who have struggled to keep their disparate directories in sync. To help with this task, vendors have begun moving to a standard called Lightweight Directory Access Protocol (LDAP), which is a method of exchanging directory service information.

A few agencies have found LDAP useful in integrating the directories for competing applications and in allowing mobile users to track down the addresses of others within the agency.

But the sheer number of devices and applications that managers must control so far has made it impossible for vendors to develop a comprehensive LDAP solution. In addition, incompatibilities in the way different directories store information and the lack of LDAP interfaces in popular programming tools are hurdles that may block the road to a successful LDAP implementation.

Put simply, directories act as store lists with the names and addresses of every end user and computer resource— which could be anything from an application to a printer— within an organization. Directories also serve as traffic cops for computers and networks, ensuring that users have the proper credentials before granting them a network connection or access to a resource.

While offering many benefits, directories have been somewhat troublesome for federal agency network administrators. Because of agencies' dynamic nature, directories require ongoing pruning. Employees come and go, new applications are installed, and servers are replaced. The network administrator's task of updating an agency's directories can be complex because most agencies support multiple directories, and large agencies can have dozens or even hundreds of directories. One directory may provide access to a local-area network operating system, a second could open an e-mail application, and a third could work with security.

Unfortunately, directories were not designed to share information, so when an employee leaves, an administrator has to delete the employee's privileges from each directory— a process prone to error. Agencies have longed to integrate directories so that changes made by administrators would automatically be relayed to all associated directories.

Because vendors designed their directory services in vacuums, there is no simple way to connect those services. Standards would help, but they have been slow to develop. In the early 1980s, the International Standards Organization developed the X.500 standard, but agencies found it was too large and complex to be stationed on users' desktops.

Directory Assistance

In the early 1990s, programmers at the University of Michigan in Ann Arbor stripped down X.500 so that it could operate better on PCs. The result was LDAP, which is a standard to enable directories to exchange information. The standard gained a big boost in April 1996 when Netscape Communications Corp., Mountain View, Calif., selected LDAP as the foundation for Netscape's directory services server.

"Once Netscape was on board, LDAP interest took off," said Dan Blum, a senior vice president at the Silver Springs, Md., office of The Burton Group Inc., a market research firm specializing in networking issues. Following Netscape's lead, suppliers such as Hewlett-Packard Co., IBM Corp. and Novell Inc. added LDAP compliance to their products.

Although LDAP has the potential to ease directory administration, few agencies have adopted it. "There seems to be a reluctance among government agencies to invest in a computing infrastructure that does not have an easy-to-determine return on investment," said Ian Goldsmith, a product marketing manager at Isocor Inc., a Santa Monica, Calif., directory services software supplier.

The few agencies deploying LDAP are in the early stages of implementation. The Navy's Space and Naval Warfare Command (Spawar) in San Diego has 8,000 users on a variety of PCs and Unix systems throughout the world. These users access applications that have proprietary directory services: Notes from Lotus Development Corp., Windows NT and Exchange from Microsoft Corp., Novell NetWare, and e-mail systems based on the Internet Mail Access Protocol 4 (IMAP4) standard.

Peter Cruikshank, a systems engineer at the Navy, establishes standards with Spawar and plans to use LDAP to integrate directories. At the beginning of the year, the agency began testing connections between NetWare Directory Services (NDS), IMAP4 e-mail systems and servers running NDS for Windows NT. The connections have been easy to make, and the agency plans to expand its use of LDAP through 1999, Cruikshank said.

"In a few years, we expect LDAP will play a key role in helping us cut down on our directory service management chores," he said.

The Treasury Department's Office of the Comptroller in Washington, D.C., supports 2,800 users with PC servers running Windows NT and the VINES network operating system from Banyan Systems Inc., Westborough, Mass. Messaging has become a key application at the organization, and users work with Banyan's BeyondMail, Lotus' Notes, Microsoft's Outlook 98 and EMC2 from Fisher International Inc., Fort Lauderdale, Fla.

Because they use a variety of messaging packages, users have difficulty exchanging information, said John Gerding, team leader for communications delivery at the Office of the Comptroller. "Two-thirds of our users travel and have no simple way of keeping up with any changes made at the home office," Gerding said. Consequently, a user working with one of the mail systems sometimes cannot easily find the address of a user who relies on another system.

To integrate address information, the Office of the Comptroller connected its BeyondMail and Outlook directories via LDAP earlier this year. Gerding said the installation was simple, but he added that the Banyan product is based on LDAP 2.0, an older version that allows read but not write features between directories. The agency plans to migrate to LDAP 3.0 at the end of the year and eventually integrate all its directories.

Terri Bush, a principal engineer at Science Applications International Corp., worked on a Defense Department project geared toward integrating directories used by 2 million users. The company came on board at the beginning of 1997, after the agency had selected Netscape's LDAP Directory Server. By January 1998, the agency had Netscape's product running on Sun Microsystems Inc. servers in Denver; Chambersburg, Md.; and Fork, Md. Users now are able to use browsers to access information, such as co-workers' e-mail addresses, and the department may expand its use of LDAP in the future, Bush said.

LDAP Lag

Although LDAP-compliant e-mail products have become fairly common, few vendors of other applications have delivered products that rely on standard LDAP, the Burton Group's Blum said.

One reason is that popular programming tools, such as Microsoft's Visual Basic, were slow to include an integrated LDAP interface. Consequently, third parties have had to develop that connection themselves— a task few have been inclined to undertake. Blum said he expects vendors to add LDAP support to their programming tools later this year, and he predicted that the number of applications based on standard directories will grow during 1998.

While vendors have been making progress on the directory front, they still do not offer as much integration as users desire.

LDAP enables directories to move information from one directory to another, but the receiving system may not be able to work with the data once it arrives. A directory stores information using a "schema" feature designed to support specific functions.

For instance, a LAN operating system directory schema may recognize computer devices such as PCs and printers, but it may be unable to work with networking devices such as routers.

Microsoft and Cisco Systems Inc. have led an effort to develop a standard schema dubbed Directory Enabled Networking. In March of this year, the Desktop Management Task Force, an ad hoc standards-making group, took charge of the work and could complete its first cut on the standard by the end of the year.

Yet another problem faced by LDAP users is the prospect that the standard actually could increase, rather than decrease, maintenance chores. "LDAP does not define a replication mechanism," said Michael Simpson, the director of marketing at Novell.

Replication ensures that a change made to one directory is relayed to all other related directories correctly. Vendors such as Novell have included proprietary replication services in their products, so customers can use LDAP to exchange information. But replication can be difficult if all directories have equal power to make changes. To solve that problem, government agencies need a central directory, called a global or meta directory, which would house information for all applications, monitor any changes and relay updated information to appropriate directories.

This has been a goal for vendors for many years, but they have not been able to come up with suitable products. One problem is the wide range of devices and applications that a central directory needs to support. Frank Chen, a group product manager at Netscape, said his company's directory is well-suited to World Wide Web applications, while products from Novell and Microsoft perform file and print functions well. It remains unclear whether vendors will be able to deliver a global directory flexible enough to meet a wide range of performance requirements. Previous attempts have failed.

Observers also have difficulty predicting whether LDAP can improve and transform directory maintenance from a tedious to a trivial task. "In a best-case scenario, vendors will address LDAP limitations in 18 to 24 months," Novell's Simpson said. "A worst-case scenario is five or six years, or it may never happen."

-- Korzeniowski is a free-lance writer in Sudbury, Mass., who specializes in networking issues. He can be reached at paulkorzen@aol.com.

***

AT A GLANCE

Status: A few early implementors within government have begun installing LDAP directory services to make applications and e-mail addresses more accessible to employees.

Issues: The market suffers from a dearth of LDAP-compliant applications other than e-mail, and vendors have been slow to include LDAP interfaces in programming tools.

Outlook: Unclear. Despite the obvious benefits of LDAP compliance, vendors have so far been unable to deliver the global directory solutions needed to make the standard truly workable.