LDAP

Chapter 2, "LDAP," provides an in-depth exploration of the Lightweight Directory Access Protocol (LDAP), a cornerstone protocol for managing and accessing directory information over networks, as standardized in RFC 4511.

This chapter underscores LDAP’s pivotal role in Identity and Access Management (IAM) by enabling centralized authentication, authorization, and related functions such as user provisioning and role-based access control, making it indispensable in enterprise environments like Active Directory and OpenLDAP.

It outlines the evolution of LDAP from its inception as a simplified alternative to X.500’s DAP in the early 1990s (LDAPv1), through its enhanced LDAPv2, to the widely adopted LDAPv3 of 1997, which introduced robust security features like SASL and TLS. The chapter also details LDAP’s hierarchical Directory Information Tree (DIT) structure, key terminology (e.g., DN, RDN, attributes, object classes), and operational mechanisms like search requests and authentication workflows.

Additionally, it evaluates LDAP’s strengths—such as its efficiency in read-heavy workloads and standardized interoperability—and its limitations, including weaker write performance and schema inflexibility.

Key Points

• LDAP's Purpose:
  • LDAP is a protocol for managing and accessing directory information, optimized for read-heavy workloads.
  • It is used for centralized authentication and authorization, and stores data in a hierarchical tree structure.
• LDAP Basics:
  • LDAP is a crucial component in IAM, providing centralized authentication and authorization.
  • Directory services, like OpenDS, can be implemented using LDAP.
  • LDAPv3 is the current prevalent version.
• LDAP Structure:
  • Data is organized in a Directory Information Tree (DIT) with entries identified by Distinguished Names (DNs).
  • Key terms include entries, attributes, object classes, and schemas.
• LDAP Components:
  • DN (Distinguished Name): Unique identifier for an entry.
  • RDN (Relative Distinguished Name): Component of a DN.
  • Attributes: Data held within an entry.
  • Object Classes: Define collections of attributes.
  • OIDs: Unique identifiers for LDAP elements.
• LDAP Operations:
  • DNs and RDNs define the hierarchical structure.
  • Attributes store entry data.
  • Object classes define entry types.
  • Search requests retrieve entries based on criteria.
• LDAP Authentication and Authorization:
  • LDAP clients interact with LDAP servers.
  • Authentication verifies user identity through binding (anonymous, simple, SASL).
  • Authorization determines access rights through role/group lookups and Access Control Lists (ACLs).

This chapter establishes LDAP as a foundational protocol in modern IAM frameworks, balancing its enduring relevance with an analysis of its constraints.

Why LDAP

LDAP is an old protocol and even if LDAPv3 came out in 1997, it is still quite some time back. It is prevalent in the industry right now, but will it be the same in the future?

One major catch is that LDAP is optimized for read-heavy workloads. LDAP directories are designed to handle a high volume of read operations efficiently. This makes them ideal for use cases where data is read frequently but updated less often, such as user authentication and authorization, an essential role of IAM.

LDAP stores data in a hierarchical tree structure, which naturally represents organizational structures (e.g., company departments, employee hierarchy). This makes it easier to manage and navigate relationships between entries.

LDAP is a standardized protocol (defined by RFCs) specifically designed for accessing and maintaining directory information. This ensures compatibility and interoperability between different LDAP implementations.

Nevertheless, there are benefits like centralized authentication and authorization, attribute-based access, replication and redundancy, etc.

Besides its benefits, there are constraints of LDAP too.

Since it’s optimized for read heavy operation, it compromises the writing performance. Applications with heavy write demands may find LDAP less suitable compared to traditional databases.

LDAP schemas define the structure of directory entries and can be inflexible. Changing the schema can be complex and may require downtime or significant reconfiguration.

LDAP does not provide robust transaction support like traditional relational databases, which can be a limitation for applications requiring complex transactional integrity.

What is LDAP

