Softerra LDAP Administrator HelpShow AllHide All

LDAP Schema Overview

Here is how the [X.501] standard defines an LDAP Schema:

The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible ways entries are named, the information that can be held in an entry, the attributes used to represent that information and their organization into hierarchies to facilitate search and retrieval of the information and the ways in which values of attributes may be matched in attribute value and matching rule assertions.

Below are the examples of what a schema enables the Directory system to accomplish:

Formally, the Directory Schema comprises a set of the following:

  1. Name Form definitions that define primitive naming relations for structural object classes;

  2. DIT Structure Rule definitions that define the names that entries may have and the ways in which the entries may be related to one another in the DIT;

  3. DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond those indicated by the structural object classes of the entries;

  4. Object Class definitions that define the basic set of mandatory and optional attributes that shall be present, and may be present, respectively, in an entry of a given class, and which indicate the kind of object class that is being defined;

  5. Attribute Type definitions that identify the object identifier by which an attribute is known, its syntax, associated matching rules, whether it is an operational attribute and if so its type, whether it is a collective attribute, whether it is permitted to have multiple values and whether or not it is derived from another attribute type;

  6. Matching Rule definitions that define matching rules;

  7. (LDAP Specific) LDAP Syntaxes definitions that define encodings used in LDAP.

An LDAP Server stores its schema definition using a special kind of LDAP entries called subschema subentries. One subschema subentry contains all schema definitions used by entries in a particular directory tree location. To find out what DN the subentry holding the subschema that controls a particular entry really has, a client should read that entry's subschemasubentry operational attribute.

See Also