Cameron Laird's personal developer's perspective on LDAP

Table of contents

What it is

LDAP provides a common way to access different directories.

[X.500 history, ...]

[Protocol, schema, language, directory, meta-directory (1998), ...]

[data management; client-server; ...; poor fit?]

[Not only people. Resources--printers, ...--'nother good example.]

Who's doing it

[Explain poles of UMi and Netscape.]

Netscape has much the most prominent LDAP profile of any organization. It employs [...]; as many of its products as can be (including [...]) are LDAP-enabled; it freely provides a range of LDAP tools, and [...]

[Explain roles of Microsoft and Novell.]

[Explain IBM, ...]

[Refer to published article comparing servers. Explain position of Microsoft's Site Server (3).]

Several organizations expose LDAP directories to the Internet public at large. It's becoming more and more common to point e-mail clients, for example, to such public resources as

How to do it

Language choice

Whatever your domain, use a high-level language. Functional bindings are available for and one of these absolutely should be your vehicle of choice. There are no deep problems using the C API directly, just the usual tedium and wasted motion. Scripting languages are ideal for LDAP; their portability often is a good match for organizational client-side requirements (and more), and there's no performance constraint for all the network-bound LDAP applications I've seen.

Performance tips

I have a large collection of performance results I'll report as 1999 goes on.

getpwnam vs. C-coded LDAP

Digital Unix, mediocre hard disk; 12500+ lines in /etc/passwd and as cn attributes in Netscape 3.0 Directory Server bundled (Berkeley DB) LDAP data store. getpwnam takes 0.03-0.08 seconds. LDAP authentication of single cn is 0.025. Once LDAP connection is properly initialized and bound, lookups of incremental cn-s take under 0.01 seconds.

Where to learn more

We contributed "A beginner's guide to directory development" to the July 1999 SunWorld, and "A Guide to LDAP Servers" two months later. Brian Vincent's comment about it for LinuxToday makes us feel successful: he mentions how confusing it is to start with OpenLDAP (Is an error a problem in generation? Configuration? ...), and that with this article and an OpenLDAP RPM he had a working installation in 45 minutes. That's just what we're after.

Mark Komarinski and Cary Collett wrote an introduction to LDAP for LinuxWorld which complements our treatment. We plan a follow-up in September on schema design, performance, and other intermediate topics. Suggestions are welcome.

In documenting the sl{a,ur}pd server installations, the UMich team sets the context with a level-headed introduction to the key notion of "directory service". My thanks to Jean-Claude Wippler for pointing out this section of the essential SLAPD and SLURPD Administrators Guide.

Topical remarks on LDAP appear in a February 1999 "WebAdmin" column we did for WebServer Online, reprinted as "LDAP Comes of Age" in Server/Workstation Expert.

The leading standard references are

[Standard text. Critique.]

[Explain newsgroups and mailing list. Explain archive for the LDAP mailing list]

[Link to other articles.]

Several RFCs govern LDAP, among which I most often consider

Also important: the draft IETF standard on the C API.

Dave Kosiur wrote one of the nicest introductions to LDAP back in 1996, for SunWorld Online. Rawn Shah does his usual thorough, well-informed, lucid treatment in a series for for LinuxWorld. The first part introduces LDAP; the second counsels creation of a "directory task force" for managing directory development; and ...

Netscape sponsored a good interview with Tim Howes.

Sun.Net is an intriguing example of what LDAP can do.

An article in InfoWorld gives the executive summary on LDAP.

Will the Directory Interoperability Forum take off? 'Beats me. I'm seeking comments from several of the players.

Personal reflections

I'm ambivalent about LDAP. Professionally, of course, I'd like to see it expand, simply because my experience gives me a comparative advantage in the marketplace. However, I'm still not sure which questions LDAP truly answers, and whether other technologies don't provide better ones. At one extreme, for example, it's still unclear to me what the precise advantage is to clients to obtain data through an LDAP interface rather than a more general DBMS. On another side, XML has a lot of attention, and is appearing in applications that are at least technically feasible with LDAP. Will DBMSs and XML squeeze into non-viability the LDAP niche?

Also, LDAP has a little of the feel of ISDN in the USA: for several years now, this was to have been the year of its widespread acceptance. I'm not convinced that we know yet what the key questions are about LDAP. Is the replication challenge holding it back (that's my favorite--to me, it looks as though LDAP won't get replication right before 2000, at the earliest)? Is it the victim of the collateral fog generated by Microsoft's marketeers in their attempts to cover up the poverty of their own directory offerings? Are meta-directory services what people really need? I don't yet know. I know several development teams who say they're ready to enable LDAP interfaces in various products, as soon as customer demand reaches critical levels--but it hasn't happened yet.

"Is LDAP replacing X.500?" It beats me. Keep in mind that LDAP originated as a (lighter-weight) gateway to X.500. They certainly can co-operate technically. Whether organizations understand that, and how they react commercially, is another question (and another one I can't answer).

[my projects: AVF; scripting; portability; usage; replication; sourcing; IMAP?; categories of content]

[pitfalls: strategic decision; negative benefits; polysemy; ...]

[Explain OpenLDAP. Note various bindings (including recent Tcl one).]


Cameron Laird's personal notes on LDAP/claird@phaseit.net
-->