title: An alternative to custom objectclasses: the extensibleobject link: https://onemoretech.wordpress.com/2010/03/01/an-alternative-to-custom-objectclasses-the-extensibleobject/ author: lembobro description: post_id: 187 created: 2010/03/01 03:00:44 created_gmt: 2010/03/01 03:00:44 comment_status: open post_name: an-alternative-to-custom-objectclasses-the-extensibleobject status: publish post_type: post

An alternative to custom objectclasses: the extensibleobject

I’ve spent a decade designing and implementing LDAP directories, but only recently had the opportunity to reflect on the big picture. For example, the basic structure of the environment originally put in place at the company I work for by the consultants who started things is still there, but as time marched on things like access controls and custom object classes have become much more complex than the relatively simple setup I was handed at the beginning.

One missed opportunity was in failing to avoid the inevitable proliferation of custom objectclasses in our schema. Although I was merely following the lead of not only our consultants, but also the major part of the LDAP community, I now think that much of that effort was not entirely necessary.

Objectclasses are in reality only containers for attributes. While there is some utility in being able to group related attributes in distinct objectclasses (e.g., the fact that all people entries on a directory were created with the inetorgperson objectclass makes it easy to get a dump of them all by using the search filter “(objectclass=inetorgperson)”) , this practice can become unwieldy: particularly when the directory objects involved are user entries.

Most experienced directory administrators will almost instinctively create a user entry by first inserting the person, organizationalperson, and inetorgperson objectclasses. It’s just how things are done.

But I’ve begun to wonder about that next step, the creation and maintenance of custom objectclasses for attributes that aren’t included in the standard objectclasses but may be desired in user entries. For example, none of those standard person objectclasses permit you to add the attribute ‘c’ to entries for holding a two-character country code. To add ‘c’ you either have to extend one of those existing objectclasses or create a new custom objectclass and make sure it is part of every user entry you want to add ‘c’ to.

There is a middle way though. If an entry has the extensibleobject objectclass you can add any attribute you’d like to it. Section 7.1 of RFC 2252 states:

The extensibleObject object class, if present in an entry, permits that entry to optionally hold any attribute. The MAY attribute list of this class is implicitly the set of all attributes.

There’s no guarantee that extensibleobject will be supported by all LDAP servers, although it is by the major products used today.

As part of a project to put my personal address book in LDAP I recently added the evolutionperson objectclass and its constituent attributes, including the very useful birthDate and anniversary, to my home directory server. Rather than use this new objectclass or create a custom class, I’ve decided to simply add the extensibleobject objectclass to each of my entries so that I can add the attributes I need without running afoul of schema checking. It’s a practical solution to a practical problem that has the enormous benefit of keeping things as simple as possible. And that’s always a good thing.

Copyright 2004-2019 Phil Lembo