Schema introduction

Attribute types define the characteristics of the data values stored in the directory. Each attribute type that is defined in a schema must contain a unique numeric object identifier and optionally contain a textual name, zero or more alias names, and a description of the attribute type. The characteristics defined for each attribute type include the syntax, number of values, and matching rules.

Matching rules might be specified for EQUALITY, ORDERING, and SUBSTR (substring matching). The matching rule determines how comparisons between values are done. The EQUALITY matching rule determines if two values are equal. Examples of EQUALITY matching rules are caseIgnoreMatch, caseExactMatch, and telephoneNumberMatch. The ORDERING matching rule determines how two values are ordered (greaterThanOrEqual, lessThanOrEqual). Examples of ORDERING matching rules are caseIgnoreOrderingMatch and generalizedTimeOrderingMatch. The SUBSTR matching rule determines if the presented value is a substring of an attribute value from the directory. Examples of SUBSTR matching rules are caseIgnoreSubstringsMatch and telephoneNumberSubstringsMatch.

If EQUALITY, ORDERING, or SUBSTR matching rules are not specified in the definition of an attribute type or through the inheritance hierarchy, the z/OS LDAP server performs evaluations to the best of its ability, but the results might not be as expected. The z/OS LDAP server uses the matching rules shown in the following table based on attribute type syntax to evaluate EQUALITY, ORDERING, and SUBSTR if those matching rules are not specified.

The syntax or matching rule values might be inherited by specifying a superior attribute type. This is done by specifying the keyword SUP, followed by the object identifier of the superior attribute type. This is known as an attribute type hierarchy and referred to as inheritance. A superior hierarchy might be created with multiple levels of inheritance. In the following partial example, ePersonName and personName would inherit their SYNTAX from name.

ePersonName SUP personName
personName SUP name
name SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

When the SYNTAX, EQUALITY, ORDERING, or SUBSTR values are not specified for an attribute type, the attribute type hierarchy are used to determine these values. The SYNTAX must be specified on the attribute type or through inheritance.

The number of values that might be stored in each entry for an attribute type is limited to one value if the keyword SINGLE-VALUE is specified. Otherwise, any number of attribute values might exist in the entry.

The OBSOLETE keyword indicates that the attribute type cannot be used to add data to existing entries or to store data in new entries. Modifications to entries that contain data values of an attribute type which has been made obsolete fails unless all data values for all obsolete attribute types are removed during the modification. Searches specifying the obsolete attribute type returns the entries containing the attribute type. If an obsolete attribute type is referred to in a superior hierarchy, the inherited values continue to be resolved.

Example 1:

attributeTypes: ( 1.2.3.4 NAME ’obsattr1’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 OBSOLETE )
attributeTypes: ( 5.6.7.8 NAME ’validattr1’ SUP obsattr1 )

would be the same as

attributeTypes: ( 5.6.7.8 NAME ’validattr’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Example 2:

attributeTypes: ( 10.20.30.40 NAME ’obsattr2’ SUP obsattr3 )
attributeTypes: ( 50.60.70.80 NAME ’obsattr3’ 
  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributeTypes: ( 90.100.110.120 NAME ’validattr2’ SUP obsattr2 )

would be the same as

attributeTypes: ( 90.100.110.120 NAME ’validattr2’ 
  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

The USAGE keyword's valid values are userApplications or one of three operational values (directoryOperation, distributedOperation, or dSAOperation). An attribute type that has an operational USAGE value, is called an operational attribute while all other attribute types are also known as non-operational attribute types. Operational attributes are treated differently than non-operational attributes. In particular, the value of an operational attribute type in an entry is only returned by a search operation if the attribute type is specified in the list of attributes to be returned. If a plus sign, +, is specified in the list of attributes to be returned, then all operational attributes other than ibm-allMembers, ibm-allGroups, ibm-entryCheckSum, ibm-entryCheckSumOp, and hasSubordinates are returned on the search response, if the user is authorized to read those operational attributes. Also, operational attribute types do not have to belong to an object class. The default for USAGE is userApplications. By default, non-operational attribute types are returned on a search response if the user is authorized to read those attributes. If an asterisk, '*', is specified in the list of attributes to be returned, then all non-operational attributes are returned. Specifying both '*' and '+' returns non-operational and operational attribute types that the user is authorized to read.

The z/OS LDAP server restricts users from modifying data values specified for an attribute type when NO-USER-MODIFICATION is specified on the definition of the attribute type. In general, NO-USER-MODIFICATION should only be specified for attribute types that are set by the server because they cannot be assigned a value by the user. Attribute types which are NO-USER-MODIFICATION can be modified during replication processing and when the LDAP server is in maintenance mode. See Basic replication maintenance mode and Advanced replication maintenance mode for more information.

Additional information required by IBM LDAP servers for each attribute type defined in the schema is specified using the IBMAttributeTypes schema attribute. The IBMAttributeTypes schema attribute is an extension of the attributeTypes schema attribute. If the attributeTypes value is not defined, then the corresponding IBMAttributeTypes value cannot be defined. For the z/OS LDAP server, the additional information defined using this attribute is the ACCESS-CLASS and the RACFFIELD of the associated attribute type.

ACCESS-CLASS specifies the level of access users have to data values of this attribute type. The levels that might be specified for user-defined attribute types are normal, sensitive, and critical. The system and restricted keywords are for LDAP server use and are specified for some of the attribute types controlled by the server. See Attribute access classes for the definition of access classes.

RACFFIELD specifies the information needed to associate this attribute type with a RACF® custom field. The presence of RACFFIELD indicates that this attribute type is used to represent a RACF custom field in a user or group profile.

Object classes define the characteristics of individual directory entries. The object classes listed in a directory entry determine the set of required and optional attributes for the entry. Each object class defined in a schema must contain a unique numeric object identifier and optionally contain a textual name, zero or more alias names, a description of the object class, and lists of required (MUST) or optional (MAY) attribute types.

Required and optional attribute types for an object class might be inherited by specifying one or more superior object classes in an object class definition. This is done by specifying the keyword SUP followed by the object identifiers of the superior object classes. This is known as an object class hierarchy and referred to as multiple inheritance. A superior hierarchy might be created with multiple levels of inheritance.

Each object class is defined as one of three types: STRUCTURAL, ABSTRACT, or AUXILIARY. The type can be specified when the object class is defined. If the type is not specified, it defaults to STRUCTURAL.

The structural object class defines the characteristics of a directory entry. Each entry must specify exactly one base structural object class. A base structural object class is defined as the most subordinate object class in an object class hierarchy. The structural object class of an entry cannot be changed. Once an entry is defined in the directory, it must be deleted and re-created to change the structural object class.

Abstract and auxiliary object classes are used to provide common characteristics to entries with different structural object classes. Abstract object classes are used to derive additional object classes. Abstract object classes must be referred to in a structural or auxiliary superior hierarchy. Auxiliary object classes are used to extend the set of required or optional attribute types of an entry.

When using the keyword SUP to create an object class hierarchy, an auxiliary class should only specify superior object classes that are either auxiliary or abstract object classes. Similarly, a structural object class should only specify superior object classes that are either structural or abstract object classes. If these rules are not followed, the z/OS LDAP server might not be able to determine the base structural object class of the entry, resulting in the rejection of the entry.

An example of the relationship between structural, abstract, and auxiliary object classes is the schema entry shown in Figure 1. The schema entry specifies top, subEntry, subSchema, and ibmSubschema as object classes. The object classes form the following hierarchy:

In this example, the subEntry object class is the base structural object class.

The OBSOLETE keyword indicates that the object class cannot be used to define entries in the directory. When an object class is made obsolete, new entries specifying the obsoleted object class cannot be added to the directory and existing entries cannot be modified unless the obsolete object class is removed from the entries’ object class list. When the obsolete object class is removed from the entry, any attributes in the entry that are associated only with that object class must also be removed. These changes must be made through the same modify operation. If an obsolete object class is specified in a superior hierarchy for a new entry, then attempts to add the entry to the LDAP directory fails.

Each attribute type definition includes the LDAP syntax which applies to the values for the attribute. The LDAP syntax defines the set of characters which are allowed when entering data into the directory.

Matching rules allow entries to be selected from the database based on the evaluation of the matching rule assertion. Matching rule assertions are propositions which might evaluate to true, false, or undefined concerning the presence of the attribute value or values in an entry.