Netscape logo Schema Reference
Netscape Directory Server

Previous      Contents      Index      DocHome      Next     

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.

This chapter contains the following sections:

Schema Definition


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 Netscape Directory Server (Directory Server) uses the schema, refer to the Netscape Directory Server Deployment Guide.

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:

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

Required Attributes

object class
cn (common name)
sn (surname)

Allowed Attributes

description
seeAlso
telephoneNumber
userPassword

Object Class Inheritance

An entry can have more than one object class. For example, the entry for a person is defined by the person object class, but may also be defined by attributes in the inetOrgPerson, groupOfNames, and organization 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.

Attributes

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 Jonas Salk can be represented in the directory as

cn: Jonas Salk

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: Jonas
surname: Salk
mail: jonass@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 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.


Table 1-1    Attribute Syntax  


Syntax Method

OID

Definition

Binary

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 US

DN

1.3.6.1.4.1.1466.115.121.1.12

Indicates that values for this attribute are DNs.

DirectoryString

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 time.

IA5String

1.3.6.1.4.1.1466.115.121.1.26

Indicates that values for this attribute are 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 according to

postal-address = dstring * ("$" dstring)

where each dstring component is encoded as a value of type DirectoryString syntax. Backslashes and dollar characters, if they occur, are 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 1234$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

Indicates that the values for this attribute are in the form of a URL, introduced by a string such as http://, https://, ftp://, ldap://, and ldaps://. The URI has the same behavior as IA5String. See 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 object class are all attributes that can have more than one value. Attributes that are single-valued—that is, only one instance of the attribute can be specified—are noted as such. For example, uidNumber can only have one possible value.

Schema Supported by Directory Server 6.x


The schema provided with Directory Server 6.x is described in a set of files stored in the serverRoot/slapd-serverID/config/schema directory.

You 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 Netscape products, or of causing interoperability problems with directory servers from vendors other than Netscape Communications Corporation.

For more information about how the Directory Server stores information and suggestions for planning directory schema, refer to the Netscape Directory Server Deployment Guide.

The following tables list the schema files that are provided with 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 Netscape products.


Table 1-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 the 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."

10presence.ldif

Schema for Presence information; the file lists the default object classes with the allowed attributes that must be added to a user's entry in order for instant-messaging presence information to be available for that user.

10rfc2307.ldif

Schema from RFC 2307 "An Approach for Using LDAP as a Network Information Service."

20subscriber.ldif

Common schema elements for Netscape-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 by Netscape for use in new deployments.

30ns-common.ldif

Common Netscape schema.

50ns-directory.ldif

Additional schema used by Directory Server 4.x.

50ns-value.ldif

Netscape servers "value item" schema.

99user.ldif

Customer modifications to the schema.




Table 1-3    Schema Files used by other Netscape Products  


Schema Filenames

Purpose

50netscape-servicemgt.ldif

Netscape service management schema elements.

50ns-admin.ldif

Schema used by Netscape Administration Server.

50ns-calendar.ldif

Netscape Calendar Server schema.

50ns-certificate.ldif

Schema for Netscape Certificate Management System.

50ns-compass.ldif

Schema for the Netscape Compass Server.

50ns-delegated-admin.ldif

Schema for Netscape Delegated Administrator 4.5.

50ns-legacy.ldif

Legacy Netscape Schema.

50ns-mail.ldif

Schema for Netscape 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 Netscape Mailing List Manager.

50ns-msg.ldif

Schema for Netscape Web Mail.

50ns-netshare.ldif

Schema for Netscape Netshare.

50ns-news.ldif

Schema for Netscape Collabra Server.

50ns-proxy.ldif

Schema for Netscape Proxy Server.

50ns-wcal.ldif

Schema for Netscape Web Calendaring.

50ns-web.ldif

Schema for Netscape Web Server.

51ns-calendar.ldif

Schema for Netscape Calendar Server.



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 Directory Server is

2.16.840.1.113730.3

All Netscape-defined attributes have the base OID of

2.16.840.1.113370.3.1

All Netscape-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 Internet Assigned Number Authority (IANA) web site 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 Netscape Directory Server Deployment Guide.

Schema Checking


You should 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:

Schema checking also occurs when importing a database using LDIF. For more information, refer to the Netscape Directory Server Administrator's Guide.



Previous      Contents      Index      DocHome      Next     

© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002-2003 Netscape Communications Corporation. All rights reserved.
Read the Full Copyright and Thrid-Party Acknowledgments.


Last Updated October 30, 2003