Author: Jens Moller
Each Directory Server has a set of 'standard' attributes that are predefined
for use in building a Directory. This 'standard' set is anything but
standardized, and most Directory Vendors define things differently than
others. This has to do with the evolution of X.500 Directories and how they
spawned LDAP Directory Servers. The paths have diverged and as a result,
support and definition of some attributes is somewhat inconsistent.
RFC 2255 defines the current LDAP attributes. RFC 2251 and 2256 discuss
mapping DAP (X.500) to LDAP attributes. RFC 2116 discusses X.500 Attributes.
You will quickly discover that there are other sets of attributes that are
created by the vendor to support some of their internal admin functions, as
well as some sets that are in common use. Additionally, there are device and
application specific attributes defined.
It is the Directory Architects task to determine which of these match
the corporate or application needs, and when they
find that they need additional attributes, to extend the
Directory's attribute lists (thereby
extending the schema) to fill in the missing ones.
Object Identifiers, commonly referred to as OIDs, are unique identifiers
assigned to objects. They are used to uniquely identify many different
types of things, such as X.500 and LDAP directory objectclasses and
attribute types. In fact, just about everything in X.500 and LDAP
directory systems are identified by an OID. OIDs are also used to
uniquely identify objects in other protocols, such as they Simple Network
Management Protocol (SNMP).
OIDs are written as strings of dotted decimal numbers. Each part of an
OID represents a node in a hierarchical OID tree. This hierarchy allows
an arbitrarily large number of objects to be named, and it supports
delegation of the namespace. For example, all the user attribute types
defined by the X.500 standards begin with 2.5.4. The cn (common name)
attribute is assigned the OID 188.8.131.52, and the sn (surname) attribute
is assigned the OID 184.108.40.206.
An individual subtree of the OID tree is called an arc. Individual
arcs may be assigned to organizations, which can then further divide
the arc into subarcs if so desired. For example, Netscape
Communications has been assigned an arc of the OID namespace for its
own use. Internally, it has divided that arc into a number of subarcs
for use by the various product teams. By delegating the management
of the OID namespace in this fashion, conflicts can be avoided.
The X.500 protocol makes extensive use of OIDs to uniquely identify
various protocol elements. LDAP, on the other hand, favors short, textual
names for things: cn to describe the common name attribute and person
to identify the person object class, for example. To maintain
compatibility with X.500, LDAP needs a string representation of an OID
to be used interchangeably with the short name for the item. For example,
the search filters (cn=Barbara Jensen) and (220.127.116.11=Barbara Jensen)
OIDs are used to describe definitions as well. Under LDAP, you generally
use the name of the Attribute, Objectclass or Object if it is
already defined. When your create your own definitions, you will need
to assign an OID to each. You will still able to use the name that you
associated with the OID when you define your own structures.
Anyone should be able to get an OID root if they need one. IANA
hands out OIDs for free under the "Private
Enterprises" branch. The value that you are assigned by IANA should be
appended to the OID '18.104.22.168.4.1' and used as your private OID tree.
For example, if you are assigned '48989795' as your "Private
Enterprises" id, then your OID root is "22.214.171.124.4.1.48989795".
You will need an OID tree before you start creating your own Attributes
and Objectclasses. It takes at least a week to get one from IANA. Register
as soon as you know that need one.
We will focus on LDAP Directory attributes. In general, these evolved
from X.500, so many things are similar. X.500 attributes are far more
complex to define, where LDAP tends more towards a smaller subset of
data types and less ability to restrict data values. Neither is really
better than the other and as such you work with what is available.
LDAP attributes are simply fields that are used to describe 'things' about
an object. You have a default set of attributes that come with the
Directory Server, and you always have the ability to add more. Attributes
are used by Objectclasses, which are used by Objects. Any Objectclass
will have attributes that are used by other Objectclasses.
Attributes are not associated directly with an Object until that Object is
created. So, when you look at trying to represent your data as Objects,
you will go to the list of Attributes that are available and see which
ones that you might use. If you need additional attributes, you will
want to name them uniquely and you will want to associate your OID with
them. For example, if your OID is "126.96.36.199.4.1.48989795", you might
start your LDAP attribute arc at "188.8.131.52.4.1.48989795.1", and your first
attribute OID would be "184.108.40.206.4.1.48989795.1.1", and your second
one would be "220.127.116.11.4.1.48989795.1.2" and so on.
To better show this, lets defined 2 additional attributes. Assume my
company name is XYZ Corp. To make sure that my attribute names are
unique, I will preface the attribute name with "xyz". My 2 attributes
are for my products, the "Foo" and the "Bar". So, I want 2 attributes
named "xyzFoo" and "xyzBar". In my case, these are just going to be
represented as character strings, and I don't really care if the data
is entered in upper or lower case. I may want to search on these for
a data look-up, and since I don't care about the data being entered in
upper or lower case, I don't want my searches to care about upper or
lower case either. I want to allow all possible valid characters, not just
the 127 possible ASCII characters - Directories use a format called
UTF-8 to do this. There are other data types allowable, but I want UTF-8.
We now know a lot about the attributes. We know what kind of data we
will allow in them. We know how we want to access them. We know their
names and we know that we have OIDs available for them. In general they
would be defined as (iPlanet Example):
attribute xyzFoo 18.104.22.168.4.1.48989795.1.1 cis
attribute xyzBar 22.214.171.124.4.1.48989795.1.2 cis
The method of adding these to OpenLDAP is similar to the above,
except that OpenLDAP provides quite a lot more information about
how the data is to be used. For Active Directory, you will use an MMS
Snap-In and use a Windows tool to add the attribute; like OpenLDAP,
AD will capture more data about the attribute. Other LDAP Servers will
use their own unique methods to add new attributes.
These 2 attributes now can be used for something. Simply adding them to
the directory doesn't do anything, however, in order for these to become
part of an Object, they must be added to an Objectclass.
Objectclasses and Objects
OIDs are used to describe Objectclasses too. In our case, we might want
to use the LDAP arc, but since it is up to use to figure out how we want
to segment our OID, many people create a new arc for Objects and
Objectclasses. In this example, we will do that - "126.96.36.199.4.1.48989795.2"
is our start point for any Objectclasses that we create for ourselves.
We now have the option of adding our attributes to an established
Objectclass, or creating our own. Most of the time you will want to
leave the standard Objectclass definitions alone, unless they are
already being extended by functions within the Directory Server.
Active Directory, for example, creates a series of Objectclasses
that include other standard Objectclasses. These 'non standard'
Objectclasses are used to simplify the object modeling under Active
Directory, and its ok to add to these 'non standard'
Objectclasses - doing so allows you to use the provided Microsoft
Directory Management tools to administer your added attributes. In all
cases, document what you have done if you alter an existing Objectclass.
Objects are composed of Attributes. In order to quantify what makes up
Objects, Objectclasses were created. An object has to have at least one
Objectclass, however it can have as many as necessary to define everything
that describes the Object. This may seem odd, why not just allow every
attribute? You could ir you wanted to, however many attributes are quite
specific to certain things and really don't make much sense in a general
context. Some Objectclasses are subordinate to others (in that they are
used to further describe an entry by extending the original Objectclass).
In cases where you need new functionality, or you want a variation of
an existing Objectclass, you can create your own Objectclasses. You are
free to use any attributes that are defined as a part of the schema, even
attributes that are part of other Objectclasses that you will be including
in your Directory Entries. You will determine these details as a function
of how you plan to use your Objectclasses. You might choose to create a
Subordinate Objectclass, or one that only has the attributes that you want
I will create a simple Objectclass that requires xyzFoo and xyzBar (using
Objectclass "xyzObj1" is subordinate to Top (in iPlanet and OpenLDAP
Objectclasses always are). When you create an entry with Objectclass
"xyzObj1" in it, the entry must contain some value for both "xyzFoo" and
"xyzBar". In it simplest terms, the Directory entry for above would
look like (assuming the tree "dc=xyz, dc=com"):
dn: xyzFoo=Text, dc=xyz, dc=com
xyzBar: More Text
This is not a very complex object, but it may be all that is needed.
We now want to have an Objectclass where these are not required, but
can be used if we want to use either of them:
Notice that the OIDs are different this allows me to have both of these
Objectclasses active at the same time, in fact I can use them both
at the same time (not very useful, but valid):
dn: xyzFoo=Text2, dc=xyz, dc=com
dn: xyzBar=More Text2, dc=xyz, dc=com
xyzBar: More Text2
dn: xyzFoo=Text3, dc=xyz, dc=com
xyzBar: More Text3
All of the above 3 objects are valid and appropriate uses of the defined
dn: xyzFoo=Text4, dc=xyz, dc=com
The above Object would fail to be added because of an "Objectclass
Violation". Even though attribute "xyzBar" is optional in "xyzObj2",
it is required in "xyzObj1". Since one of the Objectclasses is not
satisfied, the entry is invalid.
The odds are very good that you will be using some standard Objectclasses.
You will need to know what the definitions of these are, as well as what
attributes are required, and which ones are optional. In the case of
iPlanet and OpenLDAP, all you need to do is look at the files that contain
these definitions. In Active Directory, you will need to use the MMS
snap-in for Active Directory management to see what is required and what
Originally, X.500 was envisioned as a way to track people and their job
functions. There are quite a few 'People' related attributes and a small
set of 'People' related Objectclasses. Additional application services
saw the power of the Directory and Objectclasses that serve these functions
have been created; many based on IETF RFCs for services. X.500 did not
provide a great number of Objectclasses, rather leaving as much of this
definition phase to the Directory Administrators. iPlanet (Formerly
Netscape) expanded on the original university work of Tim Howes at
the University of Michigan. As a result, a number of fairly common
Objectclasses evolved. Unfortunately, there are still inconsistencies in
naming conventions across various vendors LDAP and X.500 Servers.
Because of this, most commercial LDAP tools are made to adapt to the
different naming conventions used.
LDIF stands for LDAP Data Interchange Format. It is defined within RFC
2849. This format is how we have been representing Objects within the
Directory. In simplest terms, the attribute name is followed by a ':' -
such as 'dn:', 'objectclass:' and our 'xyzFoo:' attribute. A 'dn:' must
be the first thing that appears in an entry, however the order that the
rest of the Attributes and Objectclasses are listed are not important.
There is a single blank line separating entries. You can have as many
entries as you want in a single LDIF file.
An LDIF file can often be used to reload a Directory from, since it
describes Directory entries in terms of their Object relationships. Most
Directory Servers provide a method to dump all (or a portion) of a Directory
to an LDIF format file, as well as load from an LDIF format file.
LDIF files are processed one entry at a time. If there is a problem with any
entry, it is simply skipped. However, unless you capture the errors into
a file when you reload the database, its quite possible that you will lose
many entries and not realize it. This is particularly true if rebuilding
a database from scratch and some of the user defined Attributes and
Objectclasses are missing.
For iPlanet and OpenLDAP functionality, See the utilities 'ldapadd',
'ldapmodify' and 'ldapdelete'. Active Directory has a similar command line
tool called 'ldifde'
Comments? Questions? Contact Support@AIE-Services.com