CS406: Information Security

We refer to entries by their attributes. This means that each entry must have an attribute or group of attributes that is unambiguous at its level in the DIT hierarchy. This attribute or group of attributes is called the entry's relative distinguished name or RDN and it functions like a file name.

To refer to an entry unambiguously, you use the entry's RDN combined with all of its parent entries' RDNs. This chain of RDNs leads back up to the top of the DIT hierarchy and provides an unambiguous path to the entry in question. We call this chain of RDNs the entry's distinguished name or DN. You must specify the DN for an entry during creation so that the LDAP system knows where to place the new entry and can ensure that the entry's RDN is not being used by another entry already.

As an analogy, you can think of an RDN as a relative file or directory name, as you would see in a file system. The DN, on the other hand is more analogous to the absolute path. An important distinction is that LDAP DNs contain the most specific value on the left-hand side, while file paths contain the most specific information on the right-hand side. DNs separate the RDN values with a comma.

For instance, an entry for a person named John Smith might be placed beneath a "People" entry for an organization under example.com. Since there might be multiple John Smiths in the organization, a user ID might be a better choice for the entry's RDN. The entry might be specified like this:

dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

We had to use the inetOrgPerson objectClass to get access to the uid attribute in this instance (we still have access to all of attributes defined in the person objectClass, as we will see in the next section).