The Sins Of The Fathers... - Administration

One of the nice things about object-oriented programming is inheritance - which means, simply, that you can take a pre-existing object and use it to spawn a child object which inherits all the properties of the parent, while simultaneously including any custom properties you may decide to give it. And your newly-created object can, in turn, serve as the base for yet another object, and so on ad infinitum...

In the LDAP world, all this means is that object definitions can be inherited, thereby freeing schema designers to concentrate on other, more important things. In the example above, for instance, you'll see that the definition for the "inetOrgPerson" class does not include attributes for "cn" and "sn" - even though my original LDAP entry includes these attributes.

Why, you ask? Because the "inetOrgPerson" class also inherits some attributes from the "organizationalPerson" class

objectclass ( 2.5.6.7 NAME 'organizationalPerson'
DESC 'RFC2256: an organizational person'
SUP person STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $ destinationIndicator
$
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $
telephoneNumber $  internationaliSDNNumber $
facsimileTelephoneNumber $
street $  postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l ) )

which, in turn, inherits some attributes (including the lost-but-now-found "cn" and "sn" attributes) from the "person" class.

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

In case you're wondering, all these definitions are LDAP standards and come bundled with most LDAP servers; however, if you have the time (and necessary knowledge), LDAP also allows you to design your own schema definitions and include them in your object collection.

You can also apply more than one object definition to a single entry - consider the following hybrid:

dn: dc=melonfire, dc=com
objectclass: dcObject
objectclass: organization
dc: melonfire
o: Melonfire

In this case, I've said that the entry is an instance of the "dcObject" and "organization" classes. Since I've used more than one object class, the final LDAP entry must be compliant with the rules specified in each of the referenced class definitions.

Now, while I'd love to go on and on about the theory behind LDAP, this is, sadly, all we have time for at the moment (it's also all you really need to know about LDAP, unless you're a geek with a penchant who likes calculating pi to the nineteenth digit). In the second part of this article, I'll be putting all this theory to the test, using it to build a real, live LDAP-based address book for a small office. Make sure you come back for that!

Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!

>>> More Site Administration Articles          >>> More By Vikram Vaswani, (c) Melonfire

blog comments powered by Disqus