Learn LDAP - Schema & Object Classes

#Introduction

In episode 2 you saw schema as one of the core concepts of the LDAP data model. Episode 3 breaks it down: what schema is, how attribute types work, the three kinds of object classes, the standard schemas already bundled with OpenLDAP, and the list of the most common object classes and attributes you'll use again and again. After this episode, you'll no longer guess whether an entry is valid — schema decides everything.

#Schema Basics

Schema is the directory's rulebook. Before an entry can live in the DIT, it must pass schema verification. Its four main components:

• Attribute types — attribute definitions: name, syntax, and whether the attribute can be multi-valued.
• Object classes — the set of attributes a given entry type may and must have.
• Syntax rules — define the format of values, e.g. string, integer, or binary.
• Matching rules — define how values are compared during search, e.g. case-insensitive for names.
• Schema enforcement — OpenLDAP rejects entries that violate the schema; this is the key to keeping a directory tidy.

#Attribute Types

Attributes have properties that determine how they're used:

• Attribute syntax — the value type: string, integer, binary, timestamp, and more.
• Single-valued vs multi-valued — attributes like mail can have many values, while uidNumber has only one.
• Mandatory vs optional — required (MUST) and optional (MAY) attributes are determined by the object class.
• User attributes vs operational attributes — ordinary attributes holding business data, versus server-managed attributes such as creatorsName and modifyTimestamp.
• Attribute options — extra markers, such as the language tag mail;lang=id or the ;binary marker.

To learn an attribute's syntax and rules, you can read them from the definition in the schema file:

Definition of the cn attribute in core.schema

attributetype ( 2.5.4.3
    NAME 'cn'
    DESC 'RFC4519: common name'
    SUP name
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

The definition above shows cn as an attribute compared with the caseIgnoreMatch matching rule, using string syntax, and single-valued. This is the concrete form of the schema components just explained.

#Object Classes

Every entry has one or more object classes that determine its shape. Three main kinds:

• Structural object classes — the backbone of an entry; every entry must have exactly one structural class, such as inetOrgPerson or organizationalUnit.
• Auxiliary object classes — supplements that add attributes without changing the entry's fundamental nature, e.g. posixAccount, which adds uidNumber and gidNumber.
• Abstract object classes — used only as a basis for inheritance, never directly as an entry's object class. top is an example.

Object classes support inheritance: a class inherits its parent's attributes. That's why person inherits from top, organizationalPerson inherits from person, and inetOrgPerson inherits from organizationalPerson.

#Object Classes vs Attributes

To avoid mixing them up, let's compare directly:

In short: object classes define the rules, attributes store the values. An entry can have many object classes, but only one structural — the rest are auxiliary.

#Standard Schemas

OpenLDAP ships with standard schemas in the /etc/ldap/schema/ directory:

Each file can be loaded into the cn=config configuration while the server is running — you'll learn how to load them in episode 10.

#Common Object Classes

A few object classes you'll encounter most often:

• top — the base abstract class, parent of all object classes.
• person — a simple person with cn and sn.
• organizationalPerson — a person in an organizational context.
• inetOrgPerson — a modern person with mail, telephoneNumber, and RFC 2798 attributes.
• posixAccount — a Unix account: uidNumber, gidNumber, homeDirectory, loginShell.
• groupOfNames — a group containing member DNs.
• organizationalUnit — an organizational unit like a department.
• domain — a DNS domain representation.

#Common Attributes

Rounding out the object classes, here are the most commonly used attributes:

• cn (common name) — an entry's common name.
• sn (surname) — the family name.
• givenName — the first name.
• mail — email address, multi-valued.
• telephoneNumber — phone number.
• uid (user ID) — the user identifier on an entry.
• uidNumber, gidNumber — POSIX numeric IDs for Unix accounts.
• userPassword — the user's password hash.
• memberOf, member — group membership.
• description — free-form description.

The common pattern for a Linux account in LDAP combines inetOrgPerson (structural) and posixAccount (auxiliary), so a single entry can carry uid, cn, sn, mail, uidNumber, gidNumber, and homeDirectory all at once. This pattern is the foundation of LDAP as an authentication backend.

#Closing

Episode 3 explains the directory's rulebook: schema as the enforcer, attribute types with their syntax and matching rules, three kinds of object classes with an inheritance system, OpenLDAP's built-in standard schemas, and the catalog of object classes and attributes that will accompany your practice in the coming episodes.

Key takeaways:

• One structural object class is required on every entry; auxiliary classes add attributes.
• posixAccount connects LDAP to the Unix world.
• caseIgnoreMatch makes attribute values case-insensitive.
• Standard schemas are simply loaded from /etc/ldap/schema/.

In the next episode, episode 4, you learn the address of every entry: Distinguished Names — how a DN is built from RDNs, how its components are used, and how a DN translates into an LDAP URL.