Author: Jens Moller
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:
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
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.
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
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:
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
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:
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
name: John Smyth
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:
The entry lists which Objectclasses that the entry has, and the Objectclass
defines the attributes that may appear within any entry that specifies the
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'):
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
name: Lady Penelope
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
dn: name=India, dc=tree name, dc=tree root
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
dn: name=City of South Park, dc=tree name, dc=tree root
name: City of South Park
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
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
Comments? Questions? Contact Engineering