|Previous Contents Index DocHome Next|
|iPlanet Directory Server Schema Reference|
Chapter 1 About Schema
This chapter provides an overview of some of the basic concepts of the directory schema, and lists the files in which the schema is described. It describes object classes, attributes and Object Identifiers (OIDs), and briefly discusses extending server schema and schema checking.
The directory schema is a set of rules that defines how the data can be stored in the directory. The data is stored in the form of directory entries. Each entry is a set of attributes and their values. Each entry must have an object class. The object class specifies the kind of object the entry describes and defines the set of attributes it contains. The schema defines the type of entries allowed, their attribute structure and the syntax of the attributes. The schema can be modified and extended if it does not meet your required needs.
To find detailed information about object classes, attributes, and how the Directory Server uses the schema, please refer to the iPlanet Directory Server Deployment Guide.
In LDAP, an object class defines the set of attributes that can be used to define an entry. The LDAP standard provides some basic types of object classes, including:
Groups, including unordered lists of individual objects or groups of objects.Object classes may be subdivided into three types:
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.Note that the Directory Server currently does not distinguish between structural and auxiliary object classes.
Auxiliary: indicates the attributes that the entry may have. Does not represent a real world object, but represents additional attributes that can be associated with some structural object class to supplement its specification. Each entry, while belonging to only a single structural object class, may belong to zero or more auxiliary object classes.
Abstract: defined purely for the purpose of serving as a superclass or template for other (structural) object classes. It is a way of conveniently collecting together a set of attributes which it is known will be common to a set of structural object classes, in order that these classes may be derived as subclasses of the abstract class rather than being defined from scratch. Note that an entry may not belong to an abstract object class.
Required and Allowed Attributes
Every object class includes a number of required attributes and of allowed attributes. Required attributes include the attributes that must be present in entries using the object class. All entries require the objectClass attribute, which defines the object classes assigned to the entry.
Allowed attributes include the attributes that may be present in entries using the object class.
Example: Object Class = person
cn (common name)
Object Class Inheritance
Each entry should be assigned to one structural object class. All object classes inherit from top. They can also inherit from other object classes. The server's object class structure determines the list of required and allowed attributes for a particular entry. For example, a person entry is usually defined with the following object class structure:
In this structure, the inetOrgperson inherits from the organizationalPerson and person object classes. Therefore, when you assign the inetOrgperson object class to an entry, it automatically inherits the required and allowed attributes from the superior object class.
- objectClass: top
Note: Object class inheritence is dependant on the order in which the object classes appear in the .ldif file. The order in which object classes appear in the .ldif file must be consistent with the object class heirarchy, otherwise the server will not start. An object class which inherits from another object class must therefore appear after this object class in the .ldif file.
Directory data is represented as attribute-value pairs. Any piece of information in the directory is associated with a descriptive attribute.
For instance, the commonName, or cn, attribute is used to store a person's name. A person named Barbara (Babs) Jensen can be represented in the directory as
Each person entered in the directory can be defined by the collection of attributes in the inetorgperson object class. Other attributes used to define this entry could include:
- cn: Babs Jensen
- givenname: Barbara
Each attribute has a syntax definition that describes the type of information provided by the attribute.
Attribute syntax is used by the Directory Server to perform sorting and pattern matching.
Table 1-1 lists the different syntax methods that can be applied to attributes, and gives an OID and a definition for each syntax method.
Syntax and OID
where each dstring component is encoded as a value with DirectoryString syntax. Backslashes and dollar characters within dstring must be quoted, so that they will not be mistaken for line delimiters. Many servers limit the postal address to 6 lines of up to thirty characters. For example:
Single-Valued and Multi-Valued Attributes
By default, most attributes are multi-valued. This means that an entry can contain the same attribute with multiple values. For example, cn, tel and objectClass are all attributes that can have more than one value. Attributes that are single-valuedthat is, only one instance of the attribute can be specifiedare noted as such. For example, uidNumber can only have one possible value.
Schema Supported by Directory Server 5.1
The schema provided with iPlanet Directory Server 5.1 is described in a set of files stored in the following directory:
/var/ds5/slapd-serverID/config/schema on the Solaris 9 platformYou can modify the schema by creating new object classes and attributes. These modifications are stored in a separate file called 99user.ldif. You should not modify the standard files provided with the Directory Server, because you incur the risk of breaking compatibility with other iPlanet products, or of causing interoperability problems with directory servers from other vendors than iPlanet.
For more information about how the Directory Server stores information and suggestions for planning directory schema, refer to the iPlanet Directory Server Deployment Guide.
The following tables list the schema files that are provided with iPlanet Directory Server. Table 1-2 lists the schema files that are used by the Directory Server. Table 1-3 lists the schema files that are used by other iPlanet products.
Object Identifiers (OIDs)
Object identifiers (OIDs) are assigned to all attributes and object classes to conform to the LDAP and X.500 standards. An OID is a sequence of integers, typically written as a dot-separated string. When no OID is specified, the Directory Server automatically uses ObjectClass_name-oid and attribute_name-oid.
The Netscape base OID is 2.16.840.1.113730.
The base OID for the iPlanet Directory Server is 2.16.840.1.113730.3.
All iPlanet-defined attributes have the base OID of 2.16.840.1.113370.3.1.
All iPlanet-defined object classes have the base OID of 2.16.840.1.113730.3.2.
For more information about OIDs, or to request a prefix for your enterprise, please go to the IANA (Internet Assigned Number Authority) website at http://www.iana.org/.
Extending Server Schema
The Directory Server schema includes hundreds of object classes and attributes that can be used to meet most of your requirements. This schema can be extended with new object classes and attributes that meet evolving requirements for the directory service in the enterprise.
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 the Directory Server's compatibility with existing LDAP clients that rely on the standard LDAP schema and may cause difficulties when upgrading the server).
For more information about extending server schema, refer to the iPlanet Directory Server Deployment Guide.
You should run Directory Server with schema checking turned on.
The schema checking capability of iPlanet Directory Server checks entries when you add them to the directory or when you modify them, to verify that:
Object classes and attributes in the entry are defined in the directory schemaSchema checking also occurs when importing a database using LDIF. For more information, refer to the iPlanet Directory Server Administrator's Guide.
Previous Contents Index DocHome Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated October 29, 2001