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

  • 6,838
  • 7
  • 47
  • 66
  • For more detailed information on top of David Pashley's answer below, see http://www.zytrax.com/books/ldap/ – sh-beta Jul 18 '10 at 15:14

5 Answers5


I wrote this article a few years ago, which explains the basics of LDAP

David Pashley
  • 23,497
  • 2
  • 46
  • 73
  • Definitely the most complete answer, but what would you think about copying + pasting the text into your answer? Better search indexing and we avoid future link problems... – sh-beta Jun 11 '09 at 13:58
  • 3
    It's a bit long and isn't under a CC license. The article has been there for three years and I have no plan to lose those links. – David Pashley Jun 11 '09 at 16:39
  • Let's hope it sticks around. Excellent article. – sh-beta Jun 12 '09 at 17:08
  • That article is a gem for those of us who have heard about it but not had the privilege of trying. I haven't finished reading it at this point but from what I've read it's helped adjusted a lot of my newly gained knowledge so far. I hope you keep it up for as long as it remains valid. – Dark Star1 May 08 '12 at 11:53

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:

  1. Connect to the LDAP compliant server
  2. Bind to the directory at some base level (called the BaseDN). This is usually a container object somewhere within the structure of the directory such as an OU. You may or may not be able to bind anonymously depending on whether or not the directory is configured to allow anonymous access
  3. Execute your query or statement

Queries can be executed as follows:

  • within the same level in the structure that you are bound to (a Base scope query)
  • within the same level or one level below where you are bound to (a One Level scope query)
  • recursively down the entire structure beginning where you are bound (a Subtree sceop query)

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).

  • 37,883
  • 12
  • 92
  • 146
  • 1
    LDAP directories are read optimized and typically have poor write performance when compared to SQL like databases. LDAP database can used in a variety of way, but the most typical application (outside of Microsoft AD) is a user/group authentication backend datastore. – Matt Jun 10 '09 at 21:43

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.

  • 246
  • 1
  • 5
  • A solid untechnical explanation, but I think some technical details are appropriate (your audience is sysadmins, not managers). – sh-beta Jun 11 '09 at 13:49
  • Then you should have made your question more clear, i think. That's how i would explain a sysadmin who asked me "Hey, i've heard of thie LDAP-thingie here and there and i took a look at http://wurley.demo.phpldapadmin.info/ but didn't really grasp it." From then on it's as easy as reading wikipedia, tutorials, books or the RFC. – buster Jun 11 '09 at 18:32
  • Question clarified. And I don't think the phrase "As easy as reading [...] the RFC" has ever been written before. – sh-beta Jun 12 '09 at 14:36

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.

Maximus Minimus
  • 8,987
  • 2
  • 23
  • 36