Previous     Contents     Index     DocHome     Next     
iPlanet Directory Server 5.1 Deployment Guide



Chapter 3   How to Design the Schema


The site survey you conducted in Chapter 2 generated information abut the data you plan to store in your directory. Next, you must decide how to represent the data you store. Your directory schema describes the types of data you can store in your directory. During schema design, you map each data element to an LDAP attribute, and gather related elements into LDAP object classes. Well-designed schema helps maintain the integrity of the data you store in your directory.

This chapter describes the directory schema and how to design schema for your unique needs. This chapter contains the following sections:

For information on replicating schema, refer to "Schema Replication".



Schema Design Process Overview


During schema design, you select and define the object classes and attributes used to represent the entries stored by Directory Server. Schema design involves the following steps:

  • Choosing predefined schema elements to meet as many of your needs as possible.

  • Extending the standard Directory Server schema to define new elements to meet your remaining needs.

  • Planning for schema maintenance.

It is best to use existing schema elements defined in the standard schema provided with Directory Server. Choosing standard schema elements helps ensure compatibility with directory-enabled applications. In addition, as the schema is based on the LDAP standard, you are assured it has been reviewed and agreed to by a wide number of directory users.



iPlanet Standard Schema


Your directory schema maintains the integrity of the data stored in your directory by imposing constraints on the size, range, and format of data values. You decide what types of entries your directory contains (people, devices, organizations, and so forth) and the attributes available to each entry.

The predefined schema included with Directory Server contains both the standard LDAP schema as well as additional application-specific schema to support the features of the server. While this schema meets most directory needs, you may need to extend it with new object classes and attributes to accommodate the unique needs of your directory. Refer to "Customizing the Schema" for information on extending the schema.

The following sections describe the format, standard attributes, and object classes included in the iPlanet standard schema.


Schema Format

Directory Server bases its schema format on version 3 of the LDAP protocol (LDAPv3). This protocol requires directory servers to publish their schemas through LDAP itself, allowing directory client applications to programmatically retrieve the schema and adapt their behavior based on it. The global set of schema for Directory Server can be found in the entry named cn=schema.

The Directory Server schema differs slightly from the LDAPv3 schema, as it uses its own proprietary object classes and attributes. In addition, it uses a private field in the schema entries called X-ORIGIN, which describes where the schema entry was defined originally. For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers to RFC 2252. If the entry is defined by iPlanet for the Directory Server's use, the X-ORIGIN field contains the value iPlanet Directory Server.

For example, the standard person object class appears in the schema as follows:

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object  Class' SUP top MUST (objectlass $ sn $ cn) MAY (description $  seealso $ telephoneNumber $ userPassword) X-ORIGIN 'RFC 2252' )

This schema entry states the object identifier, or OID, for the class (2.5.6.6), the name of the object class (person), a description of the class (Standard Person Object Class), then lists the required attributes (objectclass, sn, and cn) and the allowed attributes (description, seealso, telephoneNumber, and userPassword).


Standard Attributes

Attributes hold specific data elements such as a name or a fax number. Directory Server represents data as attribute-data pairs, a descriptive attribute associated with a specific piece of information. For example, the directory can store a piece of data such as a person's name in a pair with the standard attribute, in this case commonName (cn). So, an entry for a person named Babs Jensen has the following attribute-data pair:

cn: Babs Jensen

In fact, the entire entry is represented as a series of attribute-data pairs. The entire entry for Babs Jensen might appear as follows:

dn: uid=bjensen, ou=people, dc=siroe,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@siroe.com

Notice that the entry for Babs contains multiple values for some of the attributes. The attribute givenName appears twice, each time with a unique value. The object classes that appear in this example are explained in the next section, "Standard Object Classes."

In the schema, each attribute definition contains the following information:

  • A unique name

  • An object identifier (OID) for the attribute

  • A text description of the attribute

  • The OID of the attribute syntax

  • Indications of whether the attribute is single-valued or multi-valued, whether the attribute is for the directory's own use, the origin of the attribute, and any additional matching rules associated with the attribute.

For example, the cn attribute definition appears in the schema as follows:

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard  Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

The SYNTAX is the OID of the syntax for values of the attribute. The allowed syntaxes for attributes have been renamed and expanded since versions 4.x of the Directory Server. The following table describes the new name OIDs of all syntaxes:



Syntax and OID

Definition

Binary (formerly bin)
1.3.6.1.4.1.1466.115.121.1.5  

