These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

LDAP01/LDIF Attributes

Classnotes | LDAP01 | RecentChanges | Preferences

As we have seen the basic format for a given line in an LDIF file is defined by attributes and values separated by colons:
 attribute: value

We have also seen that LDIFs allow for multivalued attributes using commas:

 attribute: value1,value2,value3

So what possible attributes are there? The answer to this is "many", and the attribute definitions vary from purpose to purpose. Completely examining all possible attributes is beyond the scope of this course. However, over the next several days you will gain an understanding of attribute definitions and schema files (next section) such that you will be able to find the attributes for yourself.

So, in this section, we will simply be examining some of the more universal attributes as well as delving into their usage and syntax.

Attribute Syntax

An attribute type's definition lays the groundwork for the answers to questions like, "What type of values can be stored in this attribute?", "Can these two values be compared?", and, if so, "How should the comparison take place?"

Let's take a look at the telephoneNumber entry we just saw as an example. Suppose you search the directory for the person who ones the phone number 885-9162. This may seem easy when you first think about it, however RFC 2252 explains that a telephone number can contain characters other than digits (0-9) and a hyphen (-). By this definition, a telephone number can include:

  • a-z
  • A-Z
  • 0-9
  • Various punctuation characters such as commas, periods, parentheses, hyphens, colons, question marks and spaces

Thus, 885.9162 or 885 9162 are correct matches for the search we've requested. Then, what about the area code, or extensions?

The solution to dilemas such as these are that attribute type definitions include matching rules that tell the LDAP server how to make comparisons. Taking a look at RFC 2256 for the entry for telephoneNumber (also on page 17 of the book) we find:

 5.21. telephoneNumber
   ( 2.5.4.20 NAME 'telephoneNumber'
     EQUALITY telephoneNumberMatch?
     SUBSTR telephoneNumberSubstringsMatch?
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )

We can see that the attribute has two associated matching rules (specified by EQUALITY and SUBSTR). The telephoneNumberMatch rule is used for equality comparisons (this is both whitespace- and case-insenstive). Then, the telephoneNumberSubstringsMatch rule is used for partial telephone number matches.

Finally, the SYNTAX keyword specifies the object identifier (OID) of the encoding rules used for storing and transmitting values of the attribute type. The number enclosed by curly braces ({}) specifies the minimum recommended maximum length of the attribute's value that a server should support.

On Object Identifiers (OID)

An OID is a string of dotted numbers that uniquely identifies items such as attributes, syntaxes, object classes, etc (all of which we will see soon). OID assignments must be unique worldwide, so if you have a need to extend a given schema element, then you should not haphazardly create a new OID. Instead, you should go to http://www.iana.org/cgi-bin/enterprise.pl and request a private enterprise number. The form is short and normally takes one to two weeks to be processed. Once you have your own enterprise number, you can create your own OIDs without fear of them conflicting with existing OIDs. RFC 3383 describes some best practices for registering new LDAP values with IANA.

We will not be creating our own OIDs in this class, but there may be a time when you (or someone in your organization) may need to. So keep this in mind.

objectClass Attribute

All entries in an LDAP directory must have an objectClass attribute, and this attribute must have at least one value. Think of the objectClass attribute as a template for the data to be stored in an entry. It defined a set of attributes that must be present in the entry and a set of optional attributes that may or may not be present.

When setting up a given entry, you define not only the data type(s) but the context of that entry using the objectClass value. For example, a very common objectClass is (as we have seen in our previous examples) an organizationalUnit which defines a number of contact attributes for use in a personel directory.

objectClass definitions are defined by the various schema (next section) and it is important that we understand how to read the objectClass definitions from their associated schema files. So, let's take a quick look at the objectClass organizationalUnit definition from RFC 2256 (also on page 19 of the book):

 organizationalUnit
   ( 2.5.6.5 NAME 'organizationalUnit'
     SUP top STRUCTURAL
     MUST ou
     MAY ( userPassword $ searchGuide $ seeAlso $
     businessCategory $ x121Address $ registeredAddress $
     destinationIndicator $ preferredDeliveryMethod $
     telexNumber $ teletexTerminalIdentifier $
     telephoneNumber $ internationaliSDNNumber $
     facsimileTelephoneNumber $ street $ postOfficeBox $
     postalCode $ postalAddress $
     physicalDeliveryOfficeName $ st $ l $ description ) )

Let's analyze some of these lines:

  • Keyword MUST details those attributes that must be present in an entry of this objectClass
  • Keyword MAY details those optional attributes which may be used in an entry of this objectClass
  • It is possible for two object classes to have common attribute members because the attribute type namespace is flat for an entire schema. Thus, members such as telephoneNumber may be present in other object classes in a given schema.
  • Keyword SUP specifies the parent object from which this object was derived. A derived object possesses all the attribute type requirements of its parent. (So, for example, if we had an object that was derived from this one, it would have all the same requirements listed here, plus any others defined explicitly for that object).

SUP and Object Class Types

As we have seen, the object class organizationalUnit is derived from something known as the 'top STRUCTURAL' class. There are three object class type definitions which are used in LDAP directory services:
Structural object classes
Represent a real-world object, such a person or some other organizationalUnit. Each entry within an LDAP directory must have exactly one structural object class listed in the objectClass attribute. According to the LDAP data model, once an entry's structural object class has been instantiated, it cannot be changed without deleting and re-adding the entire entry.

Auxiliary object classes
Add certain characteristics to a structural class. These classes cannont be used on their own, but only to suppliment an existing structural object. There is a special auxiliary object class referred to in RFC 2252 named extensibleObject, which an LDAP server may support. This object class implicitly includes all attribues defined in the server's schema as optional members.

Abstract object classes
Act the same as their counterparts in object-oriented programming. These cannot be used directly, but only as ancestors of derived classes. The most common abstract class relating to LDAP (and to X.500) that you will use is the top abstract class, which is the parent or ancestor of all LDAP object classes.


Classnotes | LDAP01 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited September 22, 2003 1:58 am (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.