Browse learn

Distinguished Names and Relative Distinguished Names

Understand how LDAP distinguished names and relative distinguished names identify entries, encode hierarchy, and support reliable directory operations.

Type
Concept
Level
Beginner
Technologies
LDAP
On this page

Understanding how LDAP identifies, organizes, and references directory entries is critical for any developer or identity engineer working with identity platforms, authentication, or directory integrations. Distinguished Names (DNs) and Relative Distinguished Names (RDNs) are cornerstones of this structure. Correct DN and RDN handling is essential because naming, escaping, comparison, and hierarchy rules affect nearly every LDAP operation.

What Is a Distinguished Name (DN)?

A Distinguished Name (DN) is a unique, fully qualified name for an entry in an LDAP directory. Formally defined in RFC 4512, the DN serves as the directory’s equivalent of an absolute file path: it points to one, and only one, entry in the directory information tree (DIT).

A DN is composed of a sequence of RDNs, ordered from the leaf (the specific entry) on the left, through each successive parent, up to the root on the right. Each entry in the directory, from a user to a group or container, is referenced by its DN in all protocol operations—whether for authentication (bind), search, or modification.

Examples:

  • cn=John Doe,ou=People,dc=example,dc=com
  • dc=example,dc=com

Why is a DN essential?

  • Uniqueness: The DN is guaranteed to identify one entry only.
  • Hierarchy encoding: The DN encodes the logical (and sometimes organizational) structure of the directory.
  • Protocol operations: Most LDAP operations target entries by DN.

What Is a Relative Distinguished Name (RDN)?

A Relative Distinguished Name (RDN) is a single component in a DN that uniquely distinguishes an entry among its siblings within a particular parent context. An RDN is typically a single attribute-value pair (e.g., cn=John Doe), but it can also be multi-valued, comprising two or more attribute-value pairs combined with a plus (+) sign (e.g., cn=John Doe+uid=jdoe).

Key Properties of RDNs:

  • Uniqueness within parent: Each RDN identifies one entry under its parent.
  • Composition: RDNs may contain one or several attribute-value pairs.
  • No global uniqueness: An RDN may occur multiple places in the DIT; uniqueness is context-dependent.

Examples:

  • Single attribute-value: cn=John Doe
  • Organizational unit: ou=People
  • Domain component: dc=example
  • Multi-valued: cn=John Doe+uid=jdoe

Why multi-valued RDNs?
Multi-valued RDNs add specificity—useful when a single attribute is insufficient for uniqueness among siblings.

How Are DNs Constructed? (Anatomy of a DN)

A DN is built by sequencing RDNs from the entry’s own RDN (leftmost) to its ultimate container or root (rightmost). Each RDN represents a level in the directory hierarchy. The order is strictly significant: reversing or shuffling RDNs changes meaning and may point to a non-existent or wrong entry.

Construction breakdown:

  • Attributes in RDNs: The most common are CN (commonName), OU (organizationalUnitName), and DC (domainComponent). Others include O (organizationName), C (countryName), etc.
  • Order: Always left (leaf) to right (root).

Examples:

  • Domain-rooted (RFC 2247): cn=John Doe,ou=People,dc=example,dc=com
    • cn=John Doe (specific person)
    • ou=People (organizational unit)
    • dc=example,dc=com (domain-rooted hierarchy)
  • Organization-rooted: cn=user,ou=teams,o=company
  • Service entry: cn=service,dc=app,dc=example,dc=com
  • Multi-valued RDN: cn=John Doe+uid=jdoe,ou=People,dc=example,dc=com

Why does order matter?

  • The order models containment: left is the entry, each RDN to the right is its parent up to the root.
  • Directory operations parse DNs strictly by this structure.

DN vs. RDN vs. CN: What's the Difference?

  • DN: The full path—sequence of RDNs—uniquely identifying the entry.
  • RDN: One “directory level”—the immediate name under its parent, possibly multi-valued.
  • CN (commonName): A specific attribute often used in RDNs, but not synonymous with RDN or DN.

For example, in cn=John Doe,ou=People,dc=example,dc=com:

  • The DN is the entire string.
  • The leftmost RDN is cn=John Doe.
  • CN is just the attribute type for the commonName; other entries might use uid, ou, or dc for their RDNs.

DNs and RDNs in LDAP Operations

DNs are central to core LDAP operations. Misunderstanding them is a frequent cause of authentication and search failures.

Binding (Authentication)

  • During LDAP bind, the DN acts as the identity (principal).
  • If the DN is malformed, incorrect, or does not match any entry, authentication fails.

Searches

  • A DN can define the base for a search operation—establishing which subtree is queried.
  • The scope and filter then determine which entries beneath that DN are returned.

Modifications

  • Modifications and attribute updates are performed against entries identified by their DNs.
  • Renaming (modifying the RDN) or moving an entry (changing parent DN) alters the entry’s DN.

Common errors:

  • Mistyping or misordering RDNs in a DN.
  • Failing to escape special characters, leading to DN parsing failures.
  • Using an incomplete or non-unique RDN as a DN.

Best Practices, Pitfalls, and Troubleshooting

Correct handling of DNs and RDNs is essential for robust directory integrations.

Composition and Formatting

  • Choose appropriate attributes: Use attributes (CN, OU, DC, etc.) that reflect organizational or domain structure.
  • Multi-valued RDNs: Use when single attributes do not guarantee uniqueness.
  • DN uniqueness: Remember, DNs must be globally unique in the directory.

Syntax and Escaping

  • Comma, plus, equals, and special characters: Must be properly escaped if present in attribute values.
    • Example: cn=Smith\, John,ou=People,dc=example,dc=com
  • Whitespace and case: LDAP DN handling may be case-insensitive but always check the specific implementation.
  • Multi-valued RDN syntax: cn=John Doe+uid=jdoe,ou=People,dc=example,dc=com

Common Pitfalls

  • Treating a DN as a single attribute-value pair: DNs are always sequences of RDNs, not just a CN.
  • Assuming all DNs must start with CN: Any valid attribute can serve as the leftmost RDN, consistent with schema and uniqueness requirements.
  • Order indifference fallacy: Changing the order of RDNs in a DN changes its reference.
  • Forgetting DC mapping: In directories integrating with DNS domains, DC attributes enable domain-rooted DNs (per RFC 2247).

Troubleshooting Tips

  • Check for unescaped special characters in attribute values.
  • Verify correct DN ordering and hierarchy when structures change.
  • Use the correct DN for bind and searches: Double-check the full path to avoid referencing non-existent entries.

Further Reading

Distinguished Names (DNs) and Relative Distinguished Names (RDNs) are foundational in LDAP, providing precise, hierarchical, and unique identification for every directory entry. Understanding their composition, correct usage, and potential pitfalls ensures reliable directory integrations and authentication flows.

For further detail and formal definitions, consult the following authoritative standards:

  • RFC 4512 (Directory Information Models—definitive on DNs and RDNs)
  • RFC 2253 and RFC 4514 (string representation of DNs)
  • RFC 4511 (LDAP protocol usage of DNs)
  • RFC 2247 (mapping domain names using DC components in DNs)

Sources

Related resources