Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide

About Custom Schema

You can extend the standard schema if it is too limited for your directory needs. Follow these guidelines when customizing schema:

When customizing the schema, do not modify, delete, or replace any existing definitions of attributes or object classes in the standard schema. Doing so can lead to compatibility problems with other directories and with LDAP client applications.

Do not modify any Directory Server internal operational attributes. You can, however, create your own operational variables for external applications.

Always define object classes instead of using objectClass: extensibleObject. Directory Server does not perform schema checking for entries that have the object class extensibleObject, so it does not constrain or check what attributes are present on the entry. Typos in applications, for example, giveName for the givenName attribute type, go unnoticed by Directory Server. Also, Directory Server must assume that all otherwise undefined attributes of extensibleObject entries are multivalued and have case-insensitive string syntax. Furthermore, some applications rely on entries having a particular object class. In general, if you have an application that requires an extension to an object class, do not relinquish schema management. Instead, create an auxiliary object class that contains the attributes that are required for the application.

This section contains information about the default directory schema, and about creating customized attributes and object classes.

Default Directory Server Schema

The schema provided with Directory Server is described in a set of files that are stored in the instance-path/config/schema/directory.

This directory contains all of the common schema for Directory Server and related products. The LDAP v3 standard user and organization schema is located in the 00core.ldif file. The configuration schema used by earlier versions of the directory is located in the 50ns-directory.ldif file.

Note –

Do not modify files in this directory while the server is running.

Object Identifiers

Each LDAP object class or attribute must be assigned a unique name and object identifier (OID). When you define a schema, you need an OID that is unique to your organization. One OID is enough to meet all of your schema needs. You then add new branches on that OID for your attributes and object classes.

Obtaining and assigning OIDs in your schema involves doing the following:

Naming Attributes and Object Classes

When creating names for new attributes and object classes, make the name meaningful so your schema is easier to use.

Avoid naming collisions between custom schema elements and existing schema elements by including a unique prefix on custom elements. For example, Corporation might add the prefix Example before each of its custom schema elements. It might also add a special object class called ExamplePerson to identify employees in its directory.

Note that in LDAP, attribute type names and object class names are case insensitive. Applications should treat them as case insensitive strings.

When Defining New Object Classes

Add new object classes when the existing object classes do not support all of the information you need to store in a directory entry.

There are two approaches to creating new object classes:

Consider the following when deciding how to implement new object classes.

When Defining New Attributes

Add new attributes when the existing attributes do not support all of the information you need to store in a directory entry. Try to use standard attributes whenever possible. Search the attributes that already exist in the default directory schema and use those attributes in association with a new object class.

For example, you might find that you want to store more information on a person entry than the person, organizationalPerson, or inetOrgPerson object classes support. If you want to store birth dates in your directory, no attribute exists within the standard Directory Server schema. You can create a new attribute called dateOfBirth. Allow this attribute to be used on entries that represent people by defining a new auxiliary class that allows this attribute.

When Creating Custom Schema Files

Keep the following in mind when creating custom schema files, especially when you are using replication: