ure     ORG      <-- Go to document source | [ure.org]

1.1 Why LDAP?

The Lightweight Directory Access Protocol (LDAP) and the servers that implement it allow all of us to offload profile and naming management to a tool designed to manage such things and store and publicize them in a standard way. That makes our lives easier. In fact, LDAP is to naming what HTTP is to human interfaces and SQL is to tables. It's important to understand what information should and what information should not be stored in an LDAP server. I found a note about the fundamental differences between a Relational Database Management System (RDBMS) like Oracle or MS Access, and a directory service like LDAP. Two things stand out.

  1. LDAP allows finer grained access control over information entries (important for profile data) and
  2. LDAP adapts better to attributes that are multivalued and data that is not naturally tabular.
So for example, while I would use an Oracle 9i (an RDBMS) to store a catalog of all the garden tools and implements I want to sell on the web, I would use iPlanet Directory Server (an LDAP server) to store information about all the users who have visited my gardenimplements.com web site. Note that I personally feel that LDAP's bad documentation, ugly tools, and mediocre integration with apache, passwd, and java will be overcome because the basic idea is a good one.

1.2 LDAP directories

An ldap database is entirely made up of a number of individual records, or entries. Each entry has a number of attributes, which are just name-value pairs like 

surname: Rumplestiltskin
Each attribute may normally be multivalued. For example, a single entry may have 
phoneNumber: 917 541 6456
phoneNumber: 212 866 8569
In general, these attributes contain information about the real-world item that is described by the entry.

In addition, there are two special kinds of attributes. Every entry has a special attribute dn which is a globally unique identifier also referred to as a distinguished name (more about that in section 1.4). In addition, the special attribute objectclass refers to a definition that specifies a group of required attributes and a group of allowed attributes (more about that in section 1.3). So a typical entry has an objectclass attribute, a dn attribute, all of the other attributes required by its objectclass and some of the attributes allowed by the objectclass.

1.3 Schemas

Much like a relational database, every ldap database (or directory) has a schema. I found that chapters 2 and 3 of the IBM Redbook: Understanding LDAP make a decent schema overview of this somewhat complicated subject, but here are the basics. An LDAP schema is implemented as set of objectclass definitions, attribute definitions. So before you start creating entries in your directory, you need to create an schema for it. Or more likely, just borrow a schema from somebody else. Your LDAP server will come with a bunch of attribute and objectclass definitions which are useful right off the bat. In particular, for people I like the objectclass inetOrgPerson and all the attributes it allows.

Some details: an entry has two or more objectclass attributes. One is either the value "top" or the value "alias". Alias means the entry is an alias for another entry. If the entry has one of its objectclasses being "extensibleObject" that means any attribute is allowed. An attribute has a type associated with it. Attribute names are global. That is, once I've defined an attribute phoneNumber, I can require that attribute for a person or for a company objectclass. You may limit the number of values an attribute may have, or an individual attribute's size. Some objectclasses are defined as structural, all other objectclasses are auxiliary. An entry must contain exactly one structural objectclass.

1.4 DITs

Now, back to DNs. As was noted above, each LDAP entry must have a globally unique name. This is done by putting in place a global naming hierarchy, much like computers are given globally unique domain names like linux.subtheory.com or ldap.umich.edu. For LDAP, this hierarchy of names is called the Directory Information Tree or DIT.

Sample DIT

                   dc=subtheory, dc=com
                          (root)


        ou=people                        ou=remoteAccounts


Thus, if Joshua Davis was a user on a webmail application on one of my servers his entry would be named 
dn: uid=joshua, o=webmail, dc=subtheory, dc=com
A person listed on Yahoo's 411 server might be stored as 
dn: cn=Gong Szeto, o=people, dc=yahoo, dc=com

Sample LDAP Entry

dn: cn=Joshua Davis (joshua),ou=people,dc=subtheory,dc=com
cn: Joshua Davis (joshua)
cn: Joshua Davis
sn: Davis
initials: JD
givenname: Joshua
mail: joshua@praystation.com
mail: jdavis@kioken.com
uid: joshua
inetAuthorizedServices: clos.ure.org
inetAuthorizedServices: webmail
inetAuthorizedServices: upload
userPassword: {SHA1}iowCaio.67
signature: 'Joshua Davis \n joshua@praystation.com'
forwardAsAttachment: TRUE
formattingPreferences: plaintext
remoteService: cn=homeemail,uid=joshua,ou=remoteAccounts,dc=subtheory,dc=com
remoteService: cn=workemail,uid=joshua,ou=remoteAccounts,dc=subtheory,dc=com
objectclass: top
objectclass: inetSubscriber
objectclass: inetOrgPerson
objectclass: subtheoryWebMailUser
objectclass: remoteServiceUser

Public LDAP Directories

ldap://ldap.bigfoot.com
ldap://ldap.columbia.edu
ldap://ldap.fnal.gov/o=fnal [FermiLab]

Web-based Interfaces to LDAP Servers

ldap.openldap.org
directory.verisign.com
ldap.itd.umich.edu
browse any ldap server

Sidebar: Specifying subschema

The general idea with subschema is that you want to have a different schema for some particular branch of the Directory Information Tree (DIT). For example in the ou=users branch of the tree you might want to only allow the use of inetOrgPerson and its superior schema.

I think I understand how this is done in general. Depending on the implementation, each entry can have a subschemasubentry attribute which points to an entry describing the subschema. That means that any entries which are below that entry in the DIT use that subschema.

I think that openldap will return the same subschemasubentry value for any entry in its database, which actually points to the root schema so essentially there are no subschemas. Check the openldap schema page, the Introduction to X.500, a note on the openldap list about subschema, and a note on the openldap list about schema: "Each administrative area held by the server can, if the implementation supports such, have a separate subschema. [OpenLDAP doesn't support this yet, some other implementations do].", and and this note about querying for subschema

.

or email to admin@ure.org