In LDAP schema, how do STRUCTURAL and AUXILIARY object classes differ in what a directory entry declares?

## Three kinds of class, one of which is different An object class definition declares a kind: `STRUCTURAL`, `AUXILIARY` or `ABSTRACT`. The kind is not decoration. It decides whether a directory entry may *be* the class, may *add* the class, or may only inherit from it, and the three are not interchangeable. A **structural** class answers the question *what is this entry*. An entry belongs to exactly one structural class, and by inheritance to that class's superclasses, forming a single chain that ends at `top`. That is why an entry's `objectClass` values usually include several names that are clearly related: `top`, `person (2.5.6.6)`, `organizationalPerson (2.5.6.7)`. They are one chain written out, not three separate decisions. An **auxiliary** class answers a different question: *what else does this entry carry*. It is bolted onto an entry whose kind is already settled, it contributes its own `MUST` and `MAY` lists, and an entry may declare any number of them or none at all. An auxiliary class is not required to derive from `top`. An **abstract** class can never be an entry's own kind. It exists to be inherited from, which is exactly what `top` (2.5.6.0) does: it sits at the root of every structural chain and contributes the requirement that `objectClass` itself be present. ## The comparison in one table | Kind | How many per entry | Derives from `top`? | Changes what the entry is? | |---|---|---|---| | `STRUCTURAL` | exactly one chain | yes, the chain is rooted there | yes — it is the entry's kind | | `AUXILIARY` | any number, including none | not required | no — it only adds attribute types | | `ABSTRACT` | never named as an entry's kind | `top` is itself the root | no — it exists to be inherited | ## The orchestra list, worked A regional orchestra keeps one entry per player. Every player entry shares a core: a name, a surname, a contact number, the section they sit in. That core is the structural class — the thing every entry *is*. Deputies who cover the occasional concert need fields a permanent player does not: the dates they are available, who books them, which instruments they will cover. Modelling that as a second structural class is the mistake, because a deputy is still a player and an entry cannot belong to two structural chains. Modelling it as an auxiliary class, declared only on the entries that need it, is the design the schema is built for. A deputy's entry then declares the same structural chain as everyone else's, plus one auxiliary class, and the directory server enforces the deputy-specific `MUST` attributes on exactly those entries. ## What the server refuses - **Two structural classes from unrelated chains** — the entry would be two kinds of thing at once, and the write is refused with `objectClassViolation (65)`. - **An abstract class declared as the entry's kind** — the same refusal; `top` may appear as part of a chain, but nothing may be *only* `top`. - **A missing mandatory attribute of a declared auxiliary class** — an auxiliary class is optional, but once declared its `MUST` list binds as hard as a structural class's, again `objectClassViolation (65)`. - **A Modify that would change the entry's structural class** — the specification does not permit it, and `objectClassModsProhibited (69)` is the code for that refusal. That last one is the one candidates are surprised by, and it is the reason the structural choice matters more than the auxiliary ones. Auxiliary classes can be added to and removed from an entry over its life. The structural class is settled when the entry is created, and changing your mind means writing the entry you actually wanted rather than editing the one you have. ## Designing with the distinction The rule of thumb that survives contact with a real estate: model as **structural** the answer to *what is this*, and model as **auxiliary** everything situational, optional or owned by one consumer. A schema with a handful of structural kinds and a longer list of auxiliary classes stays comprehensible; one that invents a new structural kind per use case forces every reader of the directory to learn the whole catalogue, and leaves entries that cannot be reclassified when the use case changes. It is also worth noticing what the distinction does *not* do. Auxiliary classes do not create a second hierarchy, do not have precedence over the structural chain, and do not make their own mandatory attributes optional. They widen the set of permitted attribute types, and that is all.