skip to content

Entry Tree and DNs

2 roadmaps5 questions

Entries hang in a tree, and a Distinguished Name locates one by chaining its RDN onto every parent's up to the suffix. You cannot write a search base or a bind DN without this model.

on this pageshow

explore

questions

5

In LDAP, how is a directory entry's Distinguished Name built from its own RDN and its ancestors'?

level: juniorimportance: must knowfreq 58%

answer

  1. position in a tree, not a label
  2. one step per ancestor
  3. read rightward toward the root
  4. siblings cannot share one RDN
  5. RDNSequence stops at a naming context

basics

~20 s

A Distinguished Name chains the entry's own Relative Distinguished Name onto every ancestor's, up to the naming context the server holds. In the RFC 4514 string form the leftmost component is the entry itself and the rightmost sits nearest the root.

solid answer

~40 s

An entry is distinguished from its siblings by one **Relative Distinguished Name** — an attribute type, an equals sign and a value, such as `uid=hbell`. That is unique only under one parent. The **Distinguished Name** is the `RDNSequence`: the entry's RDN, then its parent's, then its grandparent's, until the chain reaches a **naming context** the server holds. RFC 4514 writes that sequence in reverse, comma-separated, so `uid=hbell,ou=curators,dc=seedbank,dc=example` reads *entry, parent, suffix* from left to right — you walk toward the root as you read rightward. Two consequences matter: siblings cannot share an RDN, because their DNs would then be identical; and the attribute type and value used in the RDN must also be present as an attribute of the entry itself.

code

ldif · 9 lines
ldif
dn: uid=hbell,ou=curators,dc=seedbank,dc=example
objectClass: inetOrgPerson
cn: Hannah Bell
sn: Bell
uid: hbell

dn: cn=WHEAT-0417,ou=accessions,dc=seedbank,dc=example
objectClass: organizationalUnit
description: durum landrace, collected 1987

go deeper

for a junior

Be able to point at each comma-separated piece of a Distinguished Name and say what it is: the entry, then its containers, then the suffix. Say out loud that the rightmost end is nearest the root.

for a middle

Explain the chaining as a mechanism: an RDN is unique only among siblings, the sequence of RDNs makes it globally unique inside the tree, and the RDN's value is also an attribute of the entry.

for a senior

Show that you have been bitten by treating a DN as a stable key. Talk about what breaks in an application when an entry is reparented, and why a server-assigned identifier is the safer thing to persist.

for a principal

Frame naming as a design commitment: the suffix layout you choose decides what can later be delegated, partitioned or moved, and every consumer that stored a DN pays for a reorganisation.

