AddThis Social Bookmark Button

Listen Print Discuss

Demystifying LDAP Data
Pages: 1, 2

Inheritance Overload!

Here's the rule: every LDAP entry must use a STRUCTURAL objectclass. Furthermore, it can have only one STRUCTURAL objectclass. While it's true that every objectclass in the example entry is STRUCTURAL, only one has top as its parent. All of the others are descendants of that objectclass. I've played by the rules here, and LDAP servers will not spit this back at you.



There are applications that can cause you headaches, however. Some application developers include a schema that you can use with your LDAP server to add attributes to an entry for use by that application. Evolution and Mozilla used to (and may still) distribute schemas that defined evolutionPerson and zillaPerson, respectively, as STRUCTURAL objectclasses. This alone is not a problem. The real problem comes when you want to use both of these schemas--you can't, because both of the objectclasses, in addition to being STRUCTURAL, also have inetOrgPerson as their parent objectclass. This creates a fork in the inheritance chain, and is unacceptable to strict LDAP directories:

person
  \
   organizationalPerson
   \ 
    inetOrgPerson
   /             \ 
evolutionPerson   zillaPerson

In short, you can't define an entry which uses two STRUCTURAL objectclasses that share a parent. These schemas should really declare the objectclasses as AUXILIARY, which would fix this issue. As long as you have an object defined using one STRUCTURAL objectclass, you can use any number of AUXILIARY objectclasses to add more attributes to your entries. Also note that you can use either one of these schemas with your existing entries. It's only when you try to employ both that you create a fork in the chain.

Where's the Beef?

With all of that definition in mind, now it's possible to consider the really important information: the attributes. The interesting ones describe, in human terms, who this person is and how to reach him. Most of these attributes, such as roomNumber and givenName, come from the MAY section of the inetOrgPerson objectclass. Where did cn and sn come from?

The answer is from the person objectclass. Just like inetOrgPerson, the person definition has a MAY block, but it also has a MUST block which contains the attributes cn and sn. This means that any entry defined using this objectclass must have values set for these attributes. Here's the person objectclass definition:

objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

My earlier example also chose to use the telephoneNumber attribute, which is perfectly legal.

How do you know what cn and sn are?

In every case I've ever seen, the definitions of the attributes named in an objectclass definition are in the very same file as the objectclass itself. They're very readable as well. Here's the definition of sn:

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
        DESC 'RFC2256: last (family) name(s) for which the entity is known
by'
        SUP name )

sn is an alias for surname. I could've written the attribute as surname, if I liked. The description indicates that the purpose of this attribute is to indicate the user's last name.

There is another major point worth noting about this particular attribute definition. As you might've guessed, it has to do with the SUP line. In this case, the superior to this attribute type is name:

attributetype ( 2.5.4.41 NAME 'name'
       EQUALITY caseIgnoreMatch
       SUBSTR caseIgnoreSubstringsMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

See those EQUALITY, SUBSTR, and SYNTAX lines? EQUALITY and SUBSTR define the method the LDAP server will use to figure out if an incoming value is an exact match, or a substring match (respectively) for the value of this attribute in an entry. The SYNTAX line points to a syntax definition used to check that new values added by an administrator, or old values updated by an administrator, conform to the syntax definition pointed to by the very long ASN.1 number. The long number is just a reference point for looking up the definition, as are the strings next to the EQUALITY and SUBSTR keywords. RFC 4517 defines their meanings. As well, the handy Schema Browser tool can look up almost anything you see in any standard schema.

I told you all of that so I could tell you this: you won't see any of those lines in the sn attribute because it inherits all of that information from its SUP attribute, which is name. Because name doesn't inherit anything from anywhere, all of that information must be present in its definition.

Before You Fall Asleep

That's a good bit to chew on. Hopefully, you've come away with the ability to peruse the schema files, which will give you a greater understanding of how your directory works, and why. It also explains a good number of errors you'll get from you server, including any form of objectclass violation error.

I must caution you strongly against using this information to implement shiny new custom objectclasses and attributes. Many people have worked very hard to create standardized, published schemas for general use. It would benefit you, your firm, and anyone who may come after you to consult the Schema Browser tool, a few schema files, and maybe one or two RFCs to figure out if what you need actually exists in a published schema before taking off and blazing your own ASN.1-littered trail.

Brian K. Jones is an infrastructure architect, and system/network/database administrator, and co-author of Linux Server Hacks, Volume Two .

Return to O'Reilly SysAdmin