Lightweight Directory Access Protocol (LDAP) is a protocol, a widely adopted protocol (https://datatracker.ietf.org/doc/html/rfc4511) that enables the management and access of directory information over a network, playing a critical role in IAM.

LDAP serves as a crucial component in IAM by providing centralized authentication and authorization services. When a user attempts to access a network resource, an LDAP server can verify the user's credentials and determine their permissions based on the information stored within the directory.

This centralized approach enhances security by ensuring consistent access control policies and simplifies administrative tasks. In addition to authentication and authorization, LDAP supports key IAM functions such as user provisioning and deprovisioning, password management, and role-based access control.

As a result, LDAP is integral to many enterprise environments, supporting systems like Microsoft's Active Directory, OpenLDAP, and various other directory services. Through its efficient and standardized method of handling directory information, LDAP plays a vital role in maintaining the integrity and accessibility of data within an organization's IAM framework.

Directory Service

In a general sense, a Directory Service is a database for storing and maintaining information about users and resources. This information, such as usernames, passwords, and user preferences, allows system and network administrators to control access to applications and resources.

As LDAP is a type of protocol regarding management and access of directory information over a network, a Directory Service can be implemented based on LDAP protocol. For example,

OpenDS, a directory service project started in 2005 by Sun Microsystems, is written in Java following the LDAP standard.

Some Terms

People use LDAP and Directory Service interchangeably. LDAP is the protocol and Directory Service usually implements LDAP for standard compliance.

LDAP Versions

LDAP has evolved over the years with various versions introduced to enhance its functionality and compatibility.

LDAPv1

LDAP was developed in the early 1990s by Tim Howes and his colleagues at the University of Michigan, which is used to access a directory service called X.500. LDAP is basically a simplified or lightweight version of another protocol - DAP (Directory Access Protocol) that was used to access X.500 directory service at that time. As the protocols functionality is limited, it was not widely adopted

LDAPv2

A couple of years later, LDAP version 2 was introduced as an enhanced version of LDAPv1. It provides client-server directory access capabilities and supports simple authentication as well as basic operations like search, add, delete and modify.

LDAPv3

Published in 1997, the third version LDAPv3 became popular and widely adopted. It features some major improvements over LDAPv2, such as enhanced security features supporting SASL (Simple Authentication and Security Layer) and TLS (Transport Layer Security), schema definition and manipulation, extended operations and controls, etc.

Then LDAPv3 was accepted as the internet standard for directory services and remains the latest and most prevalent version of LDAP today. In other words, whenever you see people mentioning LDAP nowadays, it is most likely LDAPv3.

LDAP Directory Structure

LDAP organizes information in a hierarchical tree structure called Directory Information Tree (DIT, and DIT can vary based on the software or directory service provider you use ) and consists of one or more entries. Entries represent real-world objects such as organizations, users, non-user entities (e.g. printer), etc.

Here is an example of an LDAP tree structure.

The tree structure always starts with a root node (also called root DSE, Directory Service Entry), which usually represents the organization. It will then be followed by further levels of entries. Each node is an entry and can be identified by its DN.

The following highlighted a user entry called ‘test1’.

Key Terms

Let’s look at some key terms used by LDAP.

Entry

A single record in the LDAP directory. Each entry is identified by a Distinguished Name (DN) and contains a set of attributes.

Attributes

Properties or characteristics of an entry. Each attribute has a type (or name) and one or more values. Common attributes include cn (common name), sn (surname), mail (email address), and uid (user ID).

Object Class

A definition of a type of entry in the directory. Object classes determine the mandatory and optional attributes that an entry must or can have. For example, the person object class might require cn and sn attributes and allow mail and telephoneNumber attributes.

Object Identifiers (OIDs)

An object identifier (OID) is a string that is used to uniquely identify various elements in the LDAP protocol, as well as in other areas throughout computing. OIDs consist of a sequence of numbers separated by periods (e.g., “1.2.840.113556.1.4.473” is the OID that represents the server-side sort request control).

Schema

The set of rules that define the structure and content of the directory. The schema includes definitions of object classes, attribute types, syntax rules, and matching rules.

LDIF (LDAP Data Interchange Format)

A standard plain text data interchange format for representing LDAP directory content and update requests. LDIF conveys directory content as a set of records, one record for each object (or entry). It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.

Bind

An operation that authenticates a client to the LDAP server. The bind operation establishes the identity of the client and sets the security context for subsequent operations.

Search

An operation that retrieves entries from the directory based on specified criteria. The search operation can include a base DN, a search scope (base, one-level, or subtree), a filter, and a list of attributes to return.

ACL

A list that specifies permissions or access rights to directory entries and attributes.

SASL (Simple Authentication and Security Layer)

A framework for adding authentication support to connection-based protocols. LDAP can use SASL for various authentication mechanisms, providing greater security and flexibility.

LDAPS

When LDAP is added with TLS (Transport Layer Security), it adds a layer for securing communications over a computer network. LDAP can use TLS to encrypt data transmitted between the client and server, ensuring confidentiality and integrity.

Acronyms

There are acronyms like dn, cn, rdn, ou, etc used in LDAP and it’s important to know them as well.

DIT (Directory Information Tree)

The hierarchical structure in which directory entries are organized. The tree starts from a single root and branches out into various organizational units and entries.

DN (Distinguished Name)

A unique identifier for an entry in the directory. The DN specifies the entry's position in the DIT and is composed of a series of Relative Distinguished Names (RDNs). For example, uid=test1,ou=people,ou=identities

RDN (Relative Distinguished Name)

A component of a DN that identifies an entry relative to its parent entry. An RDN typically consists of one or more attribute-value pairs.

CN (Common Name)

An attribute type typically used to represent the name of a person or object. Example: cn=John Doe.

UID (User ID)

An attribute type representing a unique identifier for a user. Example: uid=jdoe.

DC (Domain Component)

An attribute type used to represent components of a domain name. Example: dc=example,dc=com.

OU (Organizational Unit)

An attribute type used to represent a division within an organization. Example: ou=Marketing.

O (Organization)

An attribute type representing an organization. Example: o=Example Corp.

C (Country)

An attribute type representing a country. Example: c=US.

L (Locality)

An attribute type representing a locality, such as a city or town. Example: l=San Francisco.

How LDAP Works

DN and RDN

To identify an entry in the LDAP tree, we use what is called the Distinguished Name (DN). The DN is globally unique within a directory and represents the exact position of an object in the tree. It is constructed by combining the name of the entry with the names of its parent nodes, continuing all the way up to the root. In other words, the DN is the full path of the object within the tree.

Let’s revisit the tree diagram as shown below and take a leaf node ‘sales1’ (also an entry) as an example.

To traverse from root entry (dc=example,dc=com) to the target entry (cn=sales1), we will first hit ‘dc=example,dc=com’, then ‘ou=sales’, and lastly ‘cn=sales1’.

Here ‘dc=example,dc=com’, ‘ou=sales’, and ‘cn=sales1’ are RDNs (Relative Distinguished Name).

To build the DN of ‘sales1’, we simply reverse the order of traversed entries and concatenate them with commas (no space in between), which becomes ‘cn=sales1,ou=sales,dc=example,dc=com’. This will be DN of that ‘sales1’ entry and it’s globally unique, because there is only one way to traverse from root DSE to the target entry based on the LDAP tree structure.

Each RDN in a DN represents a level in the hierarchy and if you remove an RDN from a DN (starting from left side), you get the DN of the entry considered parent of the former DN.

For example, ‘ou=sales,dc=example,dc=com’ is the parent entry of ‘_cn=sales1,ou=sales,dc=example,dc=co_m’; vice versa, ‘cn=sales1,ou=sales,dc=example,dc=com’ is the child entry of ‘ou=sales,dc=example,dc=com’.

Attributes

Attributes hold the data for an entry. Each attribute consists of an attribute type, zero or more attribute options, and a set of values that represent the actual data. Attribute types are schema elements that define how attributes should be managed by LDAP clients and servers.

Every attribute type must have an object identifier (OID) and may have one or more names that can be used to reference attributes of that type. They also require an attribute syntax, which specifies the type of data that can be stored in attributes of that type, and a set of matching rules, which determine how comparisons should be made against attribute values.

Additionally, attribute types may indicate whether an attribute can have multiple values within the same entry and whether the attribute is intended to store user data (a user attribute) or to be used for the server's operation (an operational attribute).

Operational attributes are typically used for configuration and state information. Attribute options are less commonly used but can provide metadata about an attribute. For instance, attribute options can be used to offer different versions of a value in various languages.

Object Classes

Object classes are schema elements that define collections of attribute types associated with a particular type of object, process, or other entity. Each entry has a structural object class that specifies the kind of object it represents, such as information about a person, a group, a device, or a service. Additionally, entries may have zero or more auxiliary object classes that provide extra characteristics.

Like attribute types, object classes must have an object identifier (OID) and can also have one or more names. Object classes may specify a set of required attribute types, meaning any entry with that object class must include those attributes. They may also list a set of optional attribute types, which entries with that object class may include at their discretion.

Below is an example of an object class named ‘inetOrgPerson’.

Object Identifiers (OIDs)

An object identifier (OID) is a unique string used to identify various elements in the LDAP protocol and other areas of computing.

OIDs consist of a sequence of numbers separated by periods (e.g., "1.2.840.113556.1.4.805" is the OID for the subtree delete control). In LDAP, OIDs identify schema elements (such as attribute types, object classes, syntaxes, and matching rules), controls, and extended requests and responses.

For schema elements, user-friendly names may also be used in place of OIDs.

Search Request

A search request in LDAP usually consists of Search Base DN, Scope, Search Filter and Attributes to Return. Additional search parameters include size limit, time limit, etc.

For example, here is an LDAP search request command

The scope is omitted from the above command and can default to ‘subtree’ depending on the LDAP provider.

Assuming the scope is ‘subtree’, meaning all entries under the specified BaseDN, this search will return all entries under BaseDN ‘dc=example,dc=com’ with uid value containing ‘jensen’, where only uid will be displayed for each entry (DN included by default here).

LDAP Authentication and Authorization

LDAP Client

An LDAP client is a software application or utility that interacts with an LDAP server to perform operations on the directory service. These operations typically include searching, adding, modifying, and deleting directory entries. The LDAP client uses the LDAP protocol to communicate with the LDAP server.

LDAP Authentication

LDAP authentication involves verifying a user's identity against an LDAP directory.

Typical steps include:

1. Connection Establishment:
   • The client establishes a connection to the LDAP server over LDAP (port 389 by default) or LDAPS (port 636 by default)
2. Binding:
   • Anonymous Binding: Some LDAP servers allow anonymous binding, where no authentication is required. This is generally used for querying public information.
   • Simple Binding: The client sends a distinguished name (DN) and a password in plain text. This method is not secure unless used with TLS/SSL.
   • SASL Binding: Simple Authentication and Security Layer (SASL) allows for more secure and flexible authentication mechanisms, such as Kerberos, Digest-MD5, or GSSAPI.
3. Credential Validating:
   • The client searches the LDAP directory for the user’s DN based on the provided credentials (e.g., username).
   • If the user is found, the LDAP server attempts to bind with the user’s DN and password.
   • If the credentials are correct, the LDAP server grants access, and the client is considered authenticated.

LDAP Authorization

LDAP authorization determines what an authenticated user is allowed to do.

This typically involves the following steps:

1. User Role or Group Membership Lookup:
   • Once authenticated, the LDAP server or the application queries the directory to determine the user's roles or group memberships. This information is often stored in attributes like memberOf for group membership.
2. Access Control:
   • Access Control Lists (ACLs): LDAP directories often use ACLs to define permissions. ACLs specify which users or groups have access to specific directory entries or attributes.
   • Role-Based Access Control (RBAC): Applications can implement RBAC by assigning permissions based on the user’s role(s) retrieved from the LDAP directory.
3. Policy Enforcement:
   • The application or service enforces access control policies based on the retrieved roles or group memberships. This determines what resources or operations the authenticated user can access.