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.

OIDs

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 2.5.4.3, and the sn (surname) attribute is assigned the OID 2.5.4.4.

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 (2.5.4.3=Barbara Jensen) are equivalent.

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 (http://www.iana.org) - hands out OIDs for free under the "Private Enterprises" branch. The value that you are assigned by IANA should be appended to the OID '1.3.6.1.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 "1.3.6.1.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.

Attributes

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 "1.3.6.1.4.1.48989795", you might start your LDAP attribute arc at "1.3.6.1.4.1.48989795.1", and your first attribute OID would be "1.3.6.1.4.1.48989795.1.1", and your second one would be "1.3.6.1.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. (see: http://www.wu-wien.ac.at:8082/rfc/rfc2279.hyx/2._bUTF-8_bdefinition)

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  1.3.6.1.4.1.48989795.1.1  cis
      attribute  xyzBar  1.3.6.1.4.1.48989795.1.2  cis

NOTE: 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 - "1.3.6.1.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.

NOTE: 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 in it.

I will create a simple Objectclass that requires xyzFoo and xyzBar (using iPlanet syntax):

      objectclass xyzObj1
         oid 1.3.6.1.4.1.48989795.2.1
         superior top
         requires
           xyzFoo,
           xyzBar

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
      objectclass: top
      objectclass: xyzObj1
      xyzFoo: Text
      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:

      objectclass xyzObj2
	 oid 1.3.6.1.4.1.48989795.2.2
	 superior top
	 requires
	   objectclass
	 allows
	   xyzFoo,
	   xyzBar

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
      objectclass: top
      objectclass: xyzObj2
      xyzFoo: Text2

      dn: xyzBar=More Text2, dc=xyz, dc=com
      objectclass: top
      objectclass: xyzObj2
      xyzBar: More Text2

      dn: xyzFoo=Text3, dc=xyz, dc=com
      objectclass: top
      objectclass: xyzObj1
      objectclass: xyzObj2
      xyzFoo: Text3
      xyzBar: More Text3

All of the above 3 objects are valid and appropriate uses of the defined Objectclasses.

      dn: xyzFoo=Text4, dc=xyz, dc=com
      objectclass: top
      objectclass: xyzObj1
      objectclass: xyzObj2
      xyzFoo: Text4

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 is optional.

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 Format

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 Engineering