Indicates that values for this attribute are binary.  

Boolean
1.3.6.1.4.1.1466.115.121.1.7  

Indicates that this attribute has one of only two values: True or False.  

Country String
1.3.6.1.4.1.1466.115.121.1.11  

Indicates that values for this attribute are limited to exactly two printable string characters, for example fr.  

DN (formerly dn)
1.3.6.1.4.1.1466.115.121.1.12  

Indicates that values for this attribute are DNs (distinguished names).  

DirectoryString
(formerly cis)
1.3.6.1.4.1.1466.115.121.1.15  

Indicates that values for this attribute are not case sensitive.  

GeneralizedTime
1.3.6.1.4.1.1466.115.121.1.24  

Indicates that values for this attribute are encoded as printable strings. The time zone must be specified. It is strongly recommended to use GMT.  

IA5String (formerly ces)
1.3.6.1.4.1.1466.115.121.1.26  

Indicates that values for this attribute are case sensitive.  

INTEGER (formerly int)
1.3.6.1.4.1.1466.115.121.1.27  

Indicates that valid values for this attribute are numbers.  

OctetString
1.3.6.1.4.1.1466.115.121.1.40  

Same behavior as binary.  

Postal Address
1.3.6.1.4.1.1466.115.121.1.41  

Indicates that values for this attribute are encoded as

dstring[$ dstring]*

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:

1234 Main St.$Anytown, TX 12345$USA  

TelephoneNumber (formerly tel)
1.3.6.1.4.1.1466.115.121.1.50  

Indicates that values for this attribute are in the form of telephone numbers. It is recommended to use telephone numbers in international form.  

URI
1.3.6.1.4.1.250.1.57  

Indicates that the values for this attribute are in the form of a URL, introduced by a string such as http://, https://, ftp, LDAP. The URI has the same behavior as IA5String. See RFC 2396.  

"> Table 3-1    Attribute Syntax Definitions



Syntax and OID

Definition

Binary (formerly bin)
1.3.6.1.4.1.1466.115.121.1.5  

Indicates that values for this attribute are binary.  

Boolean
1.3.6.1.4.1.1466.115.121.1.7  

Indicates that this attribute has one of only two values: True or False.  

Country String
1.3.6.1.4.1.1466.115.121.1.11  

Indicates that values for this attribute are limited to exactly two printable string characters, for example fr.  

DN (formerly dn)
1.3.6.1.4.1.1466.115.121.1.12  

Indicates that values for this attribute are DNs (distinguished names).  

DirectoryString
(formerly cis)
1.3.6.1.4.1.1466.115.121.1.15  

Indicates that values for this attribute are not case sensitive.  

GeneralizedTime
1.3.6.1.4.1.1466.115.121.1.24  

Indicates that values for this attribute are encoded as printable strings. The time zone must be specified. It is strongly recommended to use GMT.  

IA5String (formerly ces)
1.3.6.1.4.1.1466.115.121.1.26  

Indicates that values for this attribute are case sensitive.  

INTEGER (formerly int)
1.3.6.1.4.1.1466.115.121.1.27  

Indicates that valid values for this attribute are numbers.  

OctetString
1.3.6.1.4.1.1466.115.121.1.40  

Same behavior as binary.  

Postal Address
1.3.6.1.4.1.1466.115.121.1.41  

Indicates that values for this attribute are encoded as

dstring[$ dstring]*

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:

1234 Main St.$Anytown, TX 12345$USA  

TelephoneNumber (formerly tel)
1.3.6.1.4.1.1466.115.121.1.50  

Indicates that values for this attribute are in the form of telephone numbers. It is recommended to use telephone numbers in international form.  

URI
1.3.6.1.4.1.250.1.57  

Indicates that the values for this attribute are in the form of a URL, introduced by a string such as http://, https://, ftp, LDAP. The URI has the same behavior as IA5String. See RFC 2396.  

For more information about the LDAPv3 schema format, refer to the LDAPv3 Attribute Syntax Definitions document (RFC 2252).


Standard Object Classes

Object classes are used to group related information. Typically, an object class represents a real object, such as a person or a fax machine. Before you can use an object class and its attributes in your directory, it must be identified in the schema. Your directory recognizes a standard list of object classes by default. See the iPlanet Schema Reference for more information.

Each directory entry belongs to one or more object classes. Once you place an object class identified in your schema on an entry, you are telling the directory server that the entry can have a certain set of attribute values and must have another, usually smaller, set of attribute values.

