Checking an entry against the schema

Edit online

This feature enables to check the entry against the schema.

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 them by providing an ibm-slapdSchemaCheck value to the ibmslapd.conf configuration directive. See the Installing and configuring section of the IBM® Security Verify Directory documentation for information about schema configuration attributes.

To comply with the schema an entry is checked for the following conditions:
With respect to object classes:
  • Must have at least one value of attribute type "objectClass".
  • 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.
  • 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.
  • Must have at least one structural object class.
  • Must have exactly one immediate or base structural object class. This means that of all the structural object classes provided with the entry, every object class 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.
  • Cannot change its immediate structural object class (on ldap_modify).
  • 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.
The validity of the attribute types for an entry is determined as follows:
  • 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.
  • 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.
  • If any of the attribute types defined for the entry are marked as NO-USER-MODIFICATION, the entry is rejected.
The validity of the attribute type values for an entry is determined as follows:
  • 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.
  • 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.
  • 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.
The validity of the DN is checked as follows:
  • The syntax is checked for compliance with the BNF for the Distinguished Names. If it does not comply, the entry is rejected.
  • It is verified that the RDN® is made up of only attribute types that are valid for that entry.
  • It is verified that the values of the attribute types used in the RDN appear in the entry.