Intro_6Schema

Directory Server schema reference

Description

Directory schema form a set of rules defining how data are stored in the directory. Data are stored in the form of directory entries. 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 requirements, but use standard schema where possible.

OBJECT CLASSES

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
Locations, such as the country name and description
Organizations
People
Devices

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.
Auxiliary: Indicates the attributes that the entry may have. An auxiliary object class does not represent a real world object, but represents additional attributes that can be associated with a structural object class to supplement its specification. Each entry may belong to only a single structural object class, but may belong to zero or more auxiliary object classes.
Abstract: Defined only as a superclass or template for other (structural) object classes. An abstract object class is a way of collecting a set of attributes that will be common to a set of structural object classes, so that these classes may be derived as subclasses of the abstract class rather than being defined from scratch. An entry may not belong to an abstract object class.

Note:

Directory Server does not distinguish between structural and auxiliary object classes.

Required and Allowed Attributes

Every object class includes a number of required attributes and allowed attributes. Required attributes 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 may be present in entries using the object class.

For example, the person object class requires attributes objectClass, cn (Common Name), and sn (Surname). It allows attributes description, seeAlso, telephoneNumber, and userPassword.

Object Class Inheritance

Each entry must be assigned to one structural object class. All object classes inherit from the top object class. 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:

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

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.

Note that object class inheritance is dependent on the order in which the object classes appear in the schema .ldif files. The order in which object classes appear in the .ldif file must be consistent with the object class hierarchy, otherwise the server will not start. An object class that inherits from another object class must therefore appear after this object class in the schema .ldif file.

ATTRIBUTE TYPES

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

cn: Babs Jensen

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:

givenname: Barbara

surname: Jensen

mail: bjensen@example.com

Attribute Syntax

Each attribute has a syntax definition that describes the type of information provided by the attribute.

Attribute syntax is used by Directory Server to perform sorting and pattern matching.

The following table lists the different syntax methods that can be applied to attributes, and gives an OID and a definition for each syntax method.

Table 4-1 Attribute Syntax

Syntax and OID	Definition
Binary - 1.3.6.1.4.1.1466.115.121.1.5	Indicates that values for this attribute are treated as binary data, and cannot be matched.
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, representing the ISO-3166 code of a country for example `FR`.
DN - 1.3.6.1.4.1.1466.115.121.1.12	Indicates that values for this attribute are DNs (distinguished names).
DirectoryString - 1.3.6.1.4.1.1466.115.121.1.15	Indicates that values for this attribute are UTF-8 encoded characters, and are treated as case insensitive.
GeneralizedTime - 1.3.6.1.4.1.1466.115.121.1.24	Indicates that values for this attribute are encoded as printable strings. You cannot specify a local time in this attribute. GMT must be used.
IA5String - 1.3.6.1.4.1.1466.115.121.1.26	Indicates that values for this attribute must contain only ASCII characters, and are treated as case sensitive.
INTEGER - 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 - 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.4401.1.1.1	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. Refer to RFC 2396.

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-valued (only one instance of the attribute can be specified) are noted as such. For example, uidNumber can have only one possible value.

SUPPORTED SCHEMA

The schema provided with Directory Server is described in a set of files stored in the $INSTANCE_DIR/config/schema/ directory, where $INSTANCE_DIR represents the directory containing files for the Directory Server instance.

You can modify the schema by creating new object classes and attributes. Your modifications are stored in a file called 99user.ldif. Do not modify the other schema files provided with Directory Server, because you run the risk of breaking compatibility with other Sun products, and of causing interoperability problems with directory servers from other vendors.

For information about how Directory Server stores information and suggestions for planning directory schema, refer to Directory Server Enterprise Edition Deployment Planning Guide.

The following tables list the schema files that are provided with Directory Server.

Table 4-2 Schema Files Used by Directory Server

