What Is LDAP, and Who Needs It Anyway?

LDAP (Lightweight Directory Access Protocol) is a vendor neutral binary protocol that is used to maintain distributed directory info in an organized way that makes it easy to query. LDAP is great for maintaining role-based permissions and secure authentication in environments with diverse access requirements.

Before you can talk about LDAP, you always have to talk about one other thing:

Content.

At the end of the day, that's what it's all about, right? Whether via an app on your phone, a browser on your laptop, a thick client at work, or otherwise; the thing you are most interested in is content. Whether consuming, creating, manipulating or otherwise, content is the main reason that we interact with technology. In a world where content is king, access to said content is logically paramount, yes?

There's no question that we generally want people only accessing the content for which they are authorized. This is an increasingly complex notion in today's ever expanding landscape of mobile devices, remote access, service oriented architectures, and more. Fortunately there are many ways in which such things can be configured and controlled. One such method has been tried and true for many a year: LDAP.

Ever heard of LDAP? Regardless, I can almost guarantee you've used it.

One of the (many) unsung heroes of our connected lifestyle, LDAP is a protocol for communicating with a database-like tree service. It's something that most people have used, and perhaps even use on a daily basis, without realizing it. Allow me to take a moment to shed some light on our beloved four letter friend.

What Is LDAP?

As defined above, LDAP stands for "Lightweight Directory Access Protocol". It's a vendor neutral, binary protocol that interacts over TCP and UDP. It's used to maintain distributed directory info in an organized, easy-to-query manner. That means it allows you to keep a directory of items and information about them. Think of an email directory where you have a list of users or email addresses and information about them, such as which department they're in, which associated lists they can send to, etc. Or perhaps a user list that also associates full name, phone number, etc. Sound familiar?

LDAP stores this data by way of records which contain a set of attributes. Think of the attributes like fields in a database. The record itself has a unique identifier, a "Distinguished Name" in LDAP parlance, most often seen as "DN." This is the unique bit of each entry, kind of like the path to a file on your file system. Or perhaps more accurately similar to a street address, since postal addresses begin with the most specific bit first (house number, etc.), as do DNs. Each other attribute in the record has a name and a type, as well as one or more values.

The basic layout of a simple LDAP record.

This structure allows for a huge amount of flexibility and correlation of data which makes LDAP beyond useful, and is a large part of what has caused it to proliferate to such a degree. Maybe you want to search a company email directory for all people located in Nashville whose name contains 'Jesse', and you want to return their full name, email address, title and description. No sweat.

An example LDAP record might look something like this:

As you can see from the above, I'd be able to query on the UID, the name, if I know UIDs are names, the type of object (person, in this case), get a list of detectives (as denoted by the ou), which would include this and all other detective records, the location, stored in a dc attribute above, etc. This is, not shockingly, an extremely simple example, but it shows how things are stored and queried, if only the tip of the iceberg. From here the sky's the limit as far as customization and extension.

LDAP Authentication, Authorization & Access Control

This type of structure lends itself extremely well to things like access control and authorization. Which groups is a user in? Only users in the detective group should have access to the clues application, so when someone attempts to log in, ensure they are in the proper group before granting access, etc. The details get complex, but the effect is fantastic.

Okay, so that's the basics of the 'what' of LDAP, but what about the 'how?' How does one get access to all of those handy-dandy records? Well, the process is pretty straight forward from a flow perspective:

1. A session begins with a client binding to an LDAP server (DSA, Directory System Agent), default port 389
2. The client then sends an operation request (often a search or compare request, for example) to the server, asking for a particular set of information. (Is uid holmes in ou detectives?)
3. The server then processes this query, and supplies a response*. (yes)
4. The client receives the response and unbinds, then processes the data.

* Note that the client does not have to wait for this response, and is free to fire multiple LDAP requests in series. The responses can return in any order.

There are, of course, a heck of a lot more complex options and steps in there, TLS, adding and deleting entries, modifying entries and more, but that's the general gist of how transactions flow.

There you have it. LDAP: a lightweight, flexible, robust, broadly used protocol leveraged to access structured information. It's not all sunshine and roses of course, things can get complicated pretty quickly in a large deployment, and there is a heck of a learning curve. All things considered, however, LDAP plays an important role in many modern deployments, and plays it well. So to answer the question...who needs LDAP?

Seems like the answer is "just about everyone."

When an LDAP deployment is misbehaving, people get frustrated fast. With ExtraHop you can get total visibility into LDAP deployments of all sizes, so you can find and fix problems as quickly as possible. See how it works in our interactive online demo.

That's not all. ExtraHop decodes dozens of other protocols that are vital to IT operations, from infrastructure services like DNS, FTP and memcache, to VDI protocols and many, many others. Check out our protocol support page for more.