How would you explain LDAP to a sysadmin who's heard of it and maybe interacted with it, but never really grasped it?
Analogies are fine, but please include some salient technical details to help ground them.
Asked in the spirit of Active Directory explained
I wrote this article a few years ago, which explains the basics of LDAP
LDAP (Lightweight Directory Access Protocol) is an application level protocol that allows clients to interface with compliant directory services for the purposes of manipulating directory entities or querying the directory for information. One of its primary benefits is to provide a standardized interface for systems across multiple platforms.
On most directory systems LDAP is not the only interface available for communicating with the server. Other native interfaces usually exist which could provide performance and other benefits.
The standard concept behind an LDAP session is this:
Queries can be executed as follows:
Because directories can be very distributed and contain an inordinate amount of information, directory administrators are usually given the option to limit LDAP queries to a certain number of results (1000 is a common max for a result set).
Think of it as a database that is organized in a tree, so for example you can have a typical structure of a company organized in a natural way. A top level company, with groups/departments under it and employees at the end, which themself can have multiple properties (like name, telephone, mail, address, etc.). Then tell him that it's also suitable for every other data that is organized in a similar way and that it is accessed by an open protocol from various platforms/languages.
Also, from wikipedia: "A directory is a set of objects with attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached."
That's the most newbie friendly explanation i can think of, without going into technical details.
It is a centralized system aimed to provide fast access to data in where the actual data is structured in a tree like formation. The language you use to communicate with that centralized system is called LDAP, which is just that, a protocol, much like POP and IMAP is a protocol. It has capability of updating and searching data across the tree.
First up, LDAP on it's own is just a protocol, it does nothing unless there is an LDAP server for it to interact with.
It lets you access a directory on the LDAP server; a good analogy would be a paper telephone directory or a directory of services (the latter is probably better). If you want to find somewhere to get your car repaired, assuming you're not familiar with the local garages, you might look up a paper directory of services to find mechanics in your area.
Similarly, LDAP lets you look up information in an LDAP-compliant directory running on a server. Each entry in the directory is an "object" that may have various properties, and an application that interacts with the directory expects things to be formatted in a certain manner. By design it's flexible and extensible, so you're not limited to what somebody else may have thought of.
Going back to the mechanic analogy, the info may be name, address, cost per hour, whether he's known to sabotage your car so he can get extra business off you, size of beer gut, and so on. Car mechanics might be stored in one node of the directory tree, hi-fi repairmen might be stored in another. Each such object type is not required to share the same properties, so some of the info for a car mechanic will not be present on a hi-fi repairman, who will in turn have his own set of unique info that relates solely to him.
It's most commonly used to hold info about users on a network, but in theory you could put anything into it. In a network scenario, we're talking about organisational info about the person, as well as perhaps security info, configuration info for applications, and so on. Because it's all stored centrally, you can easily and flexibly centralise a LOT of info into a single database that's optimised for ultra-fast lookups and is accessible by any compliant application.
