A client marks an LDAP Control critical and the server does not recognise its OID — what happens?
answer
- the client declares, the server obeys
- default is FALSE, not TRUE
- all-or-nothing, never partly done
- unavailableCriticalExtension is result code 12
- root DSE supportedControl asks in advance
basics
~20 sThe server refuses the whole operation and answers unavailableCriticalExtension (12), having performed none of it. Had criticality been FALSE — which is the encoding's default — the server would have ignored the unrecognised control and carried the operation out as if it had never been sent.
solid answer
~40 s`criticality` is a `BOOLEAN DEFAULT FALSE` inside the Control, and it is the client's statement of whether the result is still usable without that control. If the control is marked critical and the server either does not recognise the `controlType` or cannot apply it to this operation, the server must not perform the operation at all and returns `unavailableCriticalExtension (12)` — an all-or-nothing failure, not a partial one. If it is not critical and the control is unrecognised or inapplicable, the server ignores it and carries out the base operation, returning an ordinary `success (0)`. That second path is the dangerous one: a client that leaves the paging control non-critical can be handed one un-paged, silently truncated result and never know.
code
pseudocode · 9 linesfunction handle(request, controls)
for each control in controls
if recognised(control.controlType) and applicable(control, request)
apply(control)
else if control.criticality is TRUE
return result(unavailableCriticalExtension) // request not performed at all
else
skip control // criticality FALSE is the default
return perform(request)go deeper
Remember that a control can be declared critical or not, that FALSE is the default, and that the critical path fails the whole operation while the non-critical path silently carries on without the control.
Explain the mechanics: which conditions trigger unavailableCriticalExtension (12), why nothing is performed when it does, and why leaving a paging control non-critical produces a truncated result the client believes.
Demonstrate the operational reasoning — pick criticality per control against what a caller can still use, and read supportedControl per connection because a replica pool behind one address is not uniform.
Treat it as an availability-versus-correctness contract across an estate: critical controls make capability gaps loud and fail closed, which is what you want for correctness-bearing behaviour and not for conveniences.
## What the flag actually says Every LDAP Control carries three things: `controlType`, the OID naming it; `controlValue`, its parameters; and `criticality`, declared in the grammar as `BOOLEAN DEFAULT FALSE`. That default matters more than it looks — a client library that does not set the field explicitly has said "not critical", and the server will treat it that way. The flag is not a priority and not a hint about importance to the business. It is a precise statement by the client: *is the answer to this operation still meaningful if you do not honour this control?* ## The two paths a server takes - **`criticality` TRUE, and the server does not recognise the `controlType`, or recognises it but cannot apply it to this operation.** The server must not perform the operation. It returns `unavailableCriticalExtension (12)`. Nothing partial happened: no entries were searched and returned, no attribute was written. A failed critical control is a failed operation. - **`criticality` FALSE, same situation.** The server ignores the control and performs the operation as though the control had never been attached, returning whatever result that operation normally returns — typically `success (0)`. - **The server recognises and can apply the control.** Criticality does not come into it at all; the control is applied either way. The asymmetry is the whole design. A control is optional behaviour, and the client is the only party that knows whether it is optional *for this client*. ## Why the non-critical path is the one that bites Consider an equipment-booking system at a research institute that syncs group memberships nightly. Its search attaches simple paged results (1.2.840.113556.1.4.319) with a page size of 500, and the library leaves `criticality` unset. The estate then fails over to a directory replica that does not advertise that control. The sequence is: 1. The server ignores the control it does not recognise, because the client said it was optional. 2. It performs an ordinary unpaged search. 3. It hits its own administrative cap and returns entries up to that cap, then `sizeLimitExceeded (4)` — or, on a server configured to answer within a cap, an ordinary `success (0)` with a truncated set. 4. The `SearchResultDone` carries no paging control, so the client's loop sees no cookie to continue with and concludes it has read everything. The sync "succeeds" every night with a fraction of the members. Nobody is paged, and the booking system quietly stops recognising half the people entitled to book. Marking the control critical converts this into a loud `unavailableCriticalExtension (12)` on the first run against that replica. ## Is critical therefore always right? No, and this is the judgment the question is really probing. | control | mark critical? | because | |---|---|---| | simple paged results, when the caller needs the whole set | yes | a truncated answer is worse than no answer | | server-side sorting request, when the caller can sort locally | no | an unsorted page is still usable | | Assertion Control (1.3.6.1.1.12) guarding a write | yes | ignoring the condition means writing when you should not have | | Pre-Read Control (1.3.6.1.1.13.1) fetching the prior values | usually no | losing a convenience should not fail the write | Marking an advisory control critical turns a nicety into an outage the first time you fail over to a server that lacks it. Marking a load-bearing control non-critical turns a correctness failure into a silent one. Neither default is safe; the flag has to be chosen per control, per caller. ## The well-behaved alternative: ask first A server publishes the control OIDs it holds in the root DSE, as values of `supportedControl`, and the extended-operation OIDs as `supportedExtension`. Reading that once per connection lets a client decide deliberately — page if paging is there, otherwise narrow the search or refuse to run — instead of discovering the gap as a runtime failure or, worse, not discovering it. Two cautions: - the root DSE describes **that server**, so a pool of replicas behind one address must be checked per connection, not once at startup; - advertisement means the server implements the control, not that this bind identity is permitted to use it or that it will apply on every operation. ## The wording to use in an interview Criticality is a contract term, not a flag: *the client declares whether a result computed without this control is acceptable*. A server that honours the control ignores the flag. A server that cannot, reads it and chooses between failing the whole operation with `unavailableCriticalExtension (12)` and quietly doing something the client did not ask for.
- What does a client gain by reading supportedControl on the root DSE rather than just marking the control critical?It learns before it commits. A critical control turns an unsupported feature into a failed operation at the worst moment; reading `supportedControl` lets the client degrade on purpose — narrow the search, warn an operator, refuse to start — and it reveals that a pool of replicas is not uniform, which a single failed operation does not.
- Does a server return unavailableCriticalExtension only for controls it has never heard of?No. It also applies when the server recognises the control but cannot apply it to this particular operation — the control is inappropriate there — and to a critical control the server is unwilling to honour in the current state. The common thread is that the client said the result is unusable without it.
- If a critical control fails, can part of the operation still have happened?No. The server must not perform the operation, so a critical control that cannot be honoured on a write means no attribute value changed. That is exactly why criticality is the right flag for something like the Assertion Control (1.3.6.1.1.12) guarding a conditional write.
saying these in an interview costs you the question
- Thinks a non-critical control is applied anyway, just quietly
- Says an unrecognised critical control returns an empty result set
- Believes criticality defaults to TRUE when the field is omitted
- Assumes the operation partly completes before the error comes back
- Confuses a Control's criticality with an X.509 critical extension
- Treats root DSE advertisement as cluster-wide rather than per server