In an environment that was quickly moving toward standard Internet protocols, LDAP provided an accepted method of looking up remote addresses--assisted by the standardization of LIPS (Lightweight Internet Person Schema). Now, nearly every messaging server offers an LDAP gateway into its internal user directory--while many are becoming directory clients themselves in an effort to off-load user management on network operating systems or other enterprise directories.

Finally, the development of X.509 PKI promised an enterprise-class authentication and encryption service without the hassles of a secure private-key distribution system (the inherent complexity behind systems such as Kerberos). But in order to function, public keys must be distributed efficiently. Ubiquitous directory services, a natural certificate access and distribution mechanism, represent the missing link in the adoption of PKI in the enterprise. In addition to publishing certificates, expect to see CRLs (certificate revocation lists) accessed through the directory. Likewise, online certificate status checks will most likely depend on some sort of directory query (if not in the enterprise directory, on the certificate authority itself). The logical solution is an enterprise directory service in which a user's public key is included with other white pages information in a global address book.

While these various forces make the need for an enterprise directory service obvious, most top-tier network operating system vendors are determined to blaze their own paths toward directory nirvana. By integrating more network applications and services with their own directory services, Microsoft, Novell and Netscape each hope to be the torchbearers of the enterprise directory. Directory solutions within each vendor's network operating system or application suite have clearly benefited from centralized management via directory, but still lack ubiquitous and effective cross-platform support for all enterprise clients and services. This lofty goal is not likely to be reached any time this millennium.

LDAP: Building Bridges
Although the adoption of directory services has increased dramatically, the only truly interoperable directory application remains online white pages via LDAP, such as any Internet mail client's address book. But before wildly waving the LDAP flag, it's worth noting that LDAP is only a small piece of the directory puzzle. In fact, this external directory access protocol is the least common denominator of directory functionality. An effective enterprise directory solution requires not only a standardized access protocol, but standardized global naming and location mechanisms, as well as a common schema--things LDAP doesn't provide.

To date, the concept of the LDAP URL best represents the shortcomings of the protocol. Take this example: ldap://ldap. company.com:389/cn= John Doe,ou=San Francisco,o= Acme Inc,c=US. Locating a particular object in the directory means specifying the DNS name of the LDAP server, the port where that server resides and the X.500-derived naming convention that represents the directory hierarchy. In this case, the URL creates a globally unique, Internet-accessible directory reference. But to do so, it relies upon DNS to locate the directory server on the Internet.

Furthermore, the naming convention behind the directory hierarchy is rooted only within that directory service: In this case, o=Acme Inc,c=US is completely arbitrary. Not even the internal naming conventions are standardized: While most LDAP servers rely on X.500-style hierarchical names, modern LDAP directories also support dc= DNS-based naming conventions (for example, cn=John Doe,dc=sf,dc=acme,dc=com). To be effective, an enterprise directory service must have a standardized naming convention--some sort of service location protocol in which clients can discover directory servers--as well as the ability to locate directory resources from outside the organization, via the Internet.

To use existing LDAP directory services, the search base must be hard-coded into the clients (both browsers and directory-aware application servers). In this respect, LDAP is unlike proprietary directories such as NDS, which have their own bootstrapping protocols. (NDS uses IPX SAPs or NLSP to advertise directory servers to the network.)