Learn LDAP - Schema Design Best Practices

#Introduction

Most LDAP problems in production are born at design time: a DIT that doesn't scale, a schema that can't express the data, attributes forced into the wrong types. Episode 28 is about doing it right from the start: how to lay out the directory tree, when to define custom schema, how to allocate OIDs responsibly, and how to migrate safely when the design evolves.

#DIT Design Principles

The Directory Information Tree (DIT) is the skeleton of the directory. Five principles:

• Design for the search patterns, not the org chart — an application that searches (employeeType=contractor) should have a filter-friendly attribute, not a deeper tree.
• Keep it shallow — depth costs nothing to the schema but every search walks it; deep DITs are hard to maintain.
• Use OUs as containers, not groups — ou=people, ou=groups are structural organization; membership is an attribute (member, memberOf), not a position in the tree.
• Distinguish types — a user entry is not a group entry; object classes exist to separate the two, so don't blur them into one entry.
• Document the tree — a written DIT map (like the ones in this series' earlier episodes) is a deliverable, not a nicety.

#Flat versus Hierarchical DIT

There are two main shapes:

Flat DIT — a single container holds everything:

dc=example,dc=com
├── ou=people
│   ├── uid=budi
│   └── uid=siti
└── ou=groups
    └── cn=developers

Hierarchical DIT — containers by department or location:

dc=example,dc=com
├── ou=jakarta
│   └── ou=people
│       └── uid=budi
└── ou=bandung
    └── ou=people
        └── uid=siti

Rule of thumb: start flat. Add hierarchy only when a concrete need appears — a branch to replicate to a regional office, or a subtree with distinct ACLs.

#Defining Custom Schema

The built-in schemas (core, cosine, inetorgperson) cover a lot. When they don't, define your own. A custom object class example:

dn: cn=employeeExt,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: employeeExt
olcObjectClasses: {0}( 1.3.6.1.4.1.4203.666.1.2 NAME 'employeeExt'
    SUP top AUXILIARY
    MUST ( employeeId $ hireDate )
    MAY ( officeLocation $ managerUid $ costCenter ) )

Rules for custom schema:

• One concern per object class — employeeExt holds employment data; don't mix it with network data.
• MUST for required, MAY for optional — strictness at the schema level enforces data quality.
• Extend, don't modify — never edit a standard schema (like inetorgperson); add an auxiliary class that supplements it.
• SUP top for auxiliary classes — as shown; structural classes extend their structural parent.

#OID Allocation

OIDs (Object Identifiers) identify every attribute type and object class. Rules of allocation:

• Never invent ad-hoc numbers — they collide and break interoperability.
• Get your own arc — request an OID arc from your national registry (e.g. the national numbering authority for your country), or use your organization's private enterprise number.
• Structure the allocation — reserve ranges: 1 for attributes, 2 for object classes, 3 for other definitions.
• Document the register — a table mapping OID → name → definition is mandatory for a living directory.

Enterprise OID arc:  1.3.6.1.4.1.<your-enterprise-number>
  .1  attribute types
  .2  object classes
  .3  name forms / matching rules

An OID register is as important as the schema file itself — without it, the next designer has no idea what 1.3.6.1.4.1.12345.1.17 means.

#Data Normalization

LDAP doesn't enforce normal forms like a relational database, but the discipline still applies:

• No duplicate records — a person appears once, as uid=budi; departments, teams, and aliases reference that entry.
• Attributes over entries — a phone number is an attribute of a person, not a new entry under them.
• Avoid repeating the same data — an email in both mail and a custom email2 invites drift; use one authoritative attribute and derive others.
• Case and format — choose one casing convention and matching rule (e.g. caseIgnoreMatch for names) and stick to it.
• Use the standard attributes first — mail, telephoneNumber, title, employeeNumber exist; a custom attribute should be the exception, not the norm.

#Safe Migration

Schema and DIT change over time; the danger is breaking running applications. A migration recipe:

1. Additive first — add the new attribute types and object classes; existing entries still validate.
2. Staging environment — apply schema changes there first, run the application tests.
3. Populate incrementally — backfill new attributes on real entries in batches, verifying each batch.
4. Flip applications one by one — applications switch to the new attribute one at a time; roll back any that fail.
5. Deprecate, don't delete — keep the old attribute for a grace period; remove it only after all consumers have moved.
6. Document the change — schema version, what changed, which applications depend on what, and the rollback plan.

slaptest -u -v

Never change schema on production without a staging test and a rollback path.

#Closing

In this episode 28 you learned schema design best practices: DIT principles and flat versus hierarchical layouts, defining custom attribute types and object classes with the proper structure, responsible OID allocation with a documented register, data normalization to avoid duplication, and safe additive migration with staging and rollback.

Key takeaways:

• Start flat, add hierarchy for reasons — search patterns drive the DIT, not the org chart.
• Extend with auxiliary classes, never edit standards — the built-in schema stays authoritative.
• OIDs need a register — an unregistered OID is a future collision.
• Migration is additive and reversible — stage it, roll it back, deprecate last.

In the next episode, episode 29, we prove the directory is safe: compliance & security auditing — GDPR, PCI-DSS, SOC 2, HIPAA, and the audit workflow.