The DN describes the contents of attributes in the tree (the navigation path) that will reach the specific entry required OR the search start entry.
A DN is comprised of a series of RDNs (Relative Distinguished Names) found by walking UP the tree (DIT) to its root (or suffix or base) and is written LEFT to RIGHT unlike the file system analogy you see quoted everywhere which is written RIGHT to LEFT.
The DN is written LEFT to RIGHT.
When a new entry is added to the DIT a DN is used to tell the server how to structure (or place) the entry. An example of new entries being added is shown below as an LDIF file (they could equally have been added using an LDAP Browser or a specialised LDAP client tool).
version: 1
## version not strictly necessary but good practice to include for future
## DEFINE DIT ROOT/BASE/SUFFIX ####
## uses RFC 2377 format
## dcObject is an AUXILIARY objectclass and MUST
## have a STRUCTURAL objectclass (organization in this case)
# this is an ENTRY sequence and is preceded by a BLANK line
dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.
## FIRST Level hierarchy - people
# this is an ENTRY sequence and is preceded by a BLANK line
dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit
## SECOND Level hierarchy - people entries
# this is an ENTRY sequence and is preceded by a BLANK line
dn: cn=Joe Schmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales
The above LDIF creates the directory structure shown:
In general, it does not matter what attribute value is used to add a new entry as long as the 'dn:' is unique. The above example has chosen to use cn=Joe Schmo in the last entry for this purpose. It could equally have been, say, uid=jschmo. LDAP searching can use any attribute or combination of attributes and can thus find entries irrespective of the 'dn:' value used to create the entry. To avoid excessive searching, in most cases it makes sense to use a 'dn:' value that represents an entry's most frequently used access DN. Thus in the above example is would be assumed that most directory access would use the cn= attribute.
However, if the entry is going to be used for user authentication, the creation 'dn:' value becomes extremely important and defines the only possible logon DN. The reason for this behavior is that authentication is accomplished using an LDAP Bind operation which demands a Bind DN (and an optional password) and does NOT allow any search operation. Thus, the Bind DN CAN ONLY be the DN used when the entry was added or created. the following LDIF file creates a dn using the uid attribute which is more normal for authentication LDAP systems:
version: 1
## version not strictly necessary but good practice to include for future
## DEFINE DIT ROOT/BASE/SUFFIX ####
## uses RFC 2377 format
## dcObject is an AUXILIARY objectclass and MUST
## have a STRUCTURAL objectclass (organization in this case)
# this is an ENTRY sequence and is preceded by a BLANK line
dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.
## FIRST Level hierarchy - people
# this is an ENTRY sequence and is preceded by a BLANK line
dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit
## SECOND Level hierarchy - people entries
# this is an ENTRY sequence and is preceded by a BLANK line
dn: uid=jschmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales
The above LDIF creates the directory structure shown:
LDAP standards, somewhat confusingly, do not use any special terminology when refering to the DN used to intially create the entry. However, this 'creation' DN is sometimes - especially in the context of LDAP used within Microsoft's AD - referred to as a Principal DN, primarily due its use as a Principal (Security Principal) within Kerberos.
