LDAP - A Primer | Lane Department Help Desk

LDAP - A Primer

I. Introduction

This article is a primer on concepts and usage of the Lightweight Directory Access Protocol (LDAP) implementation OpenLDAP. LDAP is a standardized protocol for providing directory services over a network. A directory service is a database optimized for searching. Data is stored in hierarchical form enabling rapid search and retrieval.

A classic usage example of this model is a phone book – phone numbers can be located by searching for the name of the desired person or business. LDAP is thus quite suited for storing hierarchical information such as names, e-mail addresses, phone numbers, and other information about individuals in an organization. Another example is storing information about a collection of computers in an organization, such as vendor, model, machine location, and IP and MAC addresses.

OpenLDAP executes as daemon and supports many platforms. In this tutorial we will consider the Linux operating system as the host platform. The network shown in the figure below is an example deployment – an LDAP server providing directory services to a database and webserver. This centralized architecture provides an efficient means for services to access directory-style information.

Network with an LDAP server

II. Why Use LDAP?

LDAP provides a centralized, electronic means for storing directory-style information. For example, rather than managing computer accounts for users separately in each department within an organization, LDAP may function as a central directory. Host-to-host data encryption using Secure Sockets Layer (SSL) and Transport Layer Security (TLS) is supported, thus, sensitive data can be protected from prying eyes.

LDAP supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited to the information stored in the directory. Thanks to the existence of a client Application Programming Interface (API), the number of LDAP-enabled applications are numerous and increasing in quantity and quality.

III. Database Structure

The LDAP database stores data in a hierarchical tree, and each node of the tree is a data structure called an entry. Each entry is referenced by a name which is unique within the scope of the database known as the distinguished name (dn). As such, no two entries can have the exact same dn, as they are always unique. Each entry contains one or more data values known as attributes, which store values represented as fundamental data types such as strings and integers. These entries are often divided into different organizational units (ou) which all branch off from a central organization (cn).

The database is known as the Directory Information Tree (DIT). The DIT can be split into two categories: higher and lower. The higher portion of the DIT defines the naming of itself, while the lower half handles organization and the LDAP entries themselves.

The standard naming convention for the DIT can take one of two forms – geographicand domain component naming. It is more common to see domain component naming, however both are equally valid and widely accepted. The domain component breaks the domain name of a website into parts to form the database name. For example, the website “www.example.com” would become dc=example,dc=com. If there are subdomains in the main address, then the domain component expands further, such as dc=subdomain,dc=example,dc=com. As the name implies, geographic naming divides the DIT into categories based solely by location, such as o=organization,c=usa. If using LDAP internally within a company, it’s usually suggested to follow the domain component naming, as the direct mapping from DNSentries to upper levels of the tree make client configuration easier.

Example of ou are ou=People and ou=Machine, for storing user and computer entries respectively. Following the ou in the tree is the final attribute for the entry. Depending on the schema chosen, this could be cn, uid or any other valid LDAP attribute. Examples of a full distinguished name are uid=Jsmith,ou=People,dc=example,dc=comand cn=server001,ou=Machine,dc=example,dc=com.

LDAP Directory Tree

IV. Schemas

The content of an entry is defined by a schema, which is a definition of the attributes the entry will contain. It’s generally accepted to have a different schema for each OU in the DIT. It should be noted that the standard LDAP schemas are derived from multiple postal and telecoms standards and extended by the user to satisfy site-specific requirements. Thus, the standard schemas provide a base for extension. In usage cases where the standard schemas do not satisfy site requirements, it is highly advised against modifying them directly as many technologies and services expect the standard schemas have specific form.

LDAP schemas are defined in RFC 2377 Naming Plan for Internet Directory-Enabled Application as well as in RFC 4519 Lightweight Directory Access Protocol (LDAP):Schema for User Applications. There are multiple built in schemas for LDAPthat are provided on installation. As such, you can tailor your OU’s and entries based on the information you need. You are free to only include the attributes you need in your entries, the rest can be left out, with the exception of required attributes.

Required attributes are defined by the object class(s) that entries contain. There are two kinds of object classes, auxiliary and structural. You can only have one structural object class in your entry unless they inherit from each other. For example (inetOrgPerson → organizationalPerson → person). You must always have at least one structural object class in an entry as well. You can have as many auxiliary object classes as you want. I will go into this in more detail in the future when I discuss actually setting up and configuring an LDAP server. For now here is a reference to some object classes, as well as the attributes they provide and require.

LDAP DIT

V. Basic Operations

There are a plethora of tools and functions to work with LDAP, however the utilities you will find yourself using the most are ldapsearch, ldapadd, ldapmodify and ldapdelete. All of these facilities open a connection to the LDAP server, bind to it, and then perform an operation. The exact mechanism of binding will very depending on theLDAP server configuration. A brief description of these utilities is

ldapsearch searches for and returns entries matching criteria specified by the user.
ldapadd adds new entries to the database from a file or standard input.
ldapmodify modifies existing entries from data specified in an an ldif file.
ldapdelete deletes entries from the database.

Basic functionality of ldapsearch is now discussed. By default ldapsearch will return the entire database unless a filter is specified. For instance, “ldapsearch -xLLL cn=server001” will search for any entry that contains the cn attribute having value server001. Additionally, wildcards (*) can be used to search for attributes matching patterns. For example, say you have a gecos attribute in all of the entries for People inLDAP. This attribute stores the full name of each person. Now, we want to find the uid of a person, but all we know is their first name. We can simply search with the filter “gecos=John*” and that will return a list of every John in the system. Obviously this may not be helpful if there are a lot of Johns in the system, but the more information you have the more specific you can make your filter.

Another use case for the wildcard is to return multiple entries in an effort to quickly grab a set of information. A common example is having four web servers, and each one has its own entry. The entries have names www001,www002,www003,www004. You could simply use the filter “cn=www00*” and it would return all four webserver entries. A final useful note is that if you add the ”+” to a search, it will return operational attributes for the entry instead. An example query with this would be “ldapsearch -xLLL cn=server001 +”. This is very useful if you want to see who or when a entry was last modified.

When adding an entry, it will error out if an entry already exists. This can be overwritten with the -c flag. As an example, an entry such as this could be added with ldapadd -f /path/to/entry:

An image depicting the bash shell command

For more information on these various utilities, it’s advised to see the man/info pages for each command on your chosen Linux distribution. Online copies can be found here- ldapsearch ldapadd ldapmodify ldapdelete. While these are the basic utilities provided with LDAP (often in a ldap-utils or similar package), there are many more programs to interface with LDAP. A very good all around tool is shelldap, which gives you a command line interface to access all of the above operations in a shell like environment. Additionally, you are free to write your own tools, and make use of the many libraries that provide bindings to LDAP in a plethora of languages. An example of this will be shown in a future article.

Conclusion

LDAP can be used to store consolidated information for an entire organization into a central repository. This repository is stored in a manner that fits the DIT (Directory Information Tree) and schema of the LDAP server. The information can be manipulated via add, modify and delete commands, as well as be searched. OpenLDAP provides these tools in the form of ldapadd,ldapmodify,ldapdelete and ldapsearch, but these functions can also be implemented by other programming languages via various LDAP libraries. In the followup to this article, we’ll see how to setup OpenLDAP in Ubuntu 14.04, as well as how to implement a schema that best fits the needs of the organization using it.

References

Contributors: Barry Martin, Terry Ferrett, Marc Seery, David Krovich

Blog