Chapter 7. Schema definitions

In LDAP, an object class defines the set of attributes that can be used to define an entry. The LDAP standard provides object classes for many common types of entries, such as people (person and inetOrgPerson), groups (groupOfUniqueNames), locations (locality), organizations and divisions (organization and organizationalUnit), and equipment (device).

In a schema file, an object class is identified by the objectclasses line, then followed by its OID, name, a description, its direct superior object class (an object class which is required to be used in conjunction with the object class and which shares its attributes with this object class), and the list of required (MUST) and allowed (MAY) attributes. This is shown in the following example:

objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' )

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

Directory entries are composed of attributes and their values. These pairs are called attribute-value assertions or AVAs. Any piece of information in the directory is associated with a descriptive attribute. For instance, the cn attribute is used to store a person’s full name, such as cn: John Smith.

Additional attributes can supply additional information about John Smith:

givenname: John
surname: Smith
mail: jsmith@example.com

In a schema file, an attribute is identified by the attributetypes line, then followed by its OID, name, a description, syntax (allowed format for its value), optionally whether the attribute is single- or multi-valued, and where the attribute is defined.

This is shown in the following example:

attributetypes: ( 2.5.4.13 NAME 'description' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' )

Some attributes can be abbreviated. These abbreviations are listed as part of the attribute definition:

attributetypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) ...

dn: uid=jsmith,ou=marketing,ou=people,dc=example,dc=com
ou: marketing
ou: people

Template schema definitions for Directory Server are stored in the /etc/dirsrv/schema directory. These default schema files are used to generate the schema files for new Directory Server instances. Each server instance has its own instance-specific schema directory in /etc/dirsrv/slapd-instance/schema. The schema files in the instance directory are used only by that instance.

To modify the directory schema, create new attributes and new object classes in the instance-specific schema directory. Because the default schema is used for creating new instances and each individual instance has its own schema files, it is possible to have slightly different schema for each instance, matching the use of each instance.

Any custom attributes added using LDAP commands are stored in the 99user.ldif file; other custom schema files can be added to the /etc/dirsrv/slapd-instance/schema directory for each instance. Do not make any modifications with the standard files that come with {PRODUCT}.

All schema elements have object identifiers (OIDs) assigned to them, including attributes and object classes. An OID is a sequence of integers, usually written as a dot-separated string. All custom attributes and classes must conform to the X.500 and LDAP standards.

OIDs can be built on. The base OID is a root number which is used for every schema element for an organization, and then schema elements can be incremented from there. For example, a base OID could be 1. The company then uses 1.1 for attributes, so every new attribute has an OID of 1.1.x. It uses 1.2 for object classes, so every new object class has an OID of 1.2.x.

For Directory Server-defined schema elements, the base OIDs are as follows:

For more information about OIDs or to request a prefix, go to the Internet Assigned Number Authority (IANA) website at http://www.iana.org/.

The Directory Server schema includes hundreds of object classes and attributes that can be used to meet most of directory requirements. This schema can be extended with new object classes and attributes that meet evolving requirements for the directory service in the enterprise by creating custom schema files.

When adding new attributes to the schema, a new object class should be created to contain them. Adding a new attribute to an existing object class can compromise Directory Server’s compatibility with existing LDAP clients that rely on the standard LDAP schema and may cause difficulties when upgrading the server.

Schema checking means that Directory Server checks every entry when it is created, modified, or in a database imported using LDIF to make sure that it complies with the schema definitions in the schema files. Schema checking verifies three things:

You should run Directory Server with schema checking turned on.

Syntax validation means that Directory Server checks that the value of an attribute matches the required syntax for that attribute. For example, syntax validation will confirm that a new telephoneNumber attribute actually has a valid telephone number for its value.

With its basic configuration, syntax validation (like schema checking) will check any directory modification to make sure the attribute value matches the required syntax and will reject any modifications that violate the syntax. Optionally, syntax validation can be configured to log warning messages about syntax violations, and either reject the change or allow the modification process to succeed.

All syntaxes are validated against RFC 4514, except for DNs. By default, DNs are validated against RFC 1779 or RFC 2253, which are less strict than RFC 4514. Strict validation for DNs has to be explicitly configured.

This feature checks all attribute syntaxes, with the exception of binary syntaxes (which cannot be verified) and non-standard syntaxes, which do not have a defined required format. The unvalidated syntaxes are as follows:

When syntax validation is enabled, new attribute values are checked whenever an attribute is added or modified to an entry. (This does not include replication changes, since the syntax would have been checked on the supplier server.)