skip to content

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%

answer

  1. siblings must differ by name alone
  2. an RDN is a set
  3. plus joins, comma climbs
  4. both values live in the entry
  5. order of the components is meaningless

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.

solid answer

~40 s

An RDN is not one `type=value` pair but a **set** of them — `RelativeDistinguishedName` is a set of `AttributeTypeAndValue`. So where two curators share a common name under one container, the entries can be named `cn=Amy Green+uid=agreen2,ou=curators,dc=seedbank,dc=example` and `cn=Amy Green+uid=agreen7,...`: the `cn` collides, the pair does not. RFC 4514 joins the components with `+` in the string form, and because the components form a set their written order carries no meaning — swap them and it is the same name. Both values must appear as attributes of the entry itself, so that entry holds `cn: Amy Green` **and** `uid: agreen2`. If a value contains a literal plus sign it must be escaped, exactly as a comma is. Most deployments avoid the whole question by naming entries with an attribute that is unique by construction.

code

ldif · 11 lines
ldif
dn: cn=Amy Green+uid=agreen2,ou=curators,dc=seedbank,dc=example
objectClass: inetOrgPerson
cn: Amy Green
sn: Green
uid: agreen2

dn: cn=Amy Green+uid=agreen7,ou=curators,dc=seedbank,dc=example
objectClass: inetOrgPerson
cn: Amy Green
sn: Green
uid: agreen7

go deeper

for a junior

Know that a comma moves one step up the tree while a plus sign stays on the same entry, adding a second naming attribute to one Relative Distinguished Name.

for a middle

Explain that an RDN is a set of attribute-type-and-value pairs, that order carries no meaning, and that every value used in the name must also be an attribute of the entry.

for a senior

Argue the design side: names built from editable values move, consumers that split on commas break on these, and choosing a naming attribute that is unique by construction avoids the problem outright.

for a principal

Own the naming convention for the estate — which attribute names each class of entry, who may change it, and what the blast radius is when a name people can edit turns out to be a key elsewhere.

## An RDN is a set, not a pair The usual mental model — "an RDN is an attribute and a value" — is a simplification. The protocol's structure is a **set of one or more** `AttributeTypeAndValue`. A Relative Distinguished Name with two components is as legitimate as one with a single component, and it exists for exactly one reason: **sibling RDNs must be unique**, and sometimes no single attribute delivers that. A seed bank's registry with two curators called Amy Green in one container is the canonical case. `cn` does not separate them. Adding a second component does: ```ldif dn: cn=Amy Green+uid=agreen2,ou=curators,dc=seedbank,dc=example dn: cn=Amy Green+uid=agreen7,ou=curators,dc=seedbank,dc=example ``` ## Writing one RFC 4514 joins the components of one RDN with a **plus sign**, and separates RDNs from each other with a **comma**. That gives the string a two-level punctuation scheme worth stating explicitly: - `,` moves **up** the tree, one step per comma. - `+` stays at the **same** entry, adding another naming attribute to the same RDN. Misreading `+` as another comma is the standard error: it makes people count `cn=Amy Green+uid=agreen2,ou=curators,dc=seedbank,dc=example` as five levels of tree when it is four. ## Rules the components still obey 1. **Every RDN value is also an attribute of the entry.** The entry above holds `cn: Amy Green` and `uid: agreen2` as ordinary attributes. Both, not one of them. 2. **Order is not significant.** The components are a set, so `cn=Amy Green+uid=agreen2` and `uid=agreen2+cn=Amy Green` are two spellings of one name. Do not compare such names as strings. 3. **Escaping still applies inside each value.** A value containing a literal `+` must escape it — `\+` or the hex-pair form — just as a value containing a comma must, or the name silently gains a component. 4. **The same attribute type twice is not a way out.** Two components must differ; repeating one type with two values is not what this mechanism is for, and it does not make an ambiguous name unique in any useful way. ## When to reach for it, and when not to A multi-valued RDN is a naming device of last resort. It makes names longer, harder to type, harder to log and harder to compare, and every consumer that splits a DN on commas has to be written correctly to handle it. | Situation | Better choice | |---|---| | Naming people, where names collide by nature | name entries by a unique identifier attribute, not by rendered name | | Naming accessions or other catalogued objects | use the catalogue's own identifier, which is unique by construction | | An existing tree already naming by `cn`, one collision appears | a multi-valued RDN is the surgical fix that avoids renaming the tree | | Data imported from a source with no stable key | generate one and name by it, rather than composing two unstable values | The general principle: **a name built from a value people edit is a name that will move.** A multi-valued RDN composed of two such values simply doubles the number of reasons the name can change. ## The other plus sign One collision to hold in mind, because both appear in directory work and they are unrelated. In an RDN, `+` joins the components of one name. In the list of attributes a client asks a server to return, `+` is the selector meaning "all operational attributes" defined in RFC 3673. Same character, different grammar, no relationship — and a reader who conflates them will misread both a name and a request. ## What it does not do It does not make an entry more findable, it does not confer any precedence between the two attributes, and it is not a way of giving one entry two independent names. That last one is a different mechanism entirely: the `alias` object class, whose required `aliasedObjectName` attribute holds the Distinguished Name of another entry, exists precisely to give one entry a second name elsewhere in the tree. A multi-valued RDN produces exactly **one** name, just one assembled from two attributes.

  • Is the order of the components inside a multi-valued RDN significant?
    No. The RDN is a set of attribute-type-and-value pairs, so `cn=Amy Green+uid=agreen2` and `uid=agreen2+cn=Amy Green` denote the same entry. Neither component is primary and neither is a qualifier of the other. The practical consequence is that comparing two Distinguished Names byte by byte can report a difference where there is none — decode and compare the components.
  • How do you write an RDN whose value genuinely contains a plus sign?
    Escape it, exactly as you would a comma: a backslash before the character, or the hex pair for that octet. Left unescaped, the parser reads the value as two components of a multi-valued RDN and the name quietly means something else. The escape is part of the string form only; the stored attribute value keeps the plus sign and no backslash.

saying these in an interview costs you the question

  • Reads the plus sign as another step up the tree
  • Thinks the first component is primary and the second qualifies it
  • Confuses it with an attribute that has several values
  • Leaves one of the two values out of the entry's attributes
  • Assumes the server invents uniqueness when siblings collide