Why does removing an obsolete branch from a directory take more than one LDAP Delete request?

## The smallest request in the protocol A Delete request is a single Distinguished Name and nothing else. There is no filter to match on, no search scope to widen, and no recursion flag. The operation deletes **one** entry, and it succeeds only if that entry is a leaf: a server refuses an entry that still has subordinates with `notAllowedOnNonLeaf (66)`. That single constraint turns "remove the retired practice's branch" from one request into a client-side algorithm. ## The walk, and why its order is fixed The client enumerates the branch and deletes **depth-first**: every descendant before its parent, the branch's root last. Any other order simply collects `notAllowedOnNonLeaf (66)` refusals until it happens to hit a leaf. The important property of that walk is what it is **not**: it is not a transaction. Each Delete is an independent operation with its own `resultCode`, and the base protocol offers nothing that joins a sequence of them. A run that stops half way — a network drop, a rate limit, an operator's interrupt — leaves a branch partly deleted, and the directory has no memory of what the job intended. ## Writing the walk so a re-run is safe Because a half-finished run is the normal case rather than the exception, the interesting engineering is in the result codes: - **`noSuchObject (32)`** — the entry is already gone. On a re-run this is the expected outcome for everything the previous attempt finished, and it must be treated as **done**, not as an error. A job that aborts on it can never complete after its first failure. - **`notAllowedOnNonLeaf (66)`** — a subordinate exists. On a first pass that means the walk missed a level; on a re-run of a live directory it usually means an entry was **created under the branch while the walk was running**. The fix is to re-enumerate that node rather than to retry the same request. - **`insufficientAccessRights (50)`** — the connection's authenticated identity may not delete this entry. That stops the sub-branch containing it and, by extension, every ancestor up to the root of the walk, but it does not invalidate the entries already removed. - **`unwillingToPerform (53)`** — the server declines on policy grounds. The request was well formed and no amount of retrying changes the answer. ## What deletion does not clean up Deleting an entry removes that entry. It does not touch anything that **names** it. Group entries hold Distinguished Names in `member` and `uniqueMember` values, and the base protocol defines no referential integrity, so those values survive as references to entries that no longer resolve. A deprovisioning job that does not also send a Modify with a `delete (1)` change against each group entry leaves the directory quietly inconsistent, and the next audit of group membership reads as though the people are still there. ## Ordering the whole job For the retirement of a practice's branch, the order that actually works is: 1. Enumerate the branch and record every Distinguished Name, deepest first. 2. Repair references: for each group entry naming one of those DNs, send a Modify with a `delete (1)` change removing that value. 3. Delete depth-first, treating `noSuchObject (32)` as already-done and re-enumerating on `notAllowedOnNonLeaf (66)`. 4. Delete the branch's root entry last, and confirm the result rather than assuming it. Step 2 before step 3 matters: once the entries are gone, finding which groups referenced them is much harder, because the only remaining evidence is the stale values themselves. ## The interview point The answer an interviewer is listening for is not "there is a recursive delete". It is that the protocol's write surface is deliberately per-entry, that the server's leaf-only rule is what forces the ordering, and that the absence of a transaction across requests is what makes idempotence — not cleverness — the property a bulk deprovisioning job has to be built around.