LDAP Object Classes and Schemas

On this page

Object Classes and Schemas in LDAP

LDAP object classes and schemas are the foundation upon which directory data structure, integrity, and interoperability are built. An LDAP object class is not simply a label—it is the rulebook for what entries can exist in the directory, what attributes they are allowed or required to have, and how different types of entries relate to each other. The LDAP schema is the collection of these object classes and attribute type definitions, embodying the organizational vocabulary and constraints of the directory. For anyone building, extending, or troubleshooting directory systems, understanding these components is essential for both compliance and stability.

Object Class Categories: Structural, Auxiliary, Abstract

LDAP object classes fall into three categories, each with a distinct role and a strict set of enforcement rules (RFC 4512):

Structural Object Classes: Define the primary identity or nature of an entry (for example, person, organizationalUnit, or device). Every LDAP entry must have exactly one structural object class, either directly or via inheritance. This class establishes the entry’s core type and enforces required (MUST) and optional (MAY) attribute sets. Only a single structural lineage is allowed per entry. Example:
```
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
```
Auxiliary Object Classes: Provide additional, non-primary attributes to entries, such as account extensions or role flags. Multiple auxiliary classes can be attached to a single entry, supplementing the required and optional attributes without redefining the entry’s structural identity. Auxiliary classes are instrumental in safely extending schemas.
Abstract Object Classes: Cannot be used directly in entries. Instead, they serve as inheritance bases for other object classes. The canonical example is top, the abstract root class from which all standard object classes ultimately inherit.

Enforcement:

Only one structural object class (and its superclasses) per entry is permitted by the LDAP standard.
An entry can have multiple auxiliary classes, each extending attribute capabilities.
Abstract classes appear only as superclasses and not in entry objectClass attributes.

LDAP Schema Structure: Components and Discovery

An LDAP schema is an organized collection of definitions:

Attribute Types: Describe the syntax, matching rules, and usage constraints for individual data elements (e.g., cn, sn, mail).
Object Classes: Group attributes, define required/optional sets, and specify inheritance.
Other Schema Elements: Include matching rules, syntaxes, and operational attributes, which influence server behavior and access.

These definitions are stored centrally and exposed through the server’s subschemaSubentry, a special entry accessible via LDAP operations. To review the active schema, a query such as the following can be used:

bash

ldapsearch -b cn=schema -s base '(objectClass=*)' objectClasses

(Note: Syntax and access controls may vary between LDAP servers.)

The schema versioning and publication ensure that clients and administrators can inspect and validate directory rules, supporting safe schema discovery and extension.

Object Class Inheritance, Syntax, and Attribute Rules (MUST/MAY)

Inheritance and SUP Clause

Object classes can inherit from one or more superclasses using the SUP clause. This forms a strict hierarchy where attribute requirements from parent classes propagate down to their subclasses. Every object class, directly or indirectly, derives from the top class. For example, a person inherits from top, ensuring shared constraints.

MUST and MAY Attributes

MUST: Attributes listed under MUST are required for any directory entry assigned the corresponding object class. Absence of a MUST attribute in an entry causes it to violate schema constraints.
MAY: These attributes are optional; they can be supplied if needed, but are not required for entry validity.

Since attribute requirements inherit downward, the net set of required and optional attributes for an entry is the union of all MUST and MAY lists across the assigned object classes and their superclasses.

Example: Inheritance Matrix

For an entry with object classes person (structural) and a custom auxiliary class, the valid attributes would include all MUST/MAY from both the structural class and the auxiliary, plus those from their superclasses (ultimately including those from top).

Safe Schema Extension: Adding Custom Object Classes and Attributes

LDAP is designed for schema extensibility, but reckless modifications can critically compromise directory health. The recommended, standards-compliant extension workflow involves:

Adding, Not Modifying: Always add new schema elements. Never overwrite or alter existing standard or vendor definitions. Destructive modifications may break interoperability, replication, or future upgrades.
OID Assignment: Every schema element, including custom object classes and attributes, must have a unique Object Identifier (OID). OID uniqueness is essential to prevent name collisions across organizations or software. Do not reuse or guess OIDs—register a private arc or consult organizational authority.
Minimal Disruption: Extend by creating new auxiliary object classes to add attributes, or structural classes if defining a new entry type.
Testing and Validation: Validate the proposed schema changes in isolated environments. Confirm that entries can be created/modified as expected and that replication (if applicable) succeeds.
Production Rollout: Use schema files or LDAP operations supported by your server to publish extensions. Monitor closely for issues.

Example: Safe Custom Auxiliary Class

text

( 1.3.6.1.4.1.32473.1.1 NAME 'myAppExtension' SUP top AUXILIARY MAY ( myCustomAttr ) )

This auxiliary class uses a unique OID and inherits from top, safely extending entries without risk of structural collision.

Misconceptions, Warnings, and Implementation Differences

Multiple Structural Classes per Entry:
The LDAP standard (RFC 4512) explicitly prohibits assigning more than one structural object class per entry. Some directory servers may be lax in enforcement, but this leads to non-portable, non-standard directories. Always design for compliance.

Modifying Core Schemas:
Altering standard or vendor schema elements (rather than extending) is strongly discouraged. Modifying existing definitions can disrupt client compatibility, break replication, or undermine upgrades. Use new OIDs and extensions for custom needs.

Attribute Order:
The order of attributes in an LDAP entry is not significant; LDAP treats them as unordered sets.

Implementation Variance:
Some LDAP servers permit deviation from RFC-mandated constraints due to legacy practices or configurability. Building on non-standard behaviors may cause future migration or federation failures—adhere to published standards for long-term stability.

In Practice: Examples and FAQ

How do I define a new object class?

Use the formal schema syntax, assigning a unique OID and naming the class. Specify required and optional attributes, superior class, and type. Example:

text

( 1.3.6.1.4.1.32473.2.1 NAME 'customUser' SUP person STRUCTURAL MUST ( employeeNumber ) MAY ( favoriteColor ) )

How can I view all possible attributes for an entry?

Query the server’s schema (typically via the subschemaSubentry or cn=schema) to inspect objectClass and attributeType definitions. Combine inheritance from the entry's assigned classes to enumerate valid attributes.

What’s the safest method to troubleshoot schema conflicts?

Compare the entry’s objectClass list to structural/auxiliary rules.
Check that all MUST attributes are present.
Ensure no more than one structural object class.
Query the published schema to verify object class and attribute OIDs and definitions.

FAQ/Key Reminders

Each entry must have exactly one structural object class (by direct assignment or inheritance).
Auxiliary classes add, but do not redefine, attribute sets on entries.
Always extend (never modify) schemas; use unique OIDs.
Discover schema via the subschemaSubentry and validate before production changes.
Non-standard schema practices, even if accepted by your current server, undermine cross-directory compatibility.