When working with LDAP (Lightweight Directory Access Protocol), three fundamental naming components frequently appear: Relative Distinguished Name (RDN), Distinguished Name (DN), and Common Name (CN). While related, these serve distinct purposes in LDAP directory structures.

A Distinguished Name represents the complete, unique path to an entry in the LDAP directory hierarchy. Think of it like an absolute filesystem path in Unix systems. For example:

dn: cn=John Doe,ou=Users,dc=example,dc=com

The Relative Distinguished Name is the leftmost component of a DN - the part that uniquely identifies an entry within its immediate parent context. In our previous example:

rdn: cn=John Doe

The Common Name is frequently used as the naming attribute in RDNs, though other attributes like uid or ou can also be used. A CN example:

cn=Jane Smith

# Search using DN
ldapsearch -x -D "cn=admin,dc=example,dc=com" -W -b "ou=Users,dc=example,dc=com"

# Filter using RDN component
ldapsearch -x -b "dc=example,dc=com" "(cn=John*)"

When designing LDAP schemas, remember that while CNs are human-readable, they aren't guaranteed to be unique. For critical applications, consider using unique identifiers (uid) as RDN components instead:

dn: uid=jsmith123,ou=Users,dc=example,dc=com
objectClass: inetOrgPerson
uid: jsmith123
cn: John Smith
sn: Smith

• Assuming CN values are unique across the directory
• Confusing RDN with the entire DN
• Using spaces or special characters in RDNs without proper escaping

When entries need to be moved within the directory while keeping their RDN:

ldapmodrdn -x -D "cn=admin,dc=example,dc=com" -W \
"cn=Old Name,ou=Users,dc=example,dc=com" "cn=New Name"

In LDAP (Lightweight Directory Access Protocol), naming components form the backbone of directory structure. Let's break down the three key terms:

// Example LDAP entry in LDIF format
dn: cn=John Doe,ou=Users,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Doe
sn: Doe

The DN is the absolute path to an entry in the directory hierarchy. It's composed of multiple RDNs concatenated from leaf to root:

dn: cn=Jane Smith,ou=Engineering,dc=acme,dc=com

An RDN represents a single component of the DN. In the example above, "cn=Jane Smith" is an RDN. Key characteristics:

• Must be unique among its siblings
• Typically uses attribute-value pairs (e.g., cn=, ou=, uid=)
• Can be multi-valued (e.g., cn=John+sn=Doe)

The CN is a specific attribute type often used in RDNs. While sometimes confused with RDN, they're different:

// RDN using CN attribute
cn=Admin User  // This entire expression is the RDN
               // "cn" is the attribute type
               // "Admin User" is the attribute value

Understanding these concepts becomes crucial when constructing LDAP queries:

# Search using DN
ldapsearch -b "cn=admin,ou=special,dc=example,dc=com" "(objectClass=*)"

# Search using RDN components
ldapsearch -b "ou=People,dc=example,dc=com" "(cn=John*)"

Developers often encounter these issues:

1. Assuming CN must be unique across the directory (it only needs uniqueness within its parent)
2. Confusing RDN with the entry's display name (RDNs are structural, not necessarily descriptive)
3. Forgetting that DNs are read right-to-left (root to leaf)

Some implementations support complex RDNs:

dn: cn=Robert+sn=Johnson,ou=Users,dc=example,dc=com

This creates an RDN composed of multiple attributes, useful when single attributes don't guarantee uniqueness.