Category: Directory Services

Relative Distinguished Name

Also known as:

Simply put

A Relative Distinguished Name (RDN) is a single component of the full name that identifies an entry in an LDAP directory. It is written as an attribute paired with a value, such as cn=John Doe. Multiple RDNs are joined together to form the complete distinguished name that locates an entry within the directory tree.

Formal definition

An RDN is a component of an LDAP distinguished name (DN), where a DN is a sequence of comma-separated RDNs. Each RDN is comprised of one or more attribute name-value pairs (for example, cn=John Doe or ou=People); depending on the directory, an RDN may be multi-valued, combining more than one name-value pair. An RDN uniquely names an entry relative to its parent entry, and the DN of the parent (the entry above a given RDN) is referred to as the parent distinguished name. For example, in the DN cn=John Doe,ou=People,dc=sun.com, cn=John Doe is an RDN relative to ou=People,dc=sun.com. Specific attribute types permitted in an RDN and support for multi-valued RDNs vary by directory implementation and schema.

Why it matters

The RDN is the atomic building block of an LDAP directory's naming structure, and understanding it is essential to reasoning about how entries are located, referenced, and organized within the directory information tree (DIT). Because a distinguished name is simply a sequence of comma-separated RDNs, an incorrect or ambiguous RDN can break the resolution of an entire DN, causing lookups, binds, and downstream authentication or provisioning operations that depend on the directory to fail. The RDN uniquely names an entry only relative to its parent, so the same RDN value (for example, cn=John Doe) may legitimately appear under different parent entries, and confusing relative identity with absolute identity is a common source of directory misconfiguration.

RDN choices also have operational consequences over an entry's lifecycle. Because the RDN typically forms part of the entry's DN, using a mutable attribute (such as a person's common name) as the RDN can complicate rename operations and any external references that hold the DN, since changing the RDN changes the DN. In many deployments this is why administrators prefer stable, non-reassigned identifier attributes for the RDN, though the specific attribute types permitted and whether multi-valued RDNs are supported vary by directory implementation and schema. Being precise about which attribute serves as the RDN is therefore a practical concern for anyone designing a directory hierarchy or integrating systems that consume DNs.

Who it's relevant to

Directory and system administrators

Administrators who design and maintain LDAP directory hierarchies choose which attribute serves as the RDN for each entry, shaping how the directory tree is organized and how entries are located. Because the RDN forms part of the entry's DN, this choice affects rename operations and any external systems that reference entries by DN, so administrators must account for whether the chosen naming attribute is stable over the entry's lifecycle.

IAM and integration engineers

Engineers integrating applications, authentication flows, or provisioning pipelines with an LDAP directory frequently construct, parse, or compare DNs, and correct handling of RDN components, including comma-separated ordering and possible multi-valued RDNs, is necessary to avoid broken lookups or binds. They should confirm which attribute types the target directory permits in an RDN, since this varies by implementation and schema.

Identity architects

Architects planning directory information tree structures weigh how RDN and DN conventions influence naming stability, referential integrity, and how entries are addressed across federated or synchronized systems. Understanding that an RDN names an entry only relative to its parent helps them design hierarchies where the same RDN value can safely recur under different branches.

Inside RDN

Attribute Type and Value pair

An RDN is typically composed of one or more attribute-type-and-value assertions, for example cn=jdoe, where cn is the attribute type and jdoe is the value. This pair identifies an entry uniquely among its siblings under the same parent in the directory information tree (DIT).

Single-valued RDN

In most deployments an RDN consists of a single attribute-value pair (such as uid=alice) that distinguishes the entry from other entries sharing the same immediate parent.

Multi-valued RDN

An RDN may combine two or more attribute-value pairs joined with a plus sign (for example cn=John Doe+uid=jdoe) when a single attribute is insufficient to guarantee uniqueness among sibling entries. Support and usage depend on the directory schema and deployment conventions.

Relative position in the DIT

An RDN identifies an entry only relative to its parent, not globally. It is the local component that, when concatenated with the parent's Distinguished Name (DN), forms the full DN that is unique across the directory.

Naming attribute

The attribute chosen to form the RDN (such as cn, ou, uid, or dc) is often called the naming attribute; the appropriate choice typically depends on the object class and schema constraints of the directory.

Common questions

Answers to the questions practitioners most commonly ask about RDN.

Is a Relative Distinguished Name the same as a full Distinguished Name (DN)?

No. An RDN is a single component within a DN, not the complete path. An RDN identifies an entry relative to its immediate parent (for example, cn=jdoe), while a DN is the concatenation of that RDN with the RDNs of all ancestor entries up to the directory root (for example, cn=jdoe,ou=users,dc=example,dc=com). The RDN is only guaranteed to be unique among the siblings under a shared parent, whereas the DN is intended to be unique across the directory. Treating an RDN as if it were globally unique or a standalone identifier is a common mistake.

Does an RDN always consist of a single attribute-value pair?

Not necessarily. While many RDNs use a single attribute-value assertion, LDAP permits a multi-valued RDN that combines two or more attribute-value pairs, typically joined with a plus sign (for example, cn=jdoe+uid=12345). Multi-valued RDNs are generally used to guarantee uniqueness among siblings when no single attribute is sufficient. Assuming an RDN is always one attribute can cause parsing and comparison errors in some deployments.

Which attribute should I choose for the RDN when creating directory entries?

The choice depends on your directory schema and naming strategy, and practices vary by deployment. Commonly used naming attributes include cn for people and groups and ou for organizational units, but the key requirement is that the chosen attribute value be unique among sibling entries under the same parent. Selecting an attribute whose value is stable over time is generally advisable, because changing an RDN triggers a rename operation. Verify the object class and mandatory naming attributes defined in your schema before deciding.

What happens if I need to change an entry's RDN?

Changing an RDN is a rename operation, handled in LDAP typically through the Modify DN operation. Because the RDN forms part of the entry's DN, renaming it changes the entry's DN and, in most directories, the DNs of any child entries beneath it. This can affect references held elsewhere, such as group membership attributes that store member DNs, unless your directory maintains referential integrity. Whether stale references are automatically updated depends on the server implementation and its configuration.

How do I handle special characters or reserved characters in an RDN value?

RDN values containing characters that have syntactic meaning in DN string representation, such as commas, plus signs, equals signs, or leading/trailing spaces, generally require escaping according to the DN string format rules. Failing to escape these characters can cause the value to be misparsed as a component boundary. The exact escaping rules and how they are applied depend on the string DN representation your tooling uses, so consult the relevant DN syntax specification and test with your directory client.

How does the RDN relate to SCIM provisioning or JWT-based identity claims?

The RDN is an LDAP directory naming concept and does not directly map to SCIM resource identifiers or JWT claims, which use their own identifier schemes. In deployments that provision from an identity source into an LDAP directory, the provisioning logic must decide which incoming attribute becomes the RDN attribute, and that mapping is a configuration concern rather than something the RDN concept defines. Do not assume a SCIM id, a JWT sub claim, and an RDN are interchangeable; they serve different purposes in different layers.

Common misconceptions

An RDN uniquely identifies an entry across the entire directory.

An RDN is only unique relative to its parent entry within the DIT. Global uniqueness is provided by the full Distinguished Name (DN), which is the sequence of RDNs from the entry up to the directory root.

An RDN and a Distinguished Name (DN) are the same thing.

They are distinct. The DN is the complete, hierarchically ordered path to an entry, whereas the RDN is a single relative component of that path. A DN is formed by concatenating the entry's RDN with the DN of its parent.

An RDN can only ever contain a single attribute-value pair.

While single-valued RDNs are most common, an RDN can be multi-valued, combining multiple attribute-value pairs with a plus sign to ensure uniqueness among siblings, depending on schema and deployment conventions.

Best practices

Choose naming attributes for RDNs that are stable over the lifecycle of the entry, since changing an RDN alters the entry's DN and can break references or bindings that rely on it.

Verify that the chosen RDN value is unique among sibling entries under the same parent, and use a multi-valued RDN only when a single attribute cannot guarantee that local uniqueness.

Confirm that the attribute used as the naming attribute is permitted by the object class and schema of the target directory before provisioning entries.

Avoid embedding volatile or personally identifying data in the RDN where practical, because RDN changes propagate into the full DN and may affect access grants and audit trails.

When constructing full DNs, treat the RDN strictly as the relative component and rely on the complete DN for any operation that requires global uniqueness within the directory.

Document the RDN naming convention for each branch of the DIT so that provisioning, SCIM-driven synchronization, and administrative operations remain consistent across the deployment.