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

Schemas

ObjectClass definitions and attribute definitions are, in turn, grouped together in a construct known as a schema. Unlike traditional relational databases, schemas in LDAP are simply collections of related objectClasses and attributes. A single DIT can have many different schemas so that it can create the entries and attributes it needs.

Schemas will often include additional attribute definitions and may require the attributes defined in other schemas. For example, the person objectClass that we discussed above requires that the surname or sn attribute be set for any entries using the person objectClass. If these are not defined within the LDAP server itself, a schema containing these definitions could be used to add these definitions to the server’s vocabulary.

The format of a schema is basically just a combination of the above entries, like this:

. . .

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

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
  DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )

attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
  DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )

. . .