136 lines
7.8 KiB
HTML
136 lines
7.8 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow"/>
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<title>Directory Server (LDAP) - Schema checking</title>
|
||
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
</head>
|
||
|
<body>
|
||
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
||
|
|
||
|
<a name="rzahyschemacheck"></a>
|
||
|
<h3 id="rzahyschemacheck">Schema checking</h3>
|
||
|
<p>When the server is initialized, the schema files are read and checked for
|
||
|
consistency and correctness. If the checks fail, the server fails to initialize
|
||
|
and issues an error message. During any dynamic schema change, the resulting
|
||
|
schema is also checked for consistency and correctness. If the checks fail,
|
||
|
an error is returned and the change fails. Some checks are part of the grammar
|
||
|
(for example, an attribute type can have at most one supertype, or an object
|
||
|
class can have any number of superclasses).</p>
|
||
|
<p>The following items are checked for attribute types:</p>
|
||
|
<ul>
|
||
|
<li>Two different attribute types cannot have the same name or OID.</li>
|
||
|
<li>The inheritance hierarchy of attribute types does not have cycles.</li>
|
||
|
<li>The supertype of an attribute type must also be defined, although its
|
||
|
definition might be displayed later, or in a separate file.</li>
|
||
|
<li>If an attribute type is a subtype of another, they both have the same
|
||
|
USAGE.</li>
|
||
|
<li>All attribute types have a syntax either directly defined or inherited.</li>
|
||
|
<li>Only operational attributes can be marked as NO-USER-MODIFICATION.</li></ul>
|
||
|
<p>The following items are checked for object classes:</p>
|
||
|
<ul>
|
||
|
<li>Two different object classes cannot have the same name or OID.</li>
|
||
|
<li>The inheritance hierarchy of object classes does not have cycles.</li>
|
||
|
<li>The superclasses of an object class must also be defined, although its
|
||
|
definition might appear later or in a separate file.</li>
|
||
|
<li>The "MUST" and "MAY" attribute types of an object class must also be defined,
|
||
|
although its definition might appear later or in a separate file.</li>
|
||
|
<li>Every structural object class is a direct or indirect subclass of top.</li>
|
||
|
<li>If an abstract object class has superclasses, the superclasses must also
|
||
|
be abstract.</li></ul>
|
||
|
<p><span class="bold">Checking an entry against the schema</span></p>
|
||
|
<p>When an entry is added or modified through an LDAP operation, the entry
|
||
|
is checked against the schema. By default, all checks listed in this section
|
||
|
are performed. However you can selectively disable some of the schema checking
|
||
|
by changing the schema checking level. This is done through iSeries Navigator
|
||
|
by changing the value of the <span class="bold">Schema checking</span> field
|
||
|
on the <span class="bold">Database/Suffixes</span> page of the Directory
|
||
|
Server properties. See <a href="rzahyconfigschema.htm#rzahyconfigschema">Directory Server configuration schema</a> for information about
|
||
|
schema configuration attributes.</p>
|
||
|
<p>To comply with the schema an entry is checked for the following conditions:</p>
|
||
|
<dl>
|
||
|
<dt class="bold">With respect to object classes: </dt>
|
||
|
<dd>
|
||
|
<ul>
|
||
|
<li>Must have at least one value of attribute type "objectClass".</li>
|
||
|
<li>Can have any number of auxiliary object classes including zero. This is
|
||
|
not a check, but a clarification. There are no options to disable this.</li>
|
||
|
<li>Can have any number of abstract object classes, but only as a result of
|
||
|
class inheritance. This means that for every abstract object class that the
|
||
|
entry has, it also has a structural or auxiliary object class that inherits
|
||
|
directly or indirectly from that abstract object class.</li>
|
||
|
<li>Must have at least one structural object class.</li>
|
||
|
<li>Must have exactly one immediate or base structural object class. This
|
||
|
means that of all the structural object classes provided with the entry, they
|
||
|
all must be superclasses of exactly one of them. The most derived object class
|
||
|
is called the "immediate" or "base structural" object class of the entry,
|
||
|
or simply the "structural" object class of the entry.</li>
|
||
|
<li>Cannot change its immediate structural object class (on ldap_modify).</li>
|
||
|
<li>For each object class provided with the entry, the set of all of its direct
|
||
|
and indirect superclasses is calculated; if any of those superclasses is not
|
||
|
provided with the entry, then it is automatically added.</li>
|
||
|
<li>If the schema checking level is set to <span class="bold">Version
|
||
|
3 (strict)</span> all structural superclasses must be provided. For example,
|
||
|
to create an entry with objectclass inetorgperson, the following objectclasses
|
||
|
must be specified: person, organizationalperson, and inetorgperson.</li></ul>
|
||
|
</dd>
|
||
|
<dt class="bold">The validity of the attribute types for an entry
|
||
|
is determined as follows: </dt>
|
||
|
<dd>
|
||
|
<ul>
|
||
|
<li>The set of MUST attribute types for the entry is calculated as the union
|
||
|
of the sets of MUST attribute types of all of its object classes, including
|
||
|
the implied inherited object classes. If the set of MUST attribute types for
|
||
|
the entry is not a subset of the set of attribute types contained by the entry,
|
||
|
the entry is rejected.</li>
|
||
|
<li>The set of MAY attribute types for the entry is calculated as the union
|
||
|
of the sets of MAY attribute types of all of its object classes, including
|
||
|
the implied inherited object classes. If the set of attribute types contained
|
||
|
by the entry is not a subset of the union of the sets of MUST and MAY attribute
|
||
|
types for the entry, the entry is rejected.</li>
|
||
|
<li>If any of the attribute types defined for the entry are marked as NO-USER-MODIFICATION,
|
||
|
the entry is rejected.</li></ul>
|
||
|
</dd>
|
||
|
<dt class="bold">The validity of the attribute type values for an
|
||
|
entry is determined as follows: </dt>
|
||
|
<dd>
|
||
|
<ul>
|
||
|
<li>For every attribute type contained by the entry, if the attribute type
|
||
|
is single-valued and the entry has more than one value, the entry is rejected.</li>
|
||
|
<li>For every attribute value of every attribute type contained by the entry,
|
||
|
if its syntax does not comply with the syntax checking routine for the syntax
|
||
|
of that attribute, the entry is rejected.</li>
|
||
|
<li>For every attribute value of every attribute type contained by the entry,
|
||
|
if its length is greater than the maximum length assigned to that attribute
|
||
|
type, the entry is rejected.</li></ul>
|
||
|
</dd>
|
||
|
<dt class="bold">The validity of the DN is checked as follows: </dt>
|
||
|
<dd>
|
||
|
<ul>
|
||
|
<li>The syntax is checked for compliance with the BNF for DistinguishedNames.
|
||
|
If it does not comply, the entry is rejected.</li>
|
||
|
<li>It is verified that the RDN is made up with only attribute types that
|
||
|
are valid for that entry.</li>
|
||
|
<li>It is verified that the values of attribute types used in the RDN appear
|
||
|
in the entry.</li></ul>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
</body>
|
||
|
</html>
|