One of the reasons behind the popularity of LDAP directories (and one of the reasons for LDAP's ongoing success) is its adaptability to store so many types of information. The LDAP schema defines and controls the types of data which may be stored for individual LDAP entries. In four parts, this article will cover the a few of the basics you'll need to begin the customization of your LDAP Directory server's schema to meet your needs.
What is an LDAP Directory Schema?
In an LDAP directory, the schema is the collection of defined attributes, defined object classes, and ACIs to control which data is stored where.
Any database, regardless of its complexity or underlying technology, has a schema. In simple terms, a schema is the data model, the design with regards to how the data is stored, what types of data are tracked, and the relationships between data stored in various entries.
When setting up your LDAP directory, the information for any given entry is stored in a series of attributes. You may create new value types which may be stored in the directory.
Collectively, all the attributes which may be used for a specific type of object are called an Object Class. As with attributes, you may define new object classes to meet your needs. Within each object class, you may designate that some attributes are required, and that others are merely optional.
(For those with a traditional database background, it may be helpful to think of it this way: fields are similar to attributes, tables are similar to object classes.)
In addition, you can design your LDAP directory tree to so that you can store similar objects together in the same branch of the LDAP directory.
Understanding LDAP Attributes
Simply put, an attribute is a container that may be used to store a single type of information within your directory. For example, when describing your car, you might track many of its attributes including color, make, model, year, license plate number, and the state, province, or country that issued the license.
Each of these attributes describes an individual attribute of your car. In general, you'll want to break data apart whenever possible. (Notice how the License plate information are split apart?)
Schema customization allows the administrator to designate as many types of attributes as needed. If you want to track favorite food, birthday, hiring date, or any thing else -- all you have to do is add the appropriate attributes to your directory' server's configuration file
When defining an attribute, you will specify each of the following aspects. We'll cover each of these items in detail.
For starters, before your create a new attribute type you want to check whether there's a "standard" attibute designated for this purpose. Links to sites listing well defined attributes and object classes may be found at: http://www.ldapman.org/schema-references
Assuming that an existing attribute does not already exist, you'll need to add your own. To start, every attribute needs a name. Your attibute name should be chosen so as to avoid any potential conflicts with attributes that may become "officially designated" in the future. You may wish to use your company's or organization's name to begin your attibute name. For example, at Gizmo, Inc., they track the parking pass IDs handed out to each employee. When defining their schema, Gizmo's LDAP administrator might choose the attribute name "gizmoParkingPassNumber". They can be reasonably certain that this attribute will never conflict with "officially defined" usage at a later time.
Notice the capailitazion in "gizmoParkingPassNumber". It's purely aesthetic, but you'll typically see attributes (and object classes) listed in this format. The first word is always lower case, and the first initial of each subsequent word is capatalized. Your attribute name should be long enough to be reasonably self descriptive, and may be composed of the letters a-z, the numbers 0-9, and the dash character. (The initial character must be a letter.) Spaces, underscores, and special characters are not permitted.
A one-sentence definition of the attribute's intended usage.
Object Identifiers, or OIDs, are the numeric reference numbers used by the LDAP directory's internal database mechanism. The attribute names are there for you and me, but computers are most efficient when dealing with numbers. If you're familiar with DNS, the concept is fairly similar -- most of us use hostnames like www.sendmail.net, but the computers translate the "human friendly" name into an IP address before they get down to work.
When folks at Gizmo specify an attribute name of "gizmoParkingPassNumber", the computer converts the name into the corresponding OID number for storage and retreival, in this example the OID number would be 220.127.116.11.4.1.1234.
Do you need to register for your own OID number before you can create custom attributes and object classes? The answer depends on your Directory server. Many of the Directory servers out there simply allow you to specify an alphanumeric name for an oid number. If Gizmo hadn't registered for an OID, they may have assigned the "gizmoParkingPassNumber" attribute an OID of "gizmoParkingPassNumber-oid". It's still unique, and as such it still serves to fit the purpose.
You may not need to register your own OID, but it's still a good idea. LDAP attributes, syntax definitions, and object classes all use OIDs. So do SNMP and other protocols that support the ANSI unified identification scheme.
Getting your own OID is fairly easy. You can go to ANSI (American National Standards Institute) and pay $1000 for a number, or you can get one for free from the Internet Assigned Numbers Authority at www.iana.org
When you set up each attribute, part of the specification includes the
syntax you wish to use. The most common syntaxes are listed here:
|dn||Distinguished Name||Allows any alphanumeric string.
Pattern matching against fields of type DN are normalized for DN equivalency. For example,
"uid=ratboy,ou=accounts,dc=ldapman,dc=com" is equivalent to
"uid=Ratboy, ou=Accounts, dc=LDAPman, dc=com"
|cis||Case Ignore String||Allows any alphanumeric string. Information stored using cis is stored with the case preserved, but matches are performed with case ignored. This is the most commonly used syntax type because of its versatility.|
|ces||Case Exact String||Allows any alphanumeric string. Matches against attributes of format cis are case sensitive. Used for attributes like passwords, where you only wish to match exact strings.|
|int||Integer||Allows only integers to be stored in this attribute.|
|tel||Telephone Number||Like cis, but when searching against attributes of this type, the match ignores spaces and dashes. This allows "510-555-1212" to match "510 555 1212".|
|bin||binary||Used to store binary data in a standardized format.|
Some LDAP directories allow you to add customized syntaxes to the directory store. While the details on how to do this is beyond the scope of this article, I'll mention in passing when you'd want to do this. When creating your own syntax, you can program the directory server to allow only certain characters in that attribute, and you can specify how matches against that attribute are performed.
Let's say you wanted to store hexadecimal codes in your directory, and that you didn't want to worry too much about what format the codes were stored in. (Some might enter "00 A2 34 FF" while others might enter "00a234ff", and a third person might enter "00a2.34ff". You want searches on any of these formats to match.) To meet your needs, you would define a new syntax of type "hex" (CHECK THIS!), allowing characters 0-9, A-F, spaces, and periods . Matches would be case-insensitive and normalized to remove all spaces and periods. Presto! Mission accomplished. For more information about creating customized syntaxes, please check the documentation for your specific Directory server.
Pardon me, are you single?
Some (but not all) Directory servers allow you to specify that attributes are "single". Use of the "single" attribute is made when you want to guarantee that for a given record in your directory, there is at most one value for that type of attribute. Consider an entry for Mike Jones. You might store multiple entries for his CN (one for "Mike Jones", one for "Michael Jones") but when storing his primary email server you wish to guarantee that at most there is a single value.
That's it for now. In part 2 of this article, we will discuss object classes and how they are built from attributes. In part 3, we will use the information from parts one and two to design a few new object classes and to customize your LDAP directory schema.
I hope you've found this article useful. Please check back soon at www.sendmail.net for parts two and three of this article.
If you have comments or questions, send email to firstname.lastname@example.org.
3 august 2000