All directories "basically serve as a way for applications to look up other applications, for people to look up other applications or resources, or for managers to look up reservations or resources," says Dan Blum, an analyst at The Burton Group in Midvale, Utah. On the Internet, the most prevalent directory structure is Lightweight Directory Access Protocol (LDAP).
LDAP was originally created to be a trimmed-down, lower-overhead version of another directory protocol-the international X.500 standard-and is considered to be an easy key to the "white pages" of the network. The distinction between the two has always been that LDAP is incomplete but can be implemented quickly and efficiently, and X.500 has a comprehensive structure but requires a lot of coding.
"LDAP itself is general-purpose in nature. It can support many different types of applications," says Tim Howes, one of the co-authors of LDAP. Howes is now chief technology officer and co-founder of Loudcloud Inc. in Sunnyvale, Calif.
"Today, [LDAP] is often used to provide the e-mail address book functionality of your e-mail client, the phone book application inside your corporate firewall and the authentication and access-control engine behind many of the Web sites you visit," he says. "Many other applications are also possible and in common usage."
The much more complex X.500 directory protocol has been pushed as a standard since the late 1980s, but it has never been fully adopted, at least in part because it initially required so much space on the client side that PCs couldn't really handle it. PC processing has grown enough that this is no longer a problem, but LDAP is still the directory of choice for many technology vendors, and it's at the heart of Windows 2000's Active Directory.
In the early 1990s, Howes, William Yeong and S. Kille created LDAP at the University of Michigan in Ann Arbor. Since then, it has become a standard in 40 countries and is used by many of the world's biggest IT vendors, including IBM, Sun Microsystems Inc. and Microsoft Corp.
What LDAP does well is reduce the amount of data necessary to locate a person, application or device on a network, or even on the Internet. "LDAP directory information is contained in entries composed of attributes [such as name, address or e-mail]," Howes says. "Entries can be arranged in treelike structures for easier administration and browsing." Entries on the network are defined beginning at the country level, then by region, organization, department and individual or group.
LDAP has become the directory access protocol of choice, in part because it was adopted as a standard not long after its introduction. It's also attractive to network administrators, who can decide how to organize access for users, applications and other entities, such as servers.
Because it's a standard and so widely used for accessing directory information, LDAP is finding its way into new types of applications. Metamerge in Oslo, for example, is using its LDAP-based directory product for network provisioning functions that simplify administration.
But LDAP has limitations. According to Howes, it isn't a replacement for file servers, relational databases and the Domain Name System. While it's very flexible and allows network administrators the freedom to reflect the organization of a company in the directory, it still has some problems with efficiency.
Like X.500, LDAP uses geographical, political and organizational constructs from the off-line world to construct the directory. Thus, communication can break down between users in different organizations, even though their directories are based on LDAP.
Consider, for example, a case in which two pharmaceutical companies are working together to develop a new drug, but each uses a different messaging technology. One is a Windows 2000 shop that uses Outlook and Exchange for messaging, while the other uses Lotus Notes and Domino. They have different naming schemes and rules. How can one system securely authenticate users and encrypt messages on another system if it doesn't recognize their naming rules? The problem occurs because public-key infrastructure (PKI) certificates are stored according to the rules of the specific application or directory protocol they serve.
The user name in Microsoft's Active Directory would be firstname.lastname@example.org. A PKI certificate in Active Directory would search for the published key of a Notes/Domino user but wouldn't be able to find it under the naming rules that guide it. So if John Doe wants to send an encrypted message to Jane Smith, his counterpart in the other company, he would have to be on the same e-mail system.
"You can write scripts to overcome the translation, but that requires a lot of work," says Michele Rubenstein, a security expert and president of the Electronic Messaging Association, as well as co-chairwoman of the Global Directory Forum at the World EMA, a consortium of electronic messaging organizations. "You can [also] create a metadirectory to publish [the PKI certificate] in a more usable format for whatever it is that you're doing."
"LDAP also never solved the problem of distributed entry-that is, a person being known by different names throughout the system," Blum says. So if John Doe is part of two workgroups in a company, his e-mail address would be found in two branches of the directory. LDAP doesn't inherently identify this as a duplicate entry.
LDAP's simplicity and openness mean that it has some obvious holes. But even with those problems, LDAP remains one of the most useful directory systems ever built.