skip to content

A team adds extensibleObject to its directory entries so new attributes need no schema change — what does that cost?

level: seniorimportance: should knowfreq 26%

answer

  1. the escape hatch widens what is allowed
  2. it does not invent definitions
  3. mandatory attributes are still mandatory
  4. the server stops refusing typos
  5. removal needs a clean-up first

basics

~20 s

extensibleObject is an auxiliary class letting an entry hold any user attribute the schema defines, so MUST and MAY lists stop constraining it. The cost is that the server can no longer refuse a misspelled or misplaced attribute, and the entry stops being self-describing.

solid answer

~40 s

`extensibleObject` is an auxiliary object class that allows an entry to hold any user attribute, so the `MUST` and `MAY` lists of its other classes stop being the limit. It does not waive the rest of the check: an attribute type the schema does not define is still refused with `undefinedAttributeType (17)`, values must still satisfy their type's syntax, the entry's own mandatory attributes must still be present, and the one-structural-chain rule still holds. What you give up is the server's refusal. A misspelled or misplaced attribute now persists, two applications drift into two spellings of one field, and nothing notices. The entry also stops being self-describing: reading the published schema no longer tells you what it may hold.

code

ldif · 7 lines
ldif
dn: cn=Ada Lindqvist,ou=musicians,o=Northfield Sinfonia
changetype: modify
add: objectClass
objectClass: extensibleObject
-
add: uid
uid: alindqvist

go deeper

for a junior

Recall that a directory can be told to accept attributes outside an entry's declared classes, and that this is a deliberate loosening rather than the normal way to model data.

for a middle

Explain exactly which checks survive it — the type must be defined, values must satisfy the syntax, mandatory attributes must be present, one structural chain — and which single check it suppresses.

for a senior

Talk about the operational consequence: with the refusal gone, spelling and placement mistakes persist silently, consumers code defensively, and the clean-up needed to reverse the decision grows the longer it runs.

for a principal

This is the schema-versus-velocity bet. Decide whether the estate absorbs new fields through reviewed class definitions, or whether teams extend entries freely and every reader carries the cost indefinitely.

## What the class actually permits `extensibleObject` is an auxiliary object class with an unusual definition: rather than listing particular attribute types, it allows an entry that declares it to hold **any user attribute**. Declare it on an entry and the effective `MAY` list of that entry becomes, in effect, every user attribute type the server's schema defines. It is the escape hatch the data model provides for the case where a real entry genuinely needs a field nobody anticipated. Being auxiliary, it does not change what the entry is. A player entry that declares it is still a player entry with the same structural chain; it simply stops being constrained by the class lists. ## What it does not waive This is where candidates overreach, so state the limits precisely: | Check | With `extensibleObject` | Without it | |---|---|---| | attribute type defined in the schema | still enforced | enforced | | value conforms to the type's `SYNTAX` | still enforced | enforced | | attribute listed in `MUST` or `MAY` | not required | required | | the entry's mandatory attributes present | still enforced | enforced | | exactly one structural chain | still enforced | enforced | | `SINGLE-VALUE` respected | still enforced | enforced | So an attribute type the server has never heard of is still refused with `undefinedAttributeType (17)`, because there is no definition to check a value against; a badly formed value is still `invalidAttributeSyntax (21)`; a missing mandatory attribute of a declared class is still `objectClassViolation (65)`. The class widens *which defined attributes are allowed here*, and nothing else. ## What you give up - **The refusal.** The main value of an LDAP schema is that the directory server says no. With the class in place, an attribute written to the wrong entry, or written under a plausible-but-wrong type, is simply stored. - **Convergence between clients.** Two teams writing the same conceptual field will pick two defined types for it, and both writes succeed. Readers then need to know both, forever, and neither can be retired without auditing entries. - **Self-description.** Without the class, reading the published class definitions tells you what an entry may hold. With it, the only way to know what entries actually hold is to read the entries. - **Reversibility.** Removing the class later is not a configuration change. Entries have accumulated attributes their remaining classes do not list, so dropping it asks the server to accept an entry that now violates its own schema, and `objectClassViolation (65)` comes back. The clean-up is per entry and grows with however long the shortcut ran. ## The orchestra list, worked The orchestra's list starts clean: one structural chain per player, a small auxiliary class for deputies, every write checked. A booking tool needs to record which agency represents a deputy, and the schema change needs a review nobody has time for. Declaring `extensibleObject` on deputy entries makes the write succeed this afternoon. Six months later, three tools write to those entries. One records the agency under one defined attribute type, another under a different one because it copied an example, and a third writes it to permanent players' entries too, because nothing stopped it. A report that joins on the agency is quietly wrong: it sees two thirds of the deputies. No log records a failure, because nothing failed. The schema the server publishes still describes the original clean model, so a new engineer reading it forms an accurate picture of a directory that no longer exists. ## The alternative, and when the hatch is right The alternative is the mechanism the model already provides: have the schema administrator define an auxiliary class carrying the new attribute types, or reuse a published definition such as `inetOrgPerson` (RFC 2798) where one already covers the field. Entries that need the fields declare that class, the server keeps refusing everything else, and the published schema still documents what an entry may hold. The cost is a review and a schema update; the benefit is that the refusal survives. `extensibleObject` earns its place in narrow, deliberate cases — a staging area for data being migrated in, or a small set of entries whose shape genuinely is not knowable in advance. What makes it a smell is reaching for it as the default because defining a class is slow. That trade buys an afternoon and sells the property that made the directory worth querying: that every entry in it obeys a rule you can read. ## What to say in an interview Name the mechanism precisely (auxiliary class, any user attribute), state the limits it does not lift (defined type, syntax, mandatory attributes, one structural chain), then give the operational consequence and the exit cost. Anyone can call it a bad idea; the answer that lands is the one that says exactly which check disappears and what fills the gap once it does.

  • What is the alternative when a directory genuinely needs to hold new fields?
    Have a schema administrator define an auxiliary class carrying the new attribute types, or reuse a published definition such as `inetOrgPerson` (RFC 2798) where one already covers the field. Only the entries that need the fields declare the class, the server keeps refusing everything else, and the published schema still documents what an entry may hold.
  • Why is removing extensibleObject from entries later harder than adding it?
    Because the entries have accumulated attributes their remaining classes do not list. Dropping the class asks the server to accept an entry that now violates its own schema, so `objectClassViolation (65)` comes back. The clean-up means working out per entry which attributes only that class permitted, and it grows with however long the shortcut ran.
  • Does declaring extensibleObject change what kind of entry it is?
    No. It is auxiliary, so the entry's structural chain and its kind are untouched and the one-structural-chain rule still applies. The class only widens the set of attribute types the entry may hold; an entry declaring it is still a person, a group or an organizational unit.

saying these in an interview costs you the question

  • Says extensibleObject lets an entry store any attribute name at all.
  • Thinks it waives the mandatory attributes of the entry's other classes.
  • Assumes it can be removed again later with no clean-up.
  • Treats it as a structural class that changes what the entry is.
  • Believes a loose schema costs nothing because readers can ignore extras.