OpenLDAP Schemas and Object Classes

Why Schemas Matter in OpenLDAP

In OpenLDAP, schemas and object classes are the backbone of directory structure and enforce the “building codes” for identity data. Every entry, attribute, and relationship in the directory is governed by schema rules which ensure organization, interoperability, and safe extensibility. Understanding how schemas structure directory data—and how object classes define the types and allowed content of entries—is essential for directory engineering, extension, and troubleshooting.

Defining Schemas, Object Classes, and Attribute Types

An OpenLDAP schema is a formal set of rules describing the structure and permissible content of the directory. It answers questions like what kinds of entries can exist, which attributes they must or may carry, and how these attributes are treated by the system.

Per RFC 4512 and the OpenLDAP Admin Guide, the core schema elements are:

• attributeType: Defines an attribute’s name, OID, syntax, and matching rules.
• objectClass: Specifies entry “types,” groups allowed and required attributes, and defines inheritance for entries.
• matchingRule: Describes how attribute values are compared/matched.
• LDAP syntax: Specifies the accepted value format for attribute types.

Most LDAP work centers on attribute types and object classes, but matching rules and syntaxes are also necessary for complete schema operation, enabling reliable searches, comparisons, and value validation.

In practice, every LDAP entry is an instance of at least one object class, and each present attribute must be allowed by a schema-defined object class.

The Anatomy of Object Classes: Structure and Types

An object class groups and constrains attributes for a directory entry and governs how entries are identified and structured. Object classes are formally defined in schema files using a parenthetical syntax described in RFC 4517. A typical object class definition (as it appears in core.schema) looks like:

objectclass ( 2.5.6.6 NAME 'person'
  SUP top
  STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

• 2.5.6.6 – The global OID uniquely identifying the object class.
• NAME 'person' – The string name for human readability.
• SUP top – This class inherits (SUP) from the abstract top class.
• STRUCTURAL – This is a structural object class.
• MUST – Required attributes for this entry type (here: sn and cn).
• MAY – Optional attributes that may appear on entries of this class.

Types of object classes (RFC 4512):

• Structural: Defines the primary type and placement of an entry in the directory (for example, person or organizationalUnit). Each entry must have exactly one structural object class.
• Auxiliary: Adds additional attributes and capabilities to entries, regardless of structural class (for example, extending a user entry with email attributes).
• Abstract: Template classes used only for inheritance, not directly instantiated in entries (the prime example is top).

Why type matters: The object class type determines placement in the directory tree, inheritance, and what attributes or behaviors can be attached. Misassignment can cause schema validation failures.

Attribute Mandates: MUST, MAY, and Attribute Inheritance

Object classes use two fundamental lists to constrain values on entries:

• MUST: Attributes that are required for an entry to be valid. An entry missing any MUST attribute is rejected by the schema.
• MAY: Attributes that can be included or omitted at the admin's discretion.

Inheritance applies: if an object class is derived from a parent via SUP, it inherits all of that parent’s mandatory (MUST) and optional (MAY) attributes. For example, the commonly used inetOrgPerson class inherits attributes from organizationalPerson, person, and ultimately from top, accumulating a superset of allowed and required attributes at each level.

Crucial rule: An entry may only include attributes specified by its active object classes (either as MUST or MAY). Attempts to add unlisted attributes trigger schema violation errors.

Schema Files and Management in OpenLDAP

OpenLDAP schemas are stored in text files—each covering related object classes and attribute types—and located in the schema directory (default: /usr/local/etc/openldap/schema). Management approach depends on configuration style:

• slapd.conf: Schemas are included via include directives in the flat slapd configuration. This is traditional but deprecated in favor of dynamic, runtime configuration.
• cn=config (OLC): Modern OpenLDAP uses a dynamic, LDIF-based model. Schemas are managed under the cn=schema,cn=config DN and can be added, modified, or removed using LDAP operations and tools, without restarting the server.

Adding custom schemas with cn=config involves:

1. Writing a schema definition in LDIF format, defining each new attributeType and objectClass with unique OIDs.
2. Importing the LDIF to cn=schema,cn=config using an LDAP tool. The schema will be validated on load: errors in syntax, duplicate names, or OID collisions cause rejection.
3. The new schema is immediately available—entries can use the new classes and attributes without server restart.

Important note: Some core and operational schema elements (such as object classes and attribute types used by the server for internal purposes) cannot be modified via LDIF or schema file; changing them requires source-level changes and recompilation.

Best practice: Never modify standard shipped schema files. Always place custom schema in separate LDIF files, and ensure changes are tightly controlled and well-documented.

Object Identifiers (OIDs) and Schema Extension Best Practices

Every LDAP schema element—attributeType or objectClass—is identified by a globally unique Object Identifier (OID). OID uniqueness is critical for avoiding collisions, especially in replicated or federated environments.

Best practices for OIDs and schema extension:

• Never invent OIDs or borrow from published schemas.
• Obtain an OID arc for your organization—from a standards body (such as IANA) or designated authorities in your jurisdiction—before defining custom schema.
• Assign OIDs systematically under your organization’s arc; this ensures uniqueness into the future.
• Document all custom schema elements and maintain them as separate files or configuration units. Avoid overlapping names or meanings with standard schemas.
• Never alter shipped schema definitions or reuse/overwrite existing OIDs.

This discipline ensures compatibility, smooth upgrades, and prevents subtle directory corruption.

Common Built-In Schemas and Object Class References

OpenLDAP supplies several schema files, each introducing foundational object classes and attributes. Below is a practical reference based on official documentation:

The most frequently used classes in real-world deployments are:

• inetOrgPerson (base user with extended personal and organizational attributes)
• organizationalUnit (OU containers)
• groupOfNames (for representing groups)
• person and organizationalPerson (intermediate types)
• account, posixAccount (system or Unix user accounts)

Each class’s inheritance and attribute model matches the RFCs for maximum compatibility with directory-aware software.

Common Pitfalls and Misconceptions

Misunderstanding schema rules is a frequent source of troubleshooting pain:

• Multiple structural object classes: Each LDAP entry may have only one structural object class; you cannot assign more (attempting to do so yields strict schema errors). Auxiliary classes may be added freely.
• Adding arbitrary attributes: Only those attributes listed in MUST or MAY for the entry’s assigned object classes are allowed. Any non-sanctioned attribute is rejected.
• OIDs as arbitrary numbers: OIDs are not arbitrary. Assigning/borrowing an OID without proper authority, or duplicating an OID from another schema, causes interoperability and upgrade problems.
• Editing operational/core schema directly: Standard shipped schemas—and especially operational attributes or classes—should never be modified in place. Safe extension requires using custom schema files or LDIFs in a way that preserves vendor support and upgradability.

Sources

• www.rfc-editor.org — rfc4512
• www.rfc-editor.org — rfc4517
• www.ietf.org — rfc4519.html
• www.openldap.org — schema.html