For example, suppose an administrator wants to create the attributes exampleDateOfBirth, examplePreferredOS, exampleBuildingFloor, and exampleVicePresident. A simple solution is to create several object classes that allow some subset of these attributes.

•One object class, examplePerson, is created and allows exampleDateOfBirth and examplePreferredOS. The parent of examplePerson is inetOrgPerson.

•A second object class, exampleOrganization, allows exampleBuildingFloor and exampleVicePresident. The parent of exampleOrganization is the organization object class.

The new object classes appear in LDAPv3 schema format as follows:

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'

SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'

SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

Alternatively, create a single object class that allows all these attributes and use it with any entry which needs these attributes. The single object class appears as follows:

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top

AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ example\ BuildingFloor $ exampleVicePresident) )

The new exampleEntry object class is marked AUXILIARY, meaning that it can be used with any entry regardless of its structural object class.

NOTE:

The OID of the new object classes in the example (2.16.840.1.117370) is based on the former Netscape OID prefix. To create custom object classes, obtain an OID as described in “Getting and assigning object identifiers”.

There are several different ways to organize new object classes, depending on the organization environment. Consider the following when deciding how to implement new object classes:

•Multiple object classes result in more schema elements to create and maintain.

Generally, the number of elements remains small and needs little maintenance. However, it may be easier to use a single object class if there are more than two or three object classes added to the schema.

•Multiple object classes require a more careful and rigid data design.

Rigid data design forces attention to the object class structure under which every piece of data is placed, which can be either helpful or cumbersome.

•Single object classes simplify data design when there is data that can be applied to more than one type of object class, such as both people and asset entries.

For example, a custom preferredOS attribute may be set on both a person and a group entry. A single object class can allow this attribute on both types of entries.

•Avoid required attributes for new object classes.

Specifying require instead of allow for attributes in new object classes can make the schema inflexible. When creating a new object class, use allow rather than require as much as possible.

After defining a new object class, decide what attributes it allows and requires, and from what object classes it inherits attributes.

3.4 Customizing the schema

33