NOTE: A Directory Object can appear in any directory tree at any time. There is nothing in a tree structure that limits or restricts this in any way. It is the nature of a Directory to allow this to happen.

Directories are not relational databases. The concept of a table has no meaning in a Directory. Trees are groupings of any type of Directory Object that makes sense for that tree.

A Directory Object is a single unique entry within the Directory. Every entry in the Directory is an object.

ObjectClasses define what data may be in an Object. These things in an Object are called attributes. Attributes are simply data elements within a Directory Object.

ObjectClasses are lists of attributes that define an object type. Most Directory Objects are made up of more than one ObjectClass.

Attributes are defined in such a way that the definition is consistent no matter where an attribute of that type appears. All of the attributes are defined in some common location (could be one or more files, or in an internal structure some place) that the Directory server knows about when it starts up.

Attributes have an Object Identifier (OID) - this nothing more than a unique number that is associated with the attribute so that it can be differentiated against another attribute that might have the same name but different definitions. Every attribute needs to have its own OID. This is important if you need to define an attribute that is not already available as a part of the Directory definitions. OIDs will be discussed later in detail.

Attributes are simply bits of data that are used to describe things that appear as a part of an object. An Object can be anything, and one Object may possess one or more additional objects. To further define this, I will use the following example of a person:

Object: Person

Breaking down what might be used to describe the Object 'Person', we would list 'attributes' that we might be interested in knowing about that person:

• People have names
• People usually have phone numbers
• Many People have Email addresses
• People have home addresses (where they live)
• People live in many different places
• People wear cloths, and each person is unique in the sizes of clothes they wear, however, depending on where they shop for clothing and as such the size information may be different than somewhere else in the world, so you need to know:
  • Size standards for this persons location
  • Dress code standards for this persons location
• Currency used by this person

By doing this, we found that the environment that the person is in impacts attribute lists. We could go on and on, in fact we could, if we wanted, break down the details to the persons DNA/Genetic code - all of that information is valid attribute data. In most cases, this level of detail is not desired, however, sometime in the future, it is possible that new details about a Person, that was not anticipated initially, will be needed.

Objects, such as the Person object mentioned above, have attributes that are about the person, and others about the environment that the person operates in. Many Directories find it easier to manage this by breaking up the possible attributes into groups, called ObjectClasses, based on the types of things that the Objects represent. To tear the Person definition apart using this logic, we see that there are things about a person that reflect information about a person no matter who they are, or where they live. In the above example, that would be that 'People have names' - something that we must assume is always true (there may be exceptions, but we will assume that if a person exists, they have a name). But none of the other attributes are really required, because its possible that some people don't have any of the other 'attributes' to deal with. So our simplest ObjectClass is a Person, and they have a name.

    Objectclass: Person

      name

We still have many other attributes that we care about. Another logical grouping of Objects might be where they live. Looking at the above, the of that data could go into a group dependent on the locality where people live, or you could break it up into some other grouping. Often, since directories tend to be used for business functions, Objectclasess are usually broken up along lines that support business or functional lines. You might have a home telephone and an office telephone. You might also have a cellular phone and possibly a pager. Even email is related, since it is a means of communication, and it may be available thru your cellular phone or pager. All of these things are used to make contact, and while each is different, their purpose is similar. People have home addresses, and if they work outside of the home, they also have one or more business addresses- telephones exist at both locations. Its likely that a grouping of these attributes might belong to a business related Objectclass - so lets define one:

    Objectclass: contactInformation

      emailAddress
      homeTelephoneNumber
      officeTelephoneNumber
      cellularTelephoneNumber
      pagerNumber
      homeAddress
      businessAddress

Now if we created an entry with the Objectclasses 'Person' and 'contactInformation', we would almost be able to describe someone based on the above listed criteria for a real person. We still lack things that are associated with the locality of the person. Sometimes we won't need to know this about a person, but other times we will, so we might not always want to include this information. In case we do, we need to define an Objectclass that allows us to do this, we will call it Locality:

    Objectclass: Locality

      measurmentStandards
      dressCodeStandards
      currency

If we wanted to include the DNA/Genetic Code for this person, we could create an Objectclass called Genetic code and break down all the Genes a person has. There is no reason that you couldn't, and some day, for security measures, its possible that this level of detail will occur.

We now have a way of including all of the attributes that we originally originally discussed. We will now create the entry for the person.

To create an entry, you need to make sure that it is uniquely defined. You do this by creating a Distinguished Name and using that as the key to the entry. The Distinguished Name is made of up attributes that appear in the Directory Entry and tree structure information. The Tree Structure logic will be discussed later in detail, however for now, consider it part a logical grouping of entries within a Directory, and don't worry what it means.

The common way to represent a Distinguished Name is to call it a 'DN'. When you hear or see the term 'DN' it refers to a Distinguished Name, or a specific format of the data using DN naming conventions.

A 'DN' for 'John Smyth' might look like this:

    dn: name=John Smyth, dc=tree name, dc=tree root

The way directories work, each 'DN' must be unique. That means that in the tree 'dc=tree name, dc=tree root', there can only be one 'DN' that is equal to 'dn: name=John Smyth, dc=tree name, dc=tree root'.

This presents a problem when you start trying to add many entries. Somewhere along the line, you will start seeing random duplicate 'DN' entries because different people might have the same name as someone else. Because of this, its better to use a value that you know will always be unique to define the 'DN' than something that will probably cause duplicates to appear, and prevent the entries from being loaded. To avoid this, we will need an identifier that has some meaning to us. It could be the persons first names initial followed by the last name, such as:

    John Smyth -> jsmyth

and in situations where there is more than one John Smyth, you simply increment the value by adding a number to it, so the next John Smyth becomes 'jsmyth1' and the next after that becomes 'jsmyth2' and so on. Now we have problem, none of our Objectclasses know about this attribute, so, we will extend the Person Objectclass to have a 'User ID', which we will simplify to be 'uid' as an attribute name. Now the Objectclass Person looks like:

    Objectclass: Person

      name
      uid

And our 'DN' will change to:

    dn: uid=jsmyth, dc=tree name, dc=tree root

The 'DN' doesn't really care which attributes that you use to define it with, as long as the tree that you put it in exists. The benefit of using the 'uid' is that the names remain what they really are, and the 'uid' handles the uniqueness issues. Its possible that something else might be used, such as a number, or if this is for tracking employees, an employee number that is created by the Human Resources department. What ever makes sense for your Directory is what you should do to help simplify the issues of unique 'DN' entries in the Directory.

Now we are ready to build the entry record for 'John Smyth':

      dn: uid=jsmyth, dc=tree name, dc=tree root
      objectclass: person
      objectclass: contactInformation
      objectclass: locality
      name: John Smyth
      uid: jsmyth
      emailAddress: john.smyth@null.com
      homeTelephoneNumber: 123 456 7890
      officeTelephoneNumber: 123 654 0987
      cellularTelephoneNumber: 123 546 9870
      pagerNumber: 123 564 7980
      homeAddress: 55 Plum Street, Someplace Nebraska
      businessAddress: 321 North Main Street, Not-here Nebraska
      measurmentStandards: Inches, Feet, Yards, Miles, Acres
      dressCodeStandards: USA Business Casual
      currency: US Dollars

this puts the pieces together. We have a unique 'DN' entry for 'uid=jsmyth'. Look at the entry; you will see that the Objectclasses are used to define what appears in the entry. To review them, you will see that these 3 define the contents of the entry:

    Objectclass: Person

      name
      uid

    Objectclass: contactInformation

      emailAddress
      homeTelephoneNumber
      officeTelephoneNumber
      cellularTelephoneNumber
      pagerNumber
      homeAddress
      businessAddress

    Objectclass: Locality

      measurmentStandards
      dressCodeStandards
      currency

The entry lists which Objectclasses that the entry has, and the Objectclass defines the attributes that may appear within any entry that specifies the Objectclass.

The problem now is that we expect every attribute to have something in it. Directories do not allow you to have an attribute used that has no value to it, in fact there is not even a requirement that there be only on instance of an attribute per entry. For example, if John Smyth had 4 email addresses, the entry would have 4 instances of an email address. How do tell the directory which are required attributes and which are optional? You do it when you define the Objectclass.

Lets change the object classes so that they reflect data that we always have to have (marked with the the word 'Requires', and those things that don't need to be there (marked 'Optional'):

    Objectclass: Person
     Requires
      name
      uid
     Optional

    Objectclass: contactInformation
     Requires
      name
     Optional
      emailAddress
      homeTelephoneNumber
      officeTelephoneNumber
      cellularTelephoneNumber
      pagerNumber
      homeAddress
      businessAddress

    Objectclass: Locality
     Requires
      name
     Optional
      measurmentStandards
      dressCodeStandards
      currency

Two things happened. We added some structure to attributes in that we which ones are required and which are not, and we also made each object class include the 'name' attribute. A name is a name. Having the name in all of the Object classes makes sense because it forces that what ever is in there to have a name. Since the name attribute is defined the same no matter which object class it is in, and now, each object class requires the name, then having at least one instance of it in the entry satisfies all of the Objectclasses requirements for an entry. However now, many attributes are optional and as such, the minimum entry would look like:

      dn: uid=lpenelope, dc=tree name, dc=tree root
      objectclass: person
      objectclass: contactInformation
      objectclass: locality
      name: Lady Penelope
      uid: lpenelope

This satisfies the Person Objectclass (requires 'name' and 'uid'), it also satisfies the contactInformation Objectclass (requires 'name') and the locality Objectclass (also only requires 'name').

Each of the Object classes can be used independent of each other, for example:

      dn: name=India, dc=tree name, dc=tree root
      objectclass: locality
      name: India
      currency: Rupee

is a valid entry in the same directory tree that people also appear in, however, in this case, its not a person, but rather a place. We cannot use 'uid', because it is not a member of the Objectclass 'locality'. We could also have:

      dn: name=City of South Park, dc=tree name, dc=tree root
      objectclass: contactInformation
      name: City of South Park
      name: Fairplay
      emailAddress: City.Of.South.Park@colorado.gov
      emailAddress: ECartman@southpark.com
      emailAddress: webmaster@comedycentral.com
      officeTelephoneNumber: 719 555 1212
      businessAddress: 7763 West 1st Street, Fairplay Colorado

This is also another place, but its object class has a different set of attributes associated with it. You'll notice that 3 email addresses appear for the 'City of South Park' entry. This is because emailAddress is a multivalued attribute. Most attributes are multivalued (unless you specifically tell the directory otherwise). You also will notice that there are 2 'name' entries, one of which is used in the 'DN' and the other is not related at all. The one that appears in the 'DN' must always be a part of the entry, but any other 'name' definitions can be any value that you want them to be. There only needs to be one 'name' instance, but there is no limit to how many 'name' instances you have. Now if you search the directory for the 'name' and 'City of South Park' or 'Fairplay', you will find the same entry.

There may be hundreds of Objectclasses that operate within a directory and most will share some attributes that appear in other Objectclasses. Since the attribute is defined with a specific syntax, it doesn't make any difference that multiple Objectclasses use it, they inherit the attribute definitions.

Comments? Questions? Contact Engineering