Object class definitions contain the following information:

  • A unique name

  • An object identifier (OID) that names the object

  • A set of mandatory attributes

  • A set of allowed attributes

For an example of a standard object class as it appears in the schema, refer to "Schema Format".

As is the case for all of the iPlanet Directory Server's schema, object classes are defined and stored directly in Directory Server. This means that you can both query and change your directory's schema with standard LDAP operations.



Mapping Your Data to the Default Schema


The data you identified during your site survey, as described in "Performing a Site Survey", must be mapped to the existing directory default schema. This section describes how to view the existing default schema and provides a method for mapping your data to the appropriate existing schema elements.

If you find elements in your schema that do not match the existing default schema, you may need to create custom object classes and attributes. Refer to "Customizing the Schema" for more information.therefore


Viewing the Default Directory Schema

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

This directory contains all of the common schema for the iPlanet products. The LDAPv3 standard user and organization schema can be found in the 00core.ldif file. The configuration schema used by earlier versions of the directory can be found in the 50ns-directory.ldif file.

For more information about each object class and attribute found in directory, refer to the iPlanet Schema Reference. For more information about the schema files and directory configuration attributes, refer to iPlanet Directory Server Command and File Reference.


Matching Data to Schema Elements

The data you identified in your site survey now needs to be mapped to the existing directory schema. This process involves the following steps:

  • Identify the type of object the data describes.

    Select an object that best matches the data described in your site survey. Sometimes, a piece of data can describe multiple objects. You need to determine if the difference needs to be noted in your directory schema. For example, a telephone number can describe an employee's telephone number and a conference room's telephone number. It is up to you to determine if these different sorts of data need to be considered as different objects in your directory schema.

  • Select a similar object class from the default schema.

    It is best to use the common object classes, such as groups, people, and organizations.

  • Select a similar attribute from the matching object class.

    Select an attribute from within the matching object class that best matches the piece of data you identified in your site survey.

  • Identify the unmatched data from your site survey.

    If there are some pieces of data that do not match the object classes and attributes defined by the default directory schema, you will need to customize the schema. See "Customizing the Schema" for more information.

For example, the following table maps directory schema elements to the data identified during the site survey in Chapter 2:


Table 3-2    Data Mapped to Default Directory Schema

Data

Owner

Object Class

Attribute

Employee name  

HR  

person  

cn(commonName)  

User password  

IS  

person  

userPassword  

Home phone number  

HR  

inetOrgPerson  

homePhone  

Employee location  

IS  

inetOrgPerson  

localityName  

Office phone number  

Facilities  

person  

telephoneNumber  

In the table, the employee name describes a person. In the default directory schema, we found the person object class, which inherits from the top object class. This object class allows several attributes, one of which is the cn or commonName attribute, which describes the full name of the person. This attribute makes the best match for containing the employee name data.

The user password also describes an aspect of the person object. In the list of allowed attributes for the person object, we find userPassword.

The home phone number describes an aspect of a person, however we do not find an appropriate attribute in the list associated with the person object class. Analyzing the home phone number more specifically, we can say it describes an aspect of a person in an organization's enterprise network. This object corresponds to the inetOrgPerson object class in the directory schema. The inetOrgPerson object class inherits from the organizationPerson object class, which in turn inherits from the person object class. Among the inetOrgPerson object's allowed attributes, we locate the homePhone attribute, which is appropriate for containing the employee's home telephone number.



Customizing the Schema


You can extend the standard schema if it proves to be too limited for your directory needs. The Directory Server Console can help you manage the schema definition. For more information, see the iPlanet Directory Server Administrator's Guide.

Keep the following rules in mind when customizing your schema:

  • Reuse existing schema elements whenever possible.

  • Minimize the number of mandatory attributes you define for each object class.

  • Do not define more than one object class or attribute for the same purpose.

  • Keep the schema as simple as possible.


    Note 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 or other LDAP client applications.


Your custom object classes and attributes are defined in the following file:

/var/ds5/slapd-serverID/config/schema/99user.ldif

The following sections describe customizing the directory schema in more detail:


When to Extend Your Schema

While the object classes and attributes supplied with the Directory Server should meet most of your needs, you may find that a given object class does not allow you to store specialized information about your organization. Also, you may need to extend your schema to support the object classes and attributes required by an LDAP-enabled application's unique data needs.


Getting and Assigning 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 unique to your organization. One OID is enough to meet all of your schema needs. You simply add another level of hierarchy to create new branches for your attributes and object classes. Getting and assigning OIDs in your schema involves the following steps:

  • Obtain an OID for your organization from the Internet Assigned Numbers Authority (IANA) or a national organization.

    In some countries, corporations already have OIDs assigned to them. If your organization does not already have an OID, one can be obtained from IANA. For more information, go to the IANA website at http://www.iana.org/cgi-bin/enterprise.pl.

  • Create an OID registry so you can track OID assignments.

    An OID registry is a list you maintain that gives the OIDs and descriptions of the OIDs used in your directory schema. This ensures that no OID is ever used for more than one purpose. You should then publish your OID registry with your schema.

  • Create branches in the OID tree to accommodate schema elements.

    Create at least two branches under the OID branch or your directory schema, using OID.1 for attributes and OID.2 for object classes. If you want to define your own matching rules or controls, you can add new branches as needed (OID.3, for example).


Naming Attributes and Object Classes

When creating names for new attributes and object classes, make the name as meaningful as possible. This makes your schema easier to use for Directory Server administrators.

Avoid naming collisions between your schema elements and existing schema elements by including a unique prefix on all of your elements. For example, siroe.com Corporation might add the prefix siroe before each of their custom schema elements. They might add a special object class called siroePerson to identify siroe.com employees in their directory.


Strategies for Defining New Object Classes

There are two ways you can create new object classes:

  • You can create many new object classes, one for each object class structure to which you want to add an attribute.

  • You can create a single object class that supports all of the attributes that you create for your directory. You create this kind of an object class by defining it to be an AUXILIARY kind of object class.

You may find it easiest to mix the two methods.

For example, suppose your site wants to create the attributes siroeDateOfBirth, siroePreferredOS, siroeBuildingFloor, and siroeVicePresident. You can create several object classes that allow some subset of these attributes. You might create an object class called siroePerson and have it allow siroeDateOfBirth and siroePreferredOS. The parent of siroePerson would be inetOrgPerson. You might then create an object class called siroeOrganization and have it allow siroeBuildingFloor and siroeVicePresident. The parent of siroeOrganization would be the organization object class.

Your new object classes would appear in LDAPv3 schema format as follows:

objectclasses: ( 2.16.840.1.17370.999.1.2.3 NAME 'siroePerson'  DESC 'Siroe Person Object Class' SUP inetorgPerson MAY (siroeDateOfBirth  $ siroePreferredOS) )

objectclasses: ( 2.16.840.1.17370.999.1.2.4 NAME  'siroeOrganization' DESC 'Organization Object Class' SUP  organization MAY (siroeBuildingFloor $ siroeVicePresident) )

Alternatively, you can create a single object class that allows all of these attributes and use it with any entry on which you want to use these attributes. The single object class would appear as follows:

objectclasses: (2.16.840.1.17370.999.1.2.5 NAME 'siroeEntry' DESC  'Standard Entry Object Class' SUP top AUXILIARY MAY
 (siroeDateOfBirth $ siroePreferredOS $ siroeBuildingFloor $
 siroeVicePresident) )

The new siroeEntry 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 is based on the iPlanet OID prefix. To create your own new object classes, you must get your own OID. For more information, refer to "Getting and Assigning Object Identifiers".


Choose the strategy for defining new object classes that works for you. 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, you may find it easier to use a single object class if you plan to add more than two or three object classes to your schema.

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

    Rigid data design forces you to consider the object class structure on which every piece of data will be placed. Depending on your personal preferences, you will find this to be either helpful or cumbersome.

  • Single object classes simplify data design when you have data that you want to put on more than one type of object class structure.

    For example, suppose you want preferredOS on both a person and a group entry. You may want to create only a single object class to allow this attribute.

  • Avoid required attributes for new object classes.

    Requiring attributes can make your schema inflexible. When you create a new object class, allow rather than require attributes.

After defining a new object class, you need to decide what attributes it allows and requires and from what object class(es) it inherits.


Strategies for Defining New Attributes

Add new attributes and new object classes when the existing object classes 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 them in association with a new object class. Create a new attribute if you cannot find a match in the default directory schema.

For example, you may 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 the birth dates in your directory, no attribute exists within the standard iPlanet Directory Server schema. You can choose to create a new attribute called dateOfBirth and allow this attribute to be used on entries representing people by defining a new auxiliary class, siroePerson, which allows this attribute.


Deleting Schema Elements

Do not delete the schema elements shipped with Directory Server. Unused schema elements represent no operational or administrative overhead. However, by deleting parts of the standard LDAP schema you may run into compatibility problems with future installations of Directory Server and other directory-enabled applications.

However, if you extend the schema and find you do not use the new elements, feel free to delete the elements you don't use. Before removing the object class definitions from the schema, you need to modify each entry using the object class. Otherwise, if you remove the definition first, you might not be able to modify the entries that use the object class afterwards. Schema checks on modified entries will also fail unless you remove the unknown object class values from the entry.


Creating Custom Schema Files

You can create custom schema files other than the 99user.ldif file provided with Directory Server. However, your custom schema files should not be numerically or alphabetically higher than 99user.ldif or the server could experience problems.

The 99user.ldif file contains attributes with the X-ORIGIN 'user defined'. If you create a schema file called 99zzz.ldif, the next time you update the schema using LDAP or the Directory Server Console, all of the attributes with an X-ORIGIN value of 'user defined'will be written to 99zzz.ldif. The directory writes them to 99zzz.ldif because the directory uses the highest sequenced file (numerically, then alphabetically) for its internal schema management. The result is two LDIF files that contain duplicate information, and some information in the 99zzz.ldif file might be erased.

When naming custom schema files, name them as follows:

[00-99]yourname.ldif

The directory loads these schema files in alpha-numerical order, and thus numbers are loaded first. For this reason, you should use a number scheme that is higher than any directory standard schema defined. For example, siroe.com Corporation creates a new schema file named 60siroecorp.ldif. If you name your schema file something lower than the standard schema files, the server may encounter errors when loading the schema. In addition, all standard attributes and object classes will be loaded only after your custom schema elements have been loaded.

You should not use 'user defined' in the X-ORIGIN field of your custom schema files as 'user defined' is used internally by the directory when schema is added over LDAP. Use something more descriptive, such as 'siroe.com Corporation defined'.

After you have created custom schema files, you can either:

  • Manually copy these custom schema files to all of your servers, which requires a restart of each server.

  • Allow the replication process to replicate this information to each of the consumers for you.

If you do not copy these custom schema files to all of your servers, the schema information will only be replicated to the consumer when changes are made to the schema on the supplier using LDAP or the Directory Server Console.

When the schema definitions are then replicated to a consumer server where they do not already exist, they will be stored in the 99user.ldif file. The directory does not track where schema definitions are stored. Storing schema elements in the 99user.ldif file of consumers does not create a problem as long as you maintain your schema on the master server only.

If you copy your custom schema files to each server, when changes are made to the schema files, they must be copied again to each server. If you do not copy them again, it is possible the changes will be replicated and stored in the 99user.ldif file on the consumer. Having the changes in the 99user.ldif file may make schema management difficult, as some attributes will appear in two separate schema files on a consumer, once in the original custom schema file you copied from the supplier and again in the 99user.ldif file after replication.

For more information about replicating schema, see "Schema Replication".


Custom Schema Best Practices

