Schema & Object Classes

## The attribute that decides the other attributes An LDAP directory entry is a Distinguished Name plus a set of attributes, each attribute holding one or more values. One of those attributes is not ordinary data: `objectClass`. It is multi-valued, it is present on every entry, and its values are the names of the object classes the entry belongs to. A directory server does not read it as information about the person or group the entry describes — it reads it as the entry's own declaration of what kind of thing it is, and every other schema decision follows from that declaration. The requirement is built into the schema rather than bolted on beside it. The class `top` (2.5.6.0) is `ABSTRACT` and carries `objectClass` in its own `MUST` list, and every structural class chain is rooted at `top`. So the one attribute that decides which attributes are permitted is itself required everywhere. There is no entry without it and no way to switch the mechanism off for one entry. ## What an object class definition carries A class is published as a definition with a numeric OID, a `NAME`, a kind, a `SUP` clause naming its superclasses, and two lists of attribute types: - **`MUST`** — attribute types the entry is required to hold. An entry lacking one is not stored. - **`MAY`** — attribute types the entry is permitted to hold. Present or absent, the server does not mind. - **`SUP`** — the superclass or superclasses whose `MUST` and `MAY` lists are inherited. - **kind** — `STRUCTURAL`, `AUXILIARY` or `ABSTRACT`, which decides how the class may be used. The worked definition to keep in mind is `person (2.5.6.6)`: `MUST ( sn $ cn )` and `MAY ( userPassword $ telephoneNumber $ seeAlso $ description )`. An entry declaring `person` must carry a surname and a common name, may carry any of the four optional types, and may carry nothing else from the user attributes unless another declared class allows it. ## Combining the lists An entry usually declares several classes, and their contributions combine rather than compete: | Input | How it contributes | Effect on the entry | |---|---|---| | the structural class | its own `MUST` and `MAY` | fixes what the entry is | | each superclass via `SUP` | inherited `MUST` and `MAY` | why `top` and `person` both appear in the values | | each auxiliary class | additional `MUST` and `MAY` | widens the entry without changing its kind | | the union of all of them | the effective permitted set | anything outside it is refused | No class overrides another and there is no precedence order among the values of `objectClass`. Whatever any declared class requires is required; whatever any declared class permits is permitted. ## What the server checks when the entry is written 1. It collects every class named in `objectClass`, plus their superclasses. 2. It unions their `MUST` and `MAY` lists into the effective permitted set. 3. Every attribute type in the effective `MUST` must be present, or the write is refused with `objectClassViolation (65)`. 4. Every user attribute supplied must appear in the effective `MUST` or `MAY`, or the write is refused with the same code. 5. Each attribute type supplied must be defined in the server's schema at all, otherwise `undefinedAttributeType (17)`, and each value must satisfy that type's syntax, otherwise `invalidAttributeSyntax (21)`. When a write breaks more than one of these, which failure the server reports first is not fixed by the protocol, so a diagnostic message naming one problem does not promise the entry has only that one. ## Operational attributes sit outside the lists Not everything on an entry is governed by `MUST` and `MAY`. Operational attributes are maintained by the directory server itself and are exempt: `creatorsName`, `createTimestamp`, `modifiersName`, `modifyTimestamp`, `entryUUID (1.3.6.1.1.16.4)`, `entryDN (1.3.6.1.1.20)` and `subschemaSubentry (2.5.18.10)` among them. They are also excluded from the default result set, so a client that reads an entry and asks for everything gets the user attributes only; the operational ones must be named in the request. ## Why the check lives in the server The practical value of the arrangement is that the rules are in one place and every client gets the same ones. An application that validates its own fields and then writes is enforcing its own opinion; the directory server enforces the estate's. That is why a schema violation is a refusal rather than a warning, and why deleting an inconvenient `objectClass` value is not a way to loosen the rules — it changes what the entry claims to be, which is exactly the thing the server is checking.