## The tree comes first, the name second A directory server stores **entries** — one per person, per group, per machine, or, in a seed bank's accession registry, one per seed lot. Those entries hang in a single hierarchy, the **Directory Information Tree** (DIT). An entry has no arbitrary primary key it shows to callers. Its identity is its **position** in that tree, and a **Distinguished Name** (DN) is the written form of that position. This is why you cannot write a search base or a bind DN without the model: both of those are DNs, and both are only meaningful relative to a tree a particular server holds. ## RDN, then RDNSequence Each entry is distinguished from its **siblings** — the other children of the same parent — by a **Relative Distinguished Name**. In the protocol's own structures an RDN is a `RelativeDistinguishedName`, a set of one or more `AttributeTypeAndValue` pairs: an attribute type such as `cn`, `ou`, `uid` or `dc`, an equals sign, and a value. `uid=hbell` is an RDN. It is unique only under its parent; another parent elsewhere in the tree may hold a different entry whose RDN is also `uid=hbell`. The DN is the `RDNSequence`: the entry's own RDN, then its parent's, then its grandparent's, and so on. Three rules fall straight out of that: 1. **Sibling RDNs must differ.** Two children of one parent cannot carry the same RDN, because their two DNs would then be the same string naming two entries. 2. **The RDN's value is also an attribute of the entry.** If the RDN is `uid=hbell`, the entry itself holds `uid: hbell`. The name is not stored separately from the data. 3. **The chain terminates at a naming context.** A server holds one or more subtrees, each rooted at a suffix. The sequence stops at that suffix; there is no global root you climb to. ## The string form, and which end is the root RFC 4514 defines the human-readable encoding. It writes the RDNs of the `RDNSequence` in **reverse order**, separated by commas, so the entry comes first and the suffix last: | Component of `uid=hbell,ou=curators,dc=seedbank,dc=example` | What it is | |---|---| | `uid=hbell` | the entry's own RDN | | `ou=curators` | its parent's RDN — the container of curator entries | | `dc=seedbank,dc=example` | the naming context this server holds | The practical reading rule: **left is the entry, right is the root.** Every comma you move past is one step up the tree. A registry that holds seed accessions under one suffix and its curators under another produces two unrelated DN shapes on the same server — `cn=WHEAT-0417,ou=accessions,dc=seedbank,dc=example` and the curator above — and nothing but the name tells them apart. ## The attribute types you see in names Any attribute type may form an RDN, but a small set of registered short names does almost all the work, each with a registered object identifier: - `CN` (2.5.4.3), common name — the usual leaf name for a person or an object - `OU` (2.5.4.11), organizational unit, and `O` (2.5.4.10), organization — containers - `DC` (0.9.2342.19200300.100.1.25), domain component — one label per component of a DNS-style suffix, which is why suffixes often read `dc=seedbank,dc=example` - `UID` (0.9.2342.19200300.100.1.1), user identifier - `L` (2.5.4.7), `ST` (2.5.4.8), `C` (2.5.4.6) and `STREET` (2.5.4.9) for locality, state, country and street Where no short name is registered for an attribute type, the string form falls back to the **dotted-decimal numeric OID** followed by `=#` and the hexadecimal encoding of the value's BER form. It is rare, and it is legal. ## What a Distinguished Name is not - **It is not a login name.** A person may type a short identifier at a sign-in prompt; something must still turn that into a DN before it can be used as a bind DN. - **It is not the subject name of an X.509 certificate**, even though the two are written with the same comma-separated `type=value` grammar and can be byte-identical. One locates an entry in a tree; the other names a certificate's subject. - **It is not guaranteed stable.** A DN describes where an entry currently sits, so it changes if the entry is renamed or moved. A directory publishes `entryUUID` (1.3.6.1.1.16.4), assigned once and never reused, for callers that need a name that cannot move, and `entryDN` (1.3.6.1.1.20) to expose the current DN as an ordinary attribute. - **It does not imply access.** Knowing an entry's DN says nothing about whether the connection you are on may read it.

  • If a Distinguished Name changes when an entry moves, what does a directory offer as a name that does not?
    `entryUUID` (1.3.6.1.1.16.4) — an operational attribute the server assigns once, never changes and never reuses. An application that stores a DN as a foreign key breaks the first time the entry is renamed or reparented; one that stores the `entryUUID` and looks the current DN up again does not. `entryDN` (1.3.6.1.1.20) exposes the current DN itself as an attribute, which is useful when you need the name back out.
  • Must the attribute value used in the RDN also appear as an attribute of the entry?
    Yes. The attribute type and value that form the RDN are required to be present among the entry's own attributes, so an entry named `uid=hbell` holds `uid: hbell`. The name is a view of the data, not a label beside it — which is also why a directory server refuses a change that would strip an RDN value out of the entry while leaving the name in place.
  • Why is there no single global root above every Distinguished Name?
    Because a server publishes one or more independent suffixes rather than a slice of a worldwide namespace. The chain of RDNs stops at whichever naming context holds the entry, and a server may hold several unrelated ones at once — a registry can carry accession entries under one suffix and staff entries under another with no common ancestor between them.

saying these in an interview costs you the question

  • Calls a Distinguished Name a username with extra punctuation
  • Reads the string left to right as descending from the root
  • Thinks the components can be reordered without changing the name
  • Assumes a DN is a permanent identifier stored inside the entry
  • Believes every suffix must be built from dc components
open as a page

A directory entry's common name contains a comma — what must the RFC 4514 string form of its Distinguished Name do?

level: middleimportance: must knowfreq 46%

basics

~20 s

The comma must be escaped inside the RDN value, as a backslash before it or as the hex pair for that octet. Unescaped, the comma is read as the separator between two RDNs, and the string names something other than the entry — usually nothing at all.

open as a page

Which directory entry does an LDAP client read to discover the naming contexts a server holds, and how?

level: middleimportance: should knowfreq 40%

basics

~20 s

The root DSE — the entry whose Distinguished Name is zero-length. Reading it at the empty name returns operational attributes including namingContexts, which lists every suffix the server holds, so a client can discover them instead of being configured with a guess.

open as a page

An LDAP search returns noSuchObject(32) with a matchedDN shorter than the base you sent — what does that diagnose?

level: seniorimportance: should knowfreq 34%

basics

~20 s

It names the longest ancestor of your base that does exist, so everything below it in the name is wrong. A matchedDN equal to the suffix means the container is missing or misspelled; an empty one means the server holds no naming context covering that name at all.

open as a page

Two directory entries under one parent would carry the same cn value — how does a multi-valued RDN resolve that?

level: middleimportance: nice to knowfreq 24%

basics

~20 s

A Relative Distinguished Name may hold more than one attribute type and value, joined in the string form with a plus sign, so a second attribute distinguishes the siblings. Every value used must also be present as an attribute of the entry.

open as a page