HP-UX Directory Server 8.1 deployment guide

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