LDAP: Defining a X.500 Format Root or Suffix

The top entry in a LDAP DIT (Directory Information Tree) is, in the LDAP world, variously referred to as the root, the base or the suffix depending on the document, its author, day of the week or some other variable unknown to us.

The term Root DSE defines a kinda super root/suffix that defines all the DITs supported by the LDAP server (in the namingContexts operational attribute) as well as number of other operational objects.

There are multiple methods for defining the root or suffix.

This page defines an X.500 based method, which uses ou=name, c=country (though no formal X.500 root or suffix standard exists).

The easiest method we found was to use the structural objectClass organizationalUnit which has a single MUST attrribute of ou (organizationalUnitName) and to use the special extensibleObject to add the c (country) attribute. The LDIF fragment to add the root or suffix is shown below:

## DEFINE DIT ROOT/BASE/SUFFIX ####
## uses X.500 format
## replace example inc. and us with any appropriate text

## organizationalUnit is an STRUCTURAL objectclass and 
#  requires only an ou (organizationalUnitName) attribute
#  but does not contain c (country) which is added with an
#  extensibleObect
# this is an ENTRY sequence and is preceded by a BLANK line

dn: ou=Example Inc.,c=us
ou: Example Inc.
objectclass: organizationalUnit
description: Optional. An X.500 root or suffix name. As much text as you want  
 to place in this line up to 32K. Continuation data for the line above must 
 have <CR> or <CR><LF> that is, ENTER works 
 on both Windows and *nix system - new line MUST begin with ONE SPACE
objectClass: extensibleObject
c: us

Notes:

1. The c: us and objectClass: extensibleObject lines may be omitted from the LDIF fragment and LDAP will continue to work though it offends at a completeness level. Most LDAP servers do not validate that the DN (RDN) of the entry is covered by attribute definitions within the entry.
2. Officially Example Inc. in the above should be written as Example, Inc. for a real company name. If this format is used then the comma must be escaped using this format Example\, Inc.,c=us wherever it appears as a DN, which seems like a lot of effort for little reward.

OpenLDAP's OLC (cn=config) would use a definition of olcSuffix ou=Example Inc.,c=us in the appropriate olcDatabase section (slapd.conf would use suffix "ou=Example Inc.,c=us" in the database section.

ApacheDS would use suffix="ou=Example Inc.,c=us" in the <partitions><jdbmPartition ...> section of the server.xml file.

Subsequent entries would be added as shown in the LDIF fragment below:

## FIRST Level hierarchy - people 
## uses mixed upper and lower case for objectclass
# this is an ENTRY sequence and is preceded by a BLANK line

dn: ou=people, ou=Example Inc.,c=us
ou: people
description: All people in organisation
objectclass: organizationalunit

## SECOND Level hierarchy
## ADD a single entry under FIRST (people) level
# this is an ENTRY sequence and is preceded by a BLANK line
# the ou: Human Resources is the department name

dn: cn=Robert Smith,ou=people, ou=Example Inc.,c=us
objectclass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob  smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
carlicense: HISCAR 123

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.