LDAP Terminology and Core Concepts

LDAP: Protocol, Not a Product

LDAP—Lightweight Directory Access Protocol—is an open, standards-based protocol for accessing and managing directory information. It is not a product, server, or specific software package. Instead, LDAP defines how clients interact with directory data, specifying the structure of directory information, the unique identification of objects, and the available operations for querying and modifying that information.

Directory server products such as Active Directory, OpenLDAP, and others implement the LDAP protocol to provide standardized directory services. These products may extend or specialize the protocol’s capabilities, but LDAP itself remains a protocol as defined by RFC 4511 and related standards. Recognizing this distinction is vital when integrating with directories or troubleshooting: you interact with an LDAP protocol endpoint, which may be implemented by various products with differing capabilities and default schemas.

Core Structures: DIT, Entries, and Distinguished Names

Directory Information Tree (DIT)

The Directory Information Tree (DIT) is the hierarchical data model at the heart of LDAP. Entries in a directory are arranged in a tree structure, often reflecting organizational, geographical, or functional groupings. Each branch or node represents an entry, with the tree organized such that each entry has exactly one parent (except the root).

DITs are flexible and can contain multiple naming contexts, allowing parallel roots (such as dc=example,dc=com and dc=corp,dc=internal) to coexist within the same directory.

Entry

An entry is the fundamental unit of directory information. Each entry represents an object (such as a person, group, device, or organizational unit) and consists of a set of attributes. Every entry is uniquely identified by its Distinguished Name (DN).

Distinguished Name (DN) and Relative Distinguished Name (RDN)

A Distinguished Name (DN) is a string that uniquely identifies an entry within the DIT. It is constructed as a sequence of one or more Relative Distinguished Names (RDNs), each representing an attribute-value pair. The full DN traces the path from the target entry up to the root of the DIT, separated by commas, with the entry’s own RDN first (leftmost).

For example, the DN

uid=jsmith,ou=People,dc=example,dc=com

identifies the entry for jsmith in the People organizational unit under the example.com domain. Unlike a username or object name, a DN is a unique, unambiguous locator within the directory tree.

RDNs are the building blocks of DNs. In the above example, uid=jsmith is the RDN for the entry, ou=People for the parent, and so on.

Attributes: Data, Types, and User vs Operational

What is an Attribute?

An attribute in LDAP represents a typed piece of information associated with an entry. Each attribute has a type (like cn for common name or mail for email address) and one or more values.

Attribute Types and Syntax

The attribute type defines not only the attribute’s usage but also its syntax (the rules for representing and parsing values), matching rules (how values are compared), and the allowed multiplicity (single or multi-valued). Syntaxes are defined in the LDAP schema, as are the permissible attribute types.

User Attributes vs Operational Attributes

LDAP distinguishes between user (application) attributes and operational attributes. User attributes contain application or business data—for example, a person’s display name or telephone number. Operational attributes hold directory metadata, such as timestamps ([whenCreated], [entryUUID]), which are used internally by the directory service for replication, auditing, or management.

By default, operational attributes may not be returned in standard queries unless specifically requested, so they are often invisible when browsing an entry. Understanding the difference is important: not all data in an entry is application-visible by default.

Object Classes: Structure and Constraints

What is an Object Class?

Object classes define the schema for LDAP entries. Each object class describes a category of objects (such as user, group, or device) and lists which attributes are mandatory (MUST) and which are optional (MAY) for entries of that class.

Structural and Auxiliary Object Classes

• Structural object classes determine the primary type of the entry and define the required structure. Each entry must have exactly one structural object class.
• Auxiliary object classes provide additional attributes or capabilities that can be combined with a structural class to support extra information.

For example, a person structural class entry might be extended with auxiliary classes to record additional metadata. Object class inheritance enables reuse and composition of schema definitions.

The set of object classes assigned to an entry determines which attributes it must, may, or cannot contain.

LDAP Schema: Governance and Extensibility

What is an LDAP Schema?

The LDAP schema is the collection of object class and attribute type definitions enforced by the directory. Schemas govern:

• Which object classes exist and how they relate through inheritance.
• Which attributes are defined, their types, allowed values, syntaxes, and matching rules.
• Structural rules for entry composition.

Extending or Customizing the Schema

LDAP schemas are extensible. Organizations can define custom attribute types and object classes to model their unique data requirements, provided they assign globally unique Object Identifiers (OIDs) to prevent collisions. However, such extensions must comply with the syntactic and operational rules defined in the LDAP standards.

What Rules Do Schemas Enforce?

Schemas control data integrity and interoperability. They ensure every entry conforms to its declared object classes—both the mandatory and optional attributes, as well as correct value formats and comparison rules.

Core LDAP Operations and Authentication

Standard LDAP Operations

LDAP supports a set of standardized operations defined by the protocol:

• Bind: Authenticate and establish a session.
• Unbind: Cleanly terminate a session.
• Search: Query the directory using filters to find matching entries.
• Compare: Verify whether an entry contains a specific attribute value.
• Add: Create new entries.
• Delete: Remove entries.
• Modify: Change attribute values on an entry.
• Modify DN: Move or rename entries within the DIT.
• Abandon: Cancel an outstanding request.
• Extended operations: Allow for vendor- or implementation-specific commands.

LDAP Authentication (Bind)

LDAP authentication uses the bind operation. Various methods are supported:

• Anonymous bind: No credentials are provided; only allowed if the server permits.
• Simple bind: Username (as a DN) and password.
• SASL bind: Uses the Simple Authentication and Security Layer (SASL) framework to support mechanisms like Kerberos or external authentication protocols.

Access control for directory data is enforced by the directory service, based on the identity established by the bind operation and server-specific authorization policies.

Practical Example: A User Entry Defined

To ground these concepts, consider a typical user entry as defined in RFC 4519:

dn: uid=jsmith,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: jsmith
cn: John Smith
sn: Smith
mail: jsmith@example.com

Annotations:

• dn: The full Distinguished Name uniquely identifying the entry.
• objectClass: Stacked to define the structure and permitted attributes. inetOrgPerson (structural) is the primary object class for a user entry, inheriting required properties from organizationalPerson, person, and top.
• uid, cn, sn, mail: Attributes dictated by the object classes, with uid as the unique login name, cn (common name), sn (surname), and mail as user attributes.

In this entry, operational attributes like entryUUID or createTimestamp would exist but are typically not shown unless specifically queried.

LDAP and Active Directory: Term Glossary and Key Differences

LDAP's protocols and models underpin many directory products, but terminology often differs, especially in the context of Microsoft Active Directory (AD). Key mappings include:

While AD is a directory product that implements (and extends) LDAP, it also introduces its own class and attribute definitions and access controls. The core principles—entries, DNs, object classes—remain rooted in LDAP standards.

Misconceptions and Frequently Asked Clarifications

• LDAP is a product or server: LDAP is a protocol, not a server or directory product. Implementations such as Active Directory or OpenLDAP are servers that speak the LDAP protocol.
• Every attribute is user data: LDAP entries contain both user/application-facing and operational/directory-facing attributes. Operational attributes are essential for the functioning of the directory service but often hidden from regular queries.
• A DN is a user ID or simple name: A DN is a full, globally unique path in the directory tree, not just a username or label. It is constructed from all parent RDNs down to the entry.
• All attributes are visible by default: Operational attributes are not returned by default in queries and require explicit requests.
• Object classes are optional or arbitrary: Object classes define which attributes are required or allowed for an entry. Every entry must conform to its selected object classes.

Understanding these distinctions is essential for proper integration, schema design, and troubleshooting in LDAP-enabled environments.

Sources

• RFC 4512: Lightweight Directory Access Protocol (LDAP): Directory Information Models
• RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol
• RFC 4517: LDAP: Syntaxes and Matching Rules
• RFC 4519: LDAP: Schema for User Applications
• RFC 4513: LDAP: Authentication Methods and Security Mechanisms

Sources

• datatracker.ietf.org — rfc4512
• www.ietf.org — rfc4511.txt
• datatracker.ietf.org — rfc4517
• www.ietf.org — rfc4519.html
• www.ietf.org — rfc4513.html