Tangled in the Threads

Jon Udell, January 3, 2000

Real-world LDAP

LDAP is the de-facto directory-services for LANs, intranets, and the Internet. But it's not always clear how to use it.

Last month, Dave Caplinger posed the following conundrum to my newsgroup:

I'm having a hard time figuring something out, and I'm wondering if I'm doing something that simply isn't possible within the design of LDAP.

There are two companies, A, and B. Both have their own internal LDAP directories and other IP infrastructure (DNS, IMAP, etc.). Both use Netscape Communicator for email, and want each others' LDAP info available for "typeahead" lookups. Both use Netscape Communicator, which only lets you define one LDAP server for these lookups.

Users at company A have their Communicators set to query their internal LDAP server, 'ldap.a.com' using 'o=a.com' as the search root. Users at B are set to search 'o=b.com'.

This is a job for LDAP directory replication, right? But as far as I can tell, LDAP replication isn't designed for this. It appears that Netscape's LDAP server (which both companies happen to use) is intended for situations where there is one (and only one) "main" directory, which can be replicated whole or in part to other servers. But unlike with DNS replication, I can't find a way to have the server at A be primarily responsible for 'o=a.bom' and secondarily responsible for 'o=b.com'. Everything I've read seems to imply that There Can Be Only One directory, even if multiple servers own different pieces of it.

A job for replication? Actually, I'd thought that was a job for LDAP referral -- a feature added to version 3 of the LDAP spec to support cascading lookups. But fortunately, there's a real LDAP guru who frequents the newsgroup: Mark Wilcox, a network administrator and author of Implementing LDAP from Wrox Press.

An LDAP tutorial, courtesy of Mark Wilcox

How can you make an email address book, in Dave's case Netscape's, use LDAP for name completion and search multiple roots of a directory?

Dave asked if replication was the solution. Jon thought it might be, instead, referral.

First some definitions for those who are not up to speed on directories.

Replication

Moving entries from one directory server to another. You use replication normally to keep distant directories in synch or to improve directory performance.

Referral

An entry in a directory server points to one or more different directory servers. You could say that a referral is like a symbolic link in UNIX.

Technically the original problem could be solved by either method. However, neither actually works!

Referral fails because, to my knowledge, no popular LDAP client handles referrals correctly. A client will "follow" a referral -- that is, connect to the new LDAP server -- but will not continue a search within the new server. It just retrieves the entry provided by the referral, then stops.

In my book I do show how to properly handle such a referral using the Netscape Java Directory SDK. The code should be available at www.wrox.com. [Ed note: It's here.]

What about replication? It should be possible to store multiple trees in the directory, and use replication to synchronize the directories with each other.

In each LDAP server I would have o=a.com and o=b.com. I should be able to just point an LDAP 3 client at a LDAP 3 server (Netscape DS 3 or later, NDS 8, Microsoft AD) and tell the client to start searching. A client should be able to parse the list of roots, and use that to build a search base (or a collection of search bases) if not given one.

Alas, neither Netscape nor any other client I know of tries to do this. Instead, they force you to set a single search base.

So is there a solution to your problem? I think there are two:

• Build your own meta-directory by developing a server plugin to search both servers for you. The next version of the openLDAP server will enable you to develop plugins with Perl, which I'm hoping to try.
• Develop your own replication tool that copies all of the necessary entries from one server to another into a different branch.

Neither solution is trivial, and in my opinion neither should be necessary.

Thanks for that insight, Mark! Based on this advice, Dave decided to pursue the following replication strategy which, instead of looking like this:

A o=a.com

B o=b.com

Looks like this:

A o=a.com ou=People ou=b.com

B o=b.com ou=People ou=a.com

Dave adds:

I'll have to figure out a way to periodically copy all of B's ou=People entries to new entries like "dn=Joan User, ou=b, ou=People, o=a.com". And copy A's users to B in the same way.

Putting LDAP in perspective

Dave Caplinger followed up this discussion with an extremely thoughtful posting in which he argues, persuasively, that there is not yet any real consensus about how to design and manage a directory tree. Indeed, as Dave points out, there is even confusion about the notion that an LDAP directory is a tree when, in fact, it's not, it's really a graph.

What's the "best-practice" recommendation for a base DN (distinguished name) -- "o=Company, c=US," or "o=corp.com, c=US," or "o=corp.com"? Likewise, what's the best way to organize user data? The common examples, Dave notes, misleadingly recommend that a user's DN should document his or her organizational role, e.g.:

uid=alice, ou=Payroll, ou=Accounting, o=Acme.com

But that means changing DNs when people change departments. That's not only inconvenient. As noted in an excellent article that Dave cites in his posting, it's disastrous when an organization has deployed client certificates that embed the DNs.

Dave concludes:

These situations where the "recommended" method turns out to be not such a great idea really makes me wonder how many people have actually implemented this stuff yet. Sure, it's early in LDAP's life, but have we really learned nothing from prior experience with this problem?

Excellent question, Dave. On reflection, I think part of the problem is that LDAP, like XML, leads us into a new realm of data management where the relevant discipline is object-oriented, not relational. The plain truth is that there isn't yet much experience with managing object-oriented data -- and an LDAP directory is, among other things, a species of object database. We're all newbies when it comes to designing and manipulating data stores whose internal structures are irregular and organic, requiring new search and navigation idioms.

Should we retreat to a SQL data-management discipline? I don't think so. I've long believed that object data is the right tool for modelling many kinds of real-world complexity, especially the kind that arises from the interactions among people and organizations. The rules of this game haven't all been written yet. Although it's probably not much comfort, given that you have a pressing practical problem to solve, pioneers like yourself are going to end up helping to write the rules.

---

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

This work is licensed under a Creative Commons License.