skip to content

To move a directory entry under a different parent, what must an LDAP ModifyDN request carry?

level: middleimportance: must knowfreq 52%

answer

  1. one operation, not delete then add
  2. the optional field makes it a move
  3. a boolean decides the old name's fate
  4. children follow without their own request
  5. crossing servers is refused, not split

basics

~20 s

A ModifyDN request carries the entry's current Distinguished Name, the new RDN, a deleteoldrdn boolean deciding whether the old naming value is discarded, and the optional newSuperior field naming the new parent. Without newSuperior it is a rename in place.

solid answer

~40 s

`ModifyDNRequest` names the entry to act on, the `newrdn` it should take, a `deleteoldrdn` boolean, and an optional `newSuperior`. If `newSuperior` is absent the entry keeps its parent and is only renamed; if it is present the entry is placed under that Distinguished Name and its new DN is `newrdn` chained onto it. `deleteoldrdn` decides the old naming value's fate: TRUE removes the values that formed the old RDN from the entry, FALSE keeps them as ordinary non-distinguished values, still searchable. Subordinate entries travel with the entry and their DNs change implicitly — there is no request per child. A destination the server does not hold is refused with `affectsMultipleDSAs (71)` rather than performed in halves.

code

asn1 · 5 lines
asn1
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
     entry           LDAPDN,
     newrdn          RelativeLDAPDN,
     deleteoldrdn    BOOLEAN,
     newSuperior     [0] LDAPDN OPTIONAL }

go deeper

for a junior

Recall that one operation both renames an entry and moves it, and that the move is the optional part. Know that it is not a delete followed by a fresh add.

for a middle

Explain each field: the new RDN, the boolean that keeps or discards the old naming value, and the optional parent that turns a rename into a move. Explain that subordinates follow implicitly.

for a senior

Demonstrate the aftermath: stored Distinguished Names in group entries go stale, nothing repairs them, and a destination on another server is refused outright rather than half-performed.

for a principal

Judge when a directory merge should be a series of moves at all, given that every consumer holding a Distinguished Name must be re-pointed and the operation offers no way to keep the old name resolving.

## One operation, four fields An entry's Distinguished Name is its RDN chained onto its parent's DN, so changing either half changes the name. LDAP does both with a single operation: - **`entry`** — the Distinguished Name the entry has now. - **`newrdn`** — the RDN it should have afterwards. It may be the same as the old one when only the parent is changing. - **`deleteoldrdn`** — a boolean deciding what happens to the values that formed the old RDN. - **`newSuperior`** — **OPTIONAL**. Absent, the entry stays where it is and is merely renamed. Present, it names the entry's new parent, and the entry's new DN is `newrdn` chained onto that. That optional field is the whole difference between a rename and a move, which is why so much tooling still treats them as two separate features. ## What deleteoldrdn actually decides Suppose a legacy address book named a person `cn=D Okafor` and the consolidated tree should name her `cn=Dana Okafor`. - **`deleteoldrdn: TRUE`** — the values forming the old RDN are removed from the entry. `cn: D Okafor` is gone; a lookup for the legacy spelling finds nothing. - **`deleteoldrdn: FALSE`** — those values stay on the entry as ordinary, **non-distinguished** attribute values. The entry is now named `cn=Dana Okafor` but still holds `cn: D Okafor`, so searches and references using the old spelling still match. During a merge that is usually what you want, and it is a decision nobody makes deliberately unless they know the field exists. Note what it does **not** control: it has nothing to do with the entry's children, its other attributes, or whether the old DN keeps working. ## Moving a subtree When the entry has subordinates, they move with it. Their Distinguished Names all change implicitly, because each is chained onto an ancestor that now sits elsewhere — the client sends **one** request, not one per descendant. That is the reason a directory merge is a ModifyDN job rather than an export-and-reimport job: a single request relocates a whole practice's branch. Two caveats follow from it: 1. **Not every server implements moving an entry that has subordinates.** One that does not refuses the request outright rather than moving the parent and orphaning the children. 2. **Nothing rewrites references to the old names.** The base protocol defines no referential integrity, so every `member` or `uniqueMember` value naming a Distinguished Name under the moved branch now names something that does not resolve. Repairing those is the client's work, one Modify per group entry. ## When the destination is not this server's to write A ModifyDN is defined within one server's own naming context. If `newSuperior` names a parent the server does not hold, the operation cannot be performed as a unit, and the server refuses with `affectsMultipleDSAs (71)` rather than doing half of it. Relocating an entry across that boundary is therefore a client-side procedure — recreate it at the destination, verify, then delete the original — and only the client can make that sequence safe. ## The failures worth recognising | resultCode | what went wrong | |---|---| | `entryAlreadyExists (68)` | something already occupies the resulting Distinguished Name | | `noSuchObject (32)` | the entry, or the parent named by `newSuperior`, does not exist — read `matchedDN` | | `affectsMultipleDSAs (71)` | the move's destination is not held by this server | | `namingViolation (64)` | the proposed RDN is not a legal way to name this entry | | `insufficientAccessRights (50)` | the connection's identity may read the entry but not relocate it | ## Why this is the operation candidates miss Asked to move a person between branches, many engineers describe deleting the entry and adding it again at the new place. That loses everything the entry carried but did not export, breaks any operational values the server maintains, and passes through a window in which the person exists nowhere. ModifyDN exists precisely so the directory can relocate an entry — and its subtree — as one operation with one verdict.

  • What does deleteoldrdn set to FALSE leave on the entry?
    The values that formed the old RDN stay as ordinary, non-distinguished attribute values. The entry answers to its new name but still holds the old naming value as data, so a search or a stored reference using the legacy spelling still matches it. TRUE removes those values instead.
  • A ModifyDN is refused with affectsMultipleDSAs (71). What now?
    The destination named by `newSuperior` is not held by this server, and the operation is defined within one server, so it refuses rather than performing part of it. Moving the entry across that boundary becomes a client-side procedure: create it at the destination, verify, then delete the original.
  • After moving a branch, why do group memberships break?
    Group entries store Distinguished Names in `member` or `uniqueMember` values, and those DNs still name the old location. The base protocol defines no referential integrity, so nothing rewrites them; the client repairs each group entry with a Modify that deletes the stale value and adds the new one.

saying these in an interview costs you the question

  • Says a move is a Delete followed by an Add at the new name
  • Thinks every subordinate entry needs its own ModifyDN request
  • Believes deleteoldrdn controls whether the children move
  • Assumes newSuperior may name a parent on another server
  • Uses Modify to change the entry's naming value
  • Expects group member values to be rewritten automatically