Consider the following points when creating custom schema elements:

  • If you manage your schema using LDAP or the Directory Server Console, add all of your schema definitions to the 99user.ldif file to avoid possible duplication of schema elements in multiple files. Schema elements added and updated via LDAP are automatically written to the 99user.ldif file.


    Note If you define custom schema files, for example 60siroecorp.ldif, and then update these schema elements using LDAP, the new definitions will be written to the 99user.ldif file and not to your custom schema file, thus overriding your original custom schema definition. For example, changes to 60siroecorp.ldif will be overwritten by the definitions stored in 99user.ldif.


  • If adding schema elements to the 99user.ldif manually, always use an X-ORIGIN of value 'user defined'. If you use something other than 'user defined', when the server loads the schema from the 99user.ldif file, it will add the 'user defined' value to the X-ORIGIN portion of the definition in addition to what you have already specified for the X-ORIGIN. The result is that attributes that are not 'user defined' will appear in the read-only section of the Directory Server Console, and you will not be able to use the Console to edit object classes that contain an X-ORIGIN other than 'user defined'.

    Using an X-ORIGIN of value 'user defined' ensures that schema definitions in the 99user.ldif file are not removed from the file by the directory. The directory does not remove them because it relies on an X-ORIGIN of'user defined' to tell it what elements should reside in the 99user.ldif file.

    For example, you create a schema entry manually in 99user.ldif as follows:

    attributetypes: ( siroeContact-oid NAME 'siroeContact' DESC
     'Siroe Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     X-ORIGIN 'Siroe defined')

    After the directory loads the schema entry, it appears as follows:

    attributetypes: ( siroeContact-oid NAME 'siroeContact' DESC
     'Siroe Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     X-ORIGIN ('Siroe defined' 'user defined') )

  • When adding new schema elements, all attributes need to be defined before they can be used in an object class. You can define attributes and object classes in the same schema file.

  • Each custom attribute or object class you create should be defined in only one schema file. This prevents the server from overriding any previous definitions when it loads the most recently created schema (as the server loads the schema in numerical order first, then alphabetical order).



Maintaining Data Consistency

Maintaining data consistency within Directory Server aids LDAP client applications in locating directory entries. For each type of information you store in the directory, you should select the required object classes and attributes to support that information, and always use the same ones. If you use schema objects inconsistently, it becomes very difficult to locate information in your directory tree efficiently.

You can maintain schema consistency in the following ways:

  • Use schema checking to ensure attributes and object classes conform to the schema rules.

  • Select and apply a consistent data format.

The following sections describe in detail how to maintain consistency within your schema.


Schema Checking

Schema checking ensures that all new or modified directory entries conform to the schema rules. When the rules are violated, the directory rejects the requested change.


Note Schema checking checks only that the proper attributes are present. It does not verify whether attribute values are in the correct syntax for the attribute.


By default, the directory enables schema checking. We do not recommend turning it off. For information on turning schema checking on and off, see the iPlanet Directory Server Administrator's Guide.

With schema checking on, you must be attentive to required and allowed attributes as defined by the object classes. Object class definitions usually contain at least one required attribute, and one or more optional attributes. Optional attributes are attributes that you are allowed, but not required, to add to the directory entry. If you attempt to add an attribute to an entry that is neither required nor allowed according to the entry's object class definition, then Directory Server returns an object class violation message.

For example, if you define an entry to use the organizationalPerson object class, then the commonName (cn) and surname (sn) attributes are required for the entry (you must specify values for these attributes when you create the entry). In addition, there is a fairly long list of attributes that you can optionally use on the entry. This list includes such descriptive attributes as telephoneNumber, uid, streetAddress, and userPassword.


Selecting Consistent Data Formats

LDAP schema allows you to place any data that you want on any attribute value. However, it is important to store data consistently in your directory tree by selecting a format appropriate for your LDAP client applications and directory users.

With the LDAP protocol and iPlanet Directory Server, you must represent data in the data formats specified in RFC 2252.

In addition, the correct LDAP format for telephone numbers is defined in the following ITU-T Recommendations documents:

  • ITU-T Recommendation E.123.

    Notation for national and international telephone numbers.

  • ITU-T Recommendation E.163.

    Numbering plan for the international telephone services.

For example, a US phone number would be formatted as follows:

+1 555 222 1717

The postalAddress attribute expects an attribute value in the form of a multiline string that uses dollar signs ($) as line delimiters. A properly formatted directory entry appears as follows:

postalAddress: 1206 Directory Drive$Pleasant View, MN$34200


Maintaining Consistency in Replicated Schema

When iPlanet Directory Server is used in a replicated environment, the schema must be consistent throughout all of the directory servers that participate in replication. The only way to guarantee this level of consistency is to make schema modifications on a single master server.

When you make changes to your directory schema, the change is recorded in the change log. During replication, the change log is scanned for changes, and any changes made are replicated. Consider the following points for maintaining consistent schema in a replicated environment:

  • Do not modify the schema on a consumer server.

    If you modify the schema on a consumer server, it will be more recent than the schema on the master server. Therefore, when the master sends replication updates to the consumer, you will probably observe a number of replication errors because the schema on the consumer cannot support the new data.

  • Do not modify the schema on two master servers.

    If you modify the schema on two master servers, the master that was most recently updated will propagate its version of the schema to the consumer. This means that the schema on the consumer will be inconsistent with the schema on the other master.

  • Always modify schema on a single master server, even in a multi-master replication environment.

For more information on schema replication, refer to "Schema Replication".



Other Schema Resources


Refer to the following links for more information about standard LDAPv3 schema:


Previous     Contents     Index     DocHome     Next     
Copyright © 2002 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated February 26, 2002