Lightweight Directory Access Protocol (LDAP)

To understand Lightweight Directory Access Protocol (LDAP) you must first understand directory services. This article defines directory services and how LDAP structures the entries in a directory service. Pay attention to the basic LDAP components such as attributes, entries, and data information trees (DITs). How does LDAP organize data, and what is LDAP inheritance? Note that there are some variations in LDAP protocols.

Defining LDAP Data Components

ObjectClass Definitions

Attributes are collected within entities called objectClasses. ObjectClasses are simply groupings of associated attributes that would be useful in describing a specific thing. For instance, "person" is an objectClass.

Entries gain the ability to use an objectClass's attributes by setting a special attribute called objectClass, naming the objectClass you wish to use. In fact,  objectClass is the only attribute you can set in an entry without specifying a further objectClass.

So if you are creating an entry to describe a person, including objectClass person (or any of the more specific person objectClasses derived from person – we'll cover this later) allows you to use all of the attributes within that objectClass: 

dn: . . .
objectClass: person

You would then have the ability to set these attributes within the entry:

  • cn: Common name
  • description: Human-readable description of the entry
  • seeAlso: Reference to related entries
  • sn: Surname
  • telephoneNumber: A telephone number
  • userPassword: A password for the user

The objectClass attribute can be used multiple times if you need attributes from different objectClasses, but there are rules that dictate what is acceptable. ObjectClasses are defined as being one of several "types".

The two main types of ObjectClasses are structural or auxiliary. An entry must have exactly one structural class, but may have zero or more auxiliary classes used to augment the attributes available to the class. A structural objectClass is used to create and define the entry, while the auxiliary objectClasses add additional functionality through extra attributes.

ObjectClass definitions determine whether the attributes that they provide are required (indicated by a MUST specification) or optional (indicated by a  MAY specification). Multiple objectClasses can provide the same attributes and an attribute's MAY or  MUST categorization may vary from objectClass to objectClass.

As an example, the person objectClass is defined like this:

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

This is defined as a structural objectClass, meaning that it can be used to create an entry. The entry created must set the surname and  commonname attributes, and may choose to set the userPassword, telephoneNumber,  seeAlso, or  description attributes.