LDAP: Necessary but Not Sufficient
I’ve worked with directory services for a large part of my career. For much of that time, the question I heard most often was, "Which directory protocol should my organization adopt?" The choices included X.500, the Novell Directory Service (NDS), DNS, and lots more. Today, the question finally has an answer. Every organization should plan to base their directory services around DNS, which is simple but nonetheless essential, and the Lightweight Directory Access Protocol (LDAP).
The emergence of LDAP is unquestionably a good thing. DNS is great for mapping names to IP addresses, but it’s not great for more powerful uses. LDAP, by contrast, was designed for the more complex uses of a directory. More important, its current or pending support by every vendor in this space, including Microsoft and Novell, makes it the obvious right choice for pretty much every organization.
But don’t get too excited. LDAP is a step forward, but it’s nowhere near the end of the race. To see why, it’s important to understand what LDAP does and doesn’t define. The LDAP standard, created by the Internet Engineering Task Force (IETF), focuses on only one thing: allowing clients to access a directory server. This requires defining a protocol and standards for describing information in the directory, all of which LDAP does. Providing a common way for clients to access multiple directories offers many possibilities, such as standard access to Internet-based services. Microsoft’s decision to build Active Directory around LDAP also opens up what otherwise would likely have been a completely proprietary directory service.
Yet solving only the problem of client access isn’t enough. What you would really like is the ability to combine directory services from multiple vendors in a coherent, cohesive, standard way. Sadly, LDAP isn’t sufficient to allow this. By focusing only on client access, LDAP ignores the problem of defining how directory servers replicate information with one another. Without a standard solution to this admittedly more difficult problem, building a multivendor directory environment will remain a challenge.
Creating a standard solution for replicating information between different vendors’ directory services requires solving at least three problems. First, a protocol must be defined to convey the information. This is fairly easy -- LDAP itself could be used. Much more challenging, though, is the problem of creating standard definitions for the information in a directory service, creating a standard schema. The IETF and others have made some progress in this area, but getting everybody to agree on what kind of data should be in a directory and how that data should look will take some time. Without this agreement, however, replicating information between directory servers from different vendors isn’t possible.
Finally, if we have a protocol that everyone agrees on for server-to-server communication, and if we’ve defined a standard schema for what’s in each directory database, we still face the hardest of the three problems: defining access control information. Directories commonly contain sensitive data, and so every industrial-strength directory service allows controlling who can access that data. This access control is typically expressed in terms of the users and groups that are authorized to read, modify or otherwise work with the information. Defining standards for replicating data across different vendor’s directory services requires somehow standardizing how access control information is represented, too. Yet given the variations in how different operating systems define users and groups, a workable solution to this problem does not appear to be on the horizon.
Here’s what all of this means. Because Windows 2000 requires using the LDAP-based Active Directory, it’s a safe bet that other vendors attempting to sell directory services into the Microsoft environment will face tough sledding. Trying to sell LDAP servers on Windows 2000 will be like selling suits to a dead man -- he’s already got the only suit he needs.
This leaves one more concern: today’s installed base. By far the most important issue here is interworking between Active Directory and Novell’s NDS. If complete LDAP-like standards existed for server-to-server communication, this would be simple. Because they don’t, however, the best Novell can do is create ad hoc mechanisms for synchronizing the two environments. Along with millions of their customers, I hope they succeed in doing this effectively. Call me cynical, but I don’t expect Microsoft to give them much help. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.