Creating Your Own Schemas

I l @ ve RuBoard

The "stock" LDAP schemas are quite extensive . When you add in the registered schemas created by individual organizations, just about every piece of information that you could possibly imagine can be represented with a schema.

Still, the day might come when you find that you have to record the tail length of a user 's pet llama or the number of goldfish that someone can eat in a minute, or, on a more practical note, something important to your business, such as health insurance identification numbers . This is when you'll want to extend the LDAP schema universe.

To understand the process, let's look at two schema entries from the core LDAP set.

 attributetype ( 2.5.4.13 NAME 'description'      EQUALITY caseIgnoreMatch      SUBSTR caseIgnoreSubstringsMatch      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}  ) objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL      MUST ( sn $ cn )      MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) 

The first line defines an attribute type called description . It has a unique attribute ID number of 2.5.4.13, is compared to itself with no case sensitivity, looks for substrings also without case sensitivity, and is an object of type 1.3.6.1.4.1.1466.115.121.1.15 (which is a string, believe it or not) with a maximum length of 1024 characters .

The second entry defines an object class called person , which is derived from the top object, must have a surname and a common name, and may have a password, a telephone number, a "see also" entry, and a description. It has a unique ID number of 2.5.6.6.

The unique ID numbers are important because they're what the data placed in the database is associated with. Theoretically, if you never were going to want outside groups to be able to access your LDAP data, you could use any old IDs to create your new entries, as long as they didn't overlap with a number that you would be using from existing schemas.

In reality, it's not much good to store your data in LDAP if you don't plan to share it, at least internally. A SQL database is usually much more efficient for data that won't be shared among applications or organizations. And you don't want your data to conflict with a schema that you might decide to include in your LDAP implementation at a later date. Thus, it's worth getting your own prefix so that you can assign your own LDAP ID numbers without conflicting with anyone else's.

Technically, the number that you're applying for is an object identification number (OID), and you get it from the Internet Assigned Number Authority (IANA). These are the same folks who do things such as track assigned port numbers.

As far as IANA is concerned , you're actually applying for a private enterprise number, which is the prefix that you use to extend an Simple Network Monitoring Protocol (SNMP) Management Information Base (MIB). A MIB is a description of what remote monitoring can be done to a specific piece of hardware or software attached to a network, using the SNMP protocol. It turns out that these numbers use the same numbering system, so applying for one is the same as applying for the other. You can find the form at http://www.iana.org/cgi-bin/enterprise.pl. It takes about a week to get the number back.

When you've received your prefix, you can use it to create a new schema file for the data that you want to collect, and then you can configure your slapd.conf file to make that schema available.

I l @ ve RuBoard