Chapter 2
Schema Design and Directory Architecture

Behind every agile directory lies a resilient schema and a thoughtfully architected hierarchy. This chapter demystifies the art and science of directory schema design, revealing how foundational choices unlock flexibility, security, and speed. Uncover the strategic patterns and modern practices that transform static directories into living, business-aligned identity ecosystems.

2.1 Schema Elements and Extension

The Lightweight Directory Access Protocol (LDAP) schema defines the fundamental structure and semantics of directory entries, enabling interoperability and consistency within and across directory deployments. At its core, the LDAP schema comprises three primary elements: attribute syntaxes, attribute types, and object classes. These elements collectively govern how data is represented, validated, and organized. Understanding their distinct roles and interrelationships is crucial for effectively managing existing directory structures and evolving them to meet expanding organizational requirements.

An attribute syntax specifies the format and encoding rules of attribute values, essentially defining the datatype constraints. It can be seen as the low-level building block that determines what kind of data an attribute can hold and how it is stored. LDAP syntaxes cover simple data types, such as strings, integers, and booleans, along with more complex structures like distinguished names (DN), binary data, and case-insensitive strings. Each syntax is identified by a unique Object Identifier (OID), a globally unique string formatted according to ITU-T X.660.

For example, the Directory String syntax supports human-readable text, including UTF-8 encoded characters, often with size constraints. The Boolean syntax restricts values to logical true or false, facilitating binary state representation within entries. Other syntaxes like Integer and Octet String allow encoding of numeric data and arbitrary binary data, respectively.

Correct usage of syntaxes is paramount because improper syntax choice may lead to data inconsistency or failure of directory operations. Moreover, syntaxes are immutable once deployed; hence thorough planning is critical before defining or extending them.

Attribute types are abstractions built on syntaxes to represent discrete pieces of information stored in directory entries. They define the attribute's name, OID, syntax reference, and operational characteristics, such as whether the attribute is single-valued or multi-valued, whether it must be indexed, or if it is user-modifiable.

Every attribute type must be uniquely identified by an OID, which prevents name collisions and ensures global uniqueness. Along with an OID, a human-readable name or names (aliases) facilitate clarity and ease of management. When defining attribute types, designers specify the associated syntax using the SYNTAX keyword, which links the attribute to one of the predefined syntaxes.

Attribute types are further characterized by usage classifications: userApplications for normal user attributes, directoryOperation for internal directory use, distributedOperation for inter-directory operations, and dSAOperation for use by directory system agents. This distinction influences attribute visibility and modification rights.

Mandating or optionally including attribute types in object classes governs the data entries carry. Rigorous definition and documentation of attribute types are indispensable to avoid ambiguity in data representation.

Object classes define the logical schema templates for directory entries, grouping attribute types into sets that characterize particular entity classes or concepts. They represent the blueprint that prescribes the mandatory (MUST) and optional (MAY) attributes that an entry must or may contain.

Object classes are organized hierarchically in a directed acyclic graph, allowing inheritance from one or multiple superior classes. This enables schema designers to reuse common attribute definitions, promote modularity, and enforce consistency across diverse directory entries.

Structurally, object classes fall into three categories:

• Structural classes: Define the primary identity of an entry and govern its position in the Directory Information Tree (DIT).
• Auxiliary classes: Provide additional attributes that can be dynamically mixed into entries to supplement or extend their definitions.
• Abstract classes: Serve as conceptual groupings not intended for direct assignment to entries but facilitate inheritance and specialization.

An example of an object class might be a person class that mandates attributes such as cn (common name) and sn (surname), while allowing optional attributes like telephoneNumber. This formalism guarantees structural integrity and facilitates client applications' understanding of directory content.

Organizational needs evolve rapidly, requiring augmentations to the directory schema to accommodate new data elements, user applications, or security policies. Schema extension involves thoughtfully adding new attribute types, object classes, or occasionally syntaxes, while ensuring backward compatibility and minimizing disruption.

Successful schema extension connotes the following principles:

• OID Namespace Management: Custom schema elements must use OIDs allocated to the organization, either from private branches or assigned arcs from standards bodies, to prevent collisions with existing schema or third-party extensions.
• Modularization: Instead of extending existing object classes directly, it is advisable to create auxiliary classes for optional attributes and define new structural classes only when modeling fundamentally different entities. This modular approach promotes clarity and eases future maintenance.
• Attribute Reuse: Reuse existing attribute types wherever possible to avoid redundant definitions and simplify the schema.
• Versioning and Documentation: Keep detailed changelogs and document schema definitions rigorously, including rationale and usage examples. Version control is critical, especially in multi-site or large-scale deployments.
• Testing in Isolated Environments: Before deploying schema extensions in production, validate them in test directories to ensure no attribute conflicts or violations of directory server constraints.

A financial services firm required LDAP directory entries to represent enhanced customer profiles incorporating risk scores and financial instrument preferences. The existing schema lacked these attributes, so a custom schema extension was developed.

First, attribute types financeRiskScore and preferredInstrument were defined:

attributetype ( 1.3.6.1.4.1.99999.1.1
NAME 'financeRiskScore'
DESC 'Customer Risk Score on scale 1-100'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.99999.1.2
NAME 'preferredInstrument'
DESC 'Preferred financial instrument type'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Here, the OIDs fall under the enterprise arc 1.3.6.1.4.1.99999, ensuring uniqueness. The financeRiskScore uses an integer syntax constrained to single values, while preferredInstrument is multi-valued and string-typed.

Next, an auxiliary object class was crafted:

objectclass ( 1.3.6.1.4.1.99999.2.1
NAME 'financeAttributesAux'
DESC 'Auxiliary class adding financial attributes'
SUP top
AUXILIARY
MUST financeRiskScore
MAY preferredInstrument )

This auxiliary...