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.
|
|
Caution
|
Directory Server fails to start if schema
definitions include too few or too many space characters.
Use exactly one space in those places where
the LDAP standards allow the use of zero or many spaces; for example,
the place between the NAME keyword and the name of an attribute type.
|
|
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.
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
object class 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
objectclass
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
The schema provided with Directory Server
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 are 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.
