Structural Vs Auxillary Object class ??

What Are Objectclasses?
Objectclasses are prototypes for entries that will actually exist in directory server. The objectclass definition (uses ASN.1 syntax) specifies which attributes may or must be used by LDAP entries declared as instances of a particular objectclass.

When schema needs to be designed for custom implementation people do have confusion when to use structural and when to use auxillary object classes.

Thumb Rule: Every LDAP entry must use a STRUCTURAL objectclass. Furthermore, it can have only one STRUCTURAL objectclass. It can have any number of Auxillary object classes. If the auxillary object class is attached to the entry attributes attached to that auxillary object class (MAY/MUST) will also be attached.

For example in an organization there are multiple applications which needs specific attributes based on applications assigned to the user or not. All the applications can be represented using Auxillary object class. This way whatever application is attached to the user, attributes specific to that attributes will be assigned to the user.


I will give example on defining Structural Vs Auxillary object class but lets just read once the definition of each type of object class from SUN documentation

Abstract: defined only as a superclass or template for other (structural) object classes. An abstract object class is a way of collecting a set of attributes that will be common to a set of structural object classes, so that these classes may be derived as subclasses of the abstract class rather than being defined from scratch. An entry may not belong to an abstract object class.

--> Think of these as abstract class in java. They are just a helper classes so structural object classes can simply extend them for common attributes. For example top is a abstract object class.

Structural: indicates the attributes that the entry may have and where each entry may occur in the DIT. This object class represents the corresponding real world object. Entries must belong to a structural object class, so most object classes are structural object classes.


Auxiliary: indicates the attributes that the entry may have. An auxiliary object class does not represent a real world object, but represents additional attributes that can be associated with a structural object class to supplement its specification. Each entry may belong to only a single structural object class, but may belong to zero or more auxiliary object classes.


As promised here are example of how you can define object classes.

objectClasses: ( 1.3.6.1.4.1.20502.1.2.12 NAME 'ABCAPSMUser' SUP top AUXILIARY MAY absAPSMId X-ORIGIN 'user defined' )

objectClasses: ( 1.3.6.1.4.1.20502.1.2.8 NAME 'ABCuser' SUP inetorgperson STRUCTURAL MUST ABCuserstatus MAY ( gender $ absuserpassword $ inetUserStatus $ personalTitle $ mailAlternateAddress $ mailHost $ mailRoutingAddress ) X-ORIGIN 'user defined' )