The LDAP Schema

I l @ ve RuBoard

Like SQL, the heart of LDAP is a schema (or set of schemas). An LDAP schema defines what kind of data will be stored and how it's organized. For example, you might have a schema object called a person that stores information such as last name and title.

What makes LDAP powerful is that every entry in an LDAP database has a uniquely identified type or set of types. Because the schemas are globally registered, and because every datum is associated with one or more universally unique type identifiers, you know that if an object has the person object class, you'll be able to ask for the givenName attribute to get the first name. Moreover, because each datum reports its type(s), and because you can get schema definitions from the LDAP server, you'll always know exactly what type of information an LDAP entity holds.

In LDAP, each object is uniquely identified by a distinguished name (DN). The DN allows you to make a reference to the object that identifies only that particular piece of data. A DN consists of a series of attributes that uniquely identify the object. They're a bit like a domain name, in that the most general piece of information is rightmost in the DN.

For example, you might want an object that represents your company as a whole (which typically would serve as the root object for all the objects dealing with your company). A common scheme for this is to use the o (organization) attribute, with your domain name as the value. So o=bfg.com is the DN that uniquely identifies your company.

If you want to talk about the marketing division, you could use the ou attribute (organizational unit) ”thus ou=marketing,o=bfg.com . As mentioned before, the most specific piece of information is placed leftmost.

Now say that you want to talk about Bob Jones, who works in marketing. You would use the uid ( user ID) field along with a unique identifier ”for example:

 uid=bjones, o=bfg.com 

Note that you don't need to specify ou=marketing in the DN because the uid and o attributes are enough to uniquely distinguish Bob, unless different departments have overlapping user IDs (a large corporation might). In that case, the DN would be this:

 uid=bjones, ou=marketing, o=bfg.com 

Another DN for a computer might be this:

 uid=deepthought, ou=webservers, ou=hardware, o=bfg.com 

This DN specifies a server named deepthought, which is a Web server. All the computers are further placed under the hardware OU and finally are organized under the bfg.com organization.

The leftmost element in a DN is called the relative distinguished name (RDN). That is because that element distinguishes among different entities that live below the object specified by the remainder of the DN.

In LDAP, each object can both store data and be the parent of objects that also store data. So, an organization object can both store information about the organization and have children (the employees , or organizational units, or products sold). In the Windows world, the Windows Registry works in the same manner.

Objects have two properties associated with them. They have object classes that they are members of, and they have attributes of those object classes.

The object classes define what attributes are available to an object through the LDAP schema. Object classes have a hierarchy; if you create an object of type OrganizationalPerson , which is a derivative class of person , you'll get all the attributes available to person as well. However, if you do a search and specify objectClass=Person , you won't get these objects, which is something to look out for.

Attributes are individual properties associated with the class. For example, Person has attributes such as sn ( surname ) and givenName .

I l @ ve RuBoard