Schema Filename	Purpose
`00core.ldif`	Recommended core schema from the X.500 and LDAP standards (RFCs), and schema used by Directory Server itself.
`05rfc2247.ldif`	Schema from RFC 2247 and related pilot schema "Using Domains in LDAP/X.500 Distinguished Names."
`05rfc2927.ldif`	Schema from RFC 2927 ”MIME Directory Profile for LDAP Schema."
`11rfc2307.ldif`	Schema from RFC 2307 ”An Approach for Using LDAP as a Network Information Service."
`20subscriber.ldif`	Common schema elements for Nortel subscriber interoperability.
`25java-object.ldif`	Schema from RFC 2713 ”Schema for Representing Java^TM Objects in an LDAP Directory."
`28pilot.ldif`	Schema from the pilot RFCs, especially RFC 1274, that is no longer recommended for use in new deployments.
`30ns-common.ldif`	Common Sun Java System schema.
`50ns-admin.ldif`	Schema used by Sun Java System Administration Services.
`50ns-directory.ldif`	Additional schema used by Directory Server 4.x.
`50ns-value.ldif`	Sun Java System servers ”value item" schema.
`99user.ldif`	Placeholder for your modifications to the schema.

The following table lists the schema files that are used by other Sun products.

Table 4-3 Schema Files Used by Other Sun Products

Schema Filenames	Purpose
`50iplanet-servicemgt.ldif`	Service management schema elements.
`50ns-calendar.ldif`	Calendar Server schema.
`50ns-certificate.ldif`	Schema for Certificate Management System.
`50ns-compass.ldif`	Schema for the Netscape Compass Server.
`50ns-delegated-admin.ldif`	Schema for Delegated Administrator 4.5.
`50ns-legacy.ldif`	Legacy Netscape Schema.
`50ns-mail.ldif`	Schema for Messaging Server.
`50ns-mcd-browser.ldif`	Schema for Netscape Mission Control Desktop - Browser.
`50ns-mcd-config.ldif`	Schema for Netscape Mission Control Desktop - Configuration.
`50ns-mcd-li.ldif`	Schema for Netscape Mission Control Desktop - Location Independence.
`50ns-mcd-mail.ldif`	Schema for Netscape Mission Control Desktop - Mail.
`50ns-media.ldif`	Schema for Netscape Media Server.
`50ns-mlm.ldif`	Schema for Mailing List Manager.
`50ns-msg.ldif`	Schema for Web Mail.
`50ns-netshare.ldif`	Schema for Netshare.
`50ns-news.ldif`	Schema for Collabra Server.
`50ns-proxy.ldif`	Schema for Web Proxy Server.
`50ns-wcal.ldif`	Schema for Web Calendaring.
`50ns-web.ldif`	Schema for Web Server.

OBJECT IDENTIFIERS

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, Directory Server automatically uses ObjectClass_name-oid and attribute_name-oid.

Directory Server uses Sun-based OIDs. Previous versions of Directory Server used Netscape-based OIDs.

Sun-defined attributes and object classes using the Sun base have the base OID of 1.3.6.1.4.1.42.2.27.9.

Sun-defined attributes and object classes using the Netscape base have the base OID of 2.16.840.1.113730.3

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

EXTENDING 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 Directory Server compatibility with existing LDAP clients that rely on the standard LDAP schema and may cause difficulties when upgrading Directory Server.

SCHEMA CHECKING

When possible, run Directory Server with schema checking turned on.

The schema checking capability of 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 Directory Server schema
Attributes required for an object class are contained in the entry
Only attributes allowed by the object class are contained in the entry

Schema checking also occurs when importing a database using LDIF. For more information, refer to Administrator's Guide for Oracle Directory Server Enterprise Edition for further information.

Note:

Directory Server schema checking does not enforce the validity of values with respect to their syntax.

COLLECTIONS

This collection contains the collections documented in the following additional pages:

adminserv(5DSSD), attributes(5DSSD), changelog_5dssd(5DSSD), dirserv(5DSSD), idpilot(5DSSD), numsub(5DSSD), objects(5DSSD), operational(5DSSD), pwpolicy(5DSSD), rfc2079(5DSSD), rfc2247(5DSSD), rfc2307(5DSSD), rfc2713(5DSSD), rfc2798(5DSSD), rfc3045(5DSSD), rfc3296(5DSSD),rfc4512(5DSSD)rfc4517(5DSSD), rfc4519(5DSSD), rfc4523(5DSSD), rfc4524(5DSSD), sasl(5DSSD), subentry(5DSSD), wppilot(5DSSD)

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWdsee7
Stability Level	Evolving