Managing the IBM Directory schema

Directory Server, Version 6.1

Managing the IBM Directory schema

A schema is a set of rules that governs the way that data can be stored in the directory. The schema defines the type of entries allowed, their attribute structure, and the syntax of the attributes.
The schema information shipped with the server, such as object class descriptions and syntax, is in English. It is not translated.
Data is stored in the directory using directory entries. An entry consists of an object class, which is required, and its attributes. Attributes can be either required or optional. The object class specifies the kind of information that the entry describes and defines the set of attributes it contains. Each attribute has one or more associated values. See Working with directory entries for additional information about entries.
The schema for the IBM® Directory Version 6.1 is predefined. However, we can modify the schema, if you have additional requirements.
The IBM Tivoli® Directory Server includes dynamic schema support. The schema is published as part of the directory information, and is available in the Subschema entry (DN="cn=schema"). We can query the schema using the ldap_search() API and modify it using ldap_modify(). See the IBM Directory Client SDK Programming Reference for more information about these APIs.
The schema has more configuration information than that included in the LDAP Version 3 Request For Comments (RFCs) or standard specifications. For example, for a given attribute, we can state which indexes must be maintained. This additional configuration information is maintained in the subschema entry as appropriate. An additional object class is defined for the subschema entry IBMsubschema , which has "MAY" attributes that hold the extended schema information.
IBM Tivoli Directory Server requires that the schema defined for a naming context be stored in a special directory entry, "cn=schema". The entry contains all of the schema defined for the server. To retrieve schema information, we can perform an ldap_search by using the following:
 DN: "cn=schema", search scope: base, filter: objectclass=subschema
 or objectclass=*
The schema provides values for the following attribute types:

objectClasses (See Working with object classes.)
attributeTypes (See Working with attributes.)
IBMAttributeTypes (See The IBMAttributeTypes attribute type.)
matching rules (See Equality matching rules).
ldap syntaxes (See Attribute syntax).

The syntax of these schema definitions is based on the LDAP Version 3 RFCs.
A sample schema entry might contain:
 objectclasses=( 1.3.6.1.4.1.1466.101.120.111
                 NAME 'extensibleObject'
                 SUP top AUXILIARY )

  objectclasses=(  2.5.20.1
                  NAME 'subschema'
                  AUXILIARY MAY
                      ( dITStructureRules
                     $ nameForms
                     $ ditContentRules
                     $ objectClasses
                     $ attributeTypes
                     $ matchingRules
                     $ matchingRuleUse  ) )
  objectclasses=( 2.5.6.1
                  NAME 'alias'
                  SUP top STRUCTURAL
                  MUST aliasedObjectName )

  attributeTypes {
      ( 2.5.18.10 NAME 'subschemaSubentry' EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
        SINGLE-VALUE USAGE directoryOperation )
      ( 2.5.21.5 NAME 'attributeTypes'
          EQUALITY objectIdentifierFirstComponentMatch
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
      ( 2.5.21.6 NAME 'objectClasses'
          EQUALITY objectIdentifierFirstComponentMatch
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation )
}


    ldapSyntaxes {
              ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
              ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
              ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
              ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
              ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
              ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
              ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
              ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
              ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
    }

    matchingRules {
        ( 2.5.13.2 NAME 'caseIgnoreMatch'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
        ( 2.5.13.0 NAME 'objectIdentifierMatch'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
        ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
        ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
    }
As shown in the preceding example, it is not required that all of the attribute values of a given attribute type be provided in a single production.
The schema information can be modified through the ldap_modify API. Consult the Client SDK Programming Reference for additional information. With the DN "cn=schema" we can add, delete, or replace an attribute type or an object class. To delete a schema entity, provide the oid in parenthesis (oid). You also can provide a full description. We can add or replace a schema entry with the LDAP Version 3 definition or with the IBM attribute extension definition or with both definitions.

Common schema support

The IBM Directory supports standard directory schema as defined in the following:

The Internet Engineering Task Force (IETF) LDAP Version 3 RFCs, such as RFC 2252 and 2256.
The Directory Enabled Network (DEN)
The Common Information Model (CIM) from the Desktop Management Task Force (DMTF)
The Lightweight Internet Person Schema (LIPS) from the Network Application Consortium

This version of LDAP includes the LDAP Version 3 defined schema in the default schema configuration. It also includes the DEN schema definitions.
IBM also provides a set of extended common schema definitions that other IBM products share when they exploit the LDAP directory. They include:

Objects for white page applications such as eperson, group, country, organization, organization unit and role, locality, state, and so forth
Objects for other subsystems such as accounts, services and access points, authorization, authentication, security policy, and so forth.

Object identifier (OID)

An object identifier (OID) is a string, of decimal numbers, that uniquely identifies an object. These objects are typically an object class or an attribute. These numbers can be obtained from the IANA (Internet Assigned Number Authority). The IANA Website is located at: http://www.iana.org/iana/.

If you do not have an OID, we can specify the object class or attribute name appended with -oid. For example, if you create the attribute tempID, we can specify the OID as tempID-oid.

Working with object classes

An object class specifies a set of attributes used to describe an object. For example, if you created the object class tempEmployee, it could contain attributes associated with a temporary employee such as, idNumber, dateOfHire, or assignmentLength. We can add custom object classes to suit the needs of your organization. The IBM Tivoli Directory Server schema provides some basic types of object classes, including:

Groups
Locations
Organizations
People

Object classes that are specific to the IBM Tivoli Directory Server have the prefix 'ibm-'.

Defining object classes

Object classes are defined by the characteristics of type, inheritance, and attributes.

Object class type

An object class can be one of three types:

Structural:

Every entry must belong to one and only one structural object class, which defines the base contents of the entry. This object class represents a real world object. Because all entries must belong to a structural object class, this is the most common type of object class.

Abstract:

This type is used as a superclass or template for other (structural) object classes. It defines a set of attributes that are common to a set of structural object classes. These object classes, if defined as subclasses of the abstract class, inherit the defined attributes. The attributes do not need to be defined for each of the subordinate object classes.

Auxiliary:

This type indicates additional attributes that can be associated with an entry belonging to a particular structural object class. Although an entry, can belong to only a single structural object class, it may belong to multiple auxiliary object classes.

Object Class Inheritance

This version of the IBM Tivoli Directory Server supports object inheritance for object class and attribute definitions. A new object class can be defined with parent classes (multiple inheritance) and the additional or changed attributes.
Each entry is assigned to a single structural object class. All object classes inherit from the abstract object class top. They can also inherit from other object classes. The object class structure determines the list of required and allowed attributes for a particular entry. Object class inheritance depends on the sequence of object class definitions. An object class can only inherit from object classes that precede it. For example, the object class structure for a person entry might be defined in the LDIF file as:
objectClass: top 
objectClass: person 
objectClass: organizationalPerson 
In this structure, the organizationalPerson inherits from the person and the top object classes, while person object class only inherits from the top object class. Therefore, when you assign the organizationalPerson object class to an entry, it automatically inherits the required and allowed attributes from the superior object class. In this case, the person object class.
Schema update operations are checked against the schema class hierarchy for consistency before being processed and committed.

Attributes

Every object class includes a number of required attributes and optional attributes. Required attributes are the attributes that must be present in entries using the object class. Optional attributes are the attributes that may be present in entries using the object class.

Viewing object classes

We can view the object classes in the schema using either the Web Administration Tool, the preferred method or using the command line.

Using Web Administration:

Expand Schema management in the navigation area and click Manage object classes.
A read-only panel is displayed that enables you to view the object classes in the schema and their characteristics. The object classes are displayed in alphabetical order. Use the table options to locate the object class that you want to view. See Using tables in the Web Administration Tool for information on how to use these options.
After you have located the object class that you want, we can view its type, required attributes, and optional attributes. Expand the drop-down menus for required attributes and optional attributes to see the full listings for each characteristic.
When the Web admin tool is used to access the admin daemon:

The status bar on the Manage object classes panel displays a message indicating that the tool is connected to the admin daemon. If you access panels that are not supported by admin daemon, a message is displayed indicating that the functions on the panels are not supported.
The Manage object classes panel is enabled based on the capabilities present in rootDSE for ibm-supportedcapabilities attribute.

To view additional information about the object class:

Select the object class.
Click View.

The View object class panel is displayed.
This panel has two tabs. The Formatted view tab supplies the object class name, description, OID, object class type, superior object classes, required attributes, required inherited attributes, optional attributes and optional inherited attributes. The information is displayed in a printable format. The Server view tab provides the information in the format used in the attribute file on the server.
When you are finished click Close to return to the Managing object classes panel.

Using the command line:

To view the object classes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* objectclasses
Adding an object class

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage object classes. To create a new object class:

Click Add.
We can also access this panel by expanding Schema management in the navigation area, and then clicking Add an object class.
At the General properties tab:

Enter the Object class name. This is a required field, and is descriptive of the function of the object class. For example, tempEmployee for an object class used to track temporary employees.
Enter a Description of the object class, for example, The object class used for temporary employees.
Enter the OID for the object class. This is a required field. See Object identifier (OID). If you do not have an OID, we can use the Object class name appended with oid. For example, if the object class name is tempEmployee, then the OID is tempEmployeeoid. We can change the value of this field.
Select one or more Superior object classes from the menu . This selection determines the object class or classes from which other attributes are inherited. Typically the Superior object classes is top, however, it can be another object class, or used in conjunction with other object classes. For example, a superior object classes for tempEmployee might be top and ePerson.
Select an Object class type. See Object class type for additional information about object class types.
Click the Attributes tab to specify the required and the optional attributes for the object class and view the inherited attributes, or click OK to add the new object class or click Cancel to return to Manage object classes without making any changes.

At the Attributes tab:

Select an attribute from the alphabetical list of Available attributes and click Add to required to make the attribute required or click Add to optional to make the attribute optional for the object class. The attribute is displayed in the appropriate list of selected attributes.
Repeat this process for all the attributes you want to select.
We can move an attribute from one list to another or delete the attribute from the selected lists by selecting it and clicking the appropriate Move to or Remove button.
We can view the lists of required and optional inherited attributes. Inherited attributes are based on the Superior object classes selected on the General tab. We cannot change the inherited attributes. However, if you change the Superior object classes on the General tab, a different set of inherited attributes is displayed.

Click OK to add the new object class or click Cancel to return to Manage object classes without making any changes.

If you clicked OK on the General tab without adding any attributes, we can add attributes by editing the new object class.

Using the command line:

To add an object class using the command line, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=Schema
changetype: modify
add: objectclasses
objectclasses: ( <myobjectClass-oid> NAME '<myObjectClass>' DESC '<An object class 
                 I defined for my LDAP application>' SUP '<objectclassinheritance>'
                 <objectclasstype> MUST (<attribute1> $ <attribute2>) 
                 MAY (<attribute3> $ <attribute4>) )
Editing an object class

Not all schema changes are allowed. See Disallowed schema changes for change restrictions.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage object classes. To edit an object class:

Click the radio button next to the object class that you want to edit.
Click Edit .
We can also open the Edit object class panel to edit attributes of an object class by clicking on the object class name in the Objectclass column.
Select a tab:

Use the General tab to:

Modify the Description.
Change the Superior object classes. Select one or more superior object classes from the menu . This determines the object class or classes from which other attributes are inherited. Typically the superior object class is top, however, it can be another object class, or used in conjunction with other object classes. For example, a superior object classes for tempEmployee might be top and ePerson.
Change the Object class type. Select an object class type. See Object class type for additional information about object class types.
Click the Attributes tab to change the required and the optional attributes for the object class and view the inherited attributes, or click OK to apply your changes or click Cancel to return to Manage object classes without making any changes.

Use the Attributes tab to:
Select an attribute from the alphabetical list of Available attributes and click Add to required to make the attribute required or click Add to optional to make the attribute optional for the object class. The attribute is displayed in the appropriate list of selected attributes.
Repeat this process for all the attributes you want to select.
We can move an attribute from one list to another or delete the attribute from the selected lists by selecting it and clicking the appropriate Move to or Remove button.
We can view the lists of required and optional inherited attributes. Inherited attributes are based on the superior object classes selected on the General tab. We cannot change the inherited attributes. However, if you change the Superior object classes on the General tab, a different set of inherited attributes is displayed.

Click OK to apply the changes or click Cancel to return to Manage object classes without making any changes.

Using the command line:

View the object classes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* objectclasses
To change an object class using the command line, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=schema
changetype: modify
replace: objectclasses
objectclasses: ( <myobjectClass-oid> NAME '<myObjectClass>' DESC '<An object class 
                 I defined for my LDAP application>' SUP '<newsuperiorclassobject>'
                 <newobjectclasstype> MUST (<attribute1> $ <attribute2>) 
                MAY (<attribute3> $ <attribute4>) )
Modify-replace requests directed at the "cn=schema" entry have a special behavior that is not true for other entries. Normally a modify-replace replaces all values of the specified attribute, with the set of new values specified in the modify operation. However, when applied to the schema, only the referenced value is replaced. If this was not the case, this example would replace the definition of "myObjectClass", but also delete the definitions of all other objectclasses. The same behavior is true for modify-replace operations to replace attributetypes values.

Copying an object class

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage object classes. To copy an object class:

Click the radio button next to the object class that you want to copy.
Click Copy.
Select a tab:

Use the General tab to:

Type the new object class name. For example, you might copy tempEmployee as tempEmployee2.
Modify the Description.
Type the new OID. See Object identifier (OID). If you do not have a registered OID for the object class you have copied, we can create one for your local use. For example, if your new object class is called tempEmployee2 you might use tempEmployee2oid as the OID.
Change the Superior object classes. Select one or more superior object classes from the menu . This determines the object class or classes from which other attributes are inherited. Typically the superior object class is top, however, it can be another object class, or used in conjunction with other object classes. For example, a superior object classes for tempPerson2 might be top and ePerson.
Change the Object class type. Select an object class type. See Object class type for additional information about object class types.
Click the Attributes tab to change the required and the optional attributes for the object class and view the inherited attributes, or click OK to apply your changes or click Cancel to return to Manage object classes without making any changes.

Use the Attributes tab to:
Select an attribute from the alphabetical list of Available attributes and click Add to required to make the attribute required or click Add to optional to make the attribute optional for the object class. The attribute is displayed in the appropriate list of selected attributes.
Repeat this process for all the attributes you want to select.
We can move an attribute from one list to another or delete the attribute from the selected lists by selecting it and clicking the appropriate Move to or Remove button.
We can view the lists of required and optional inherited attributes. Inherited attributes are based on the superior object classes selected on the General tab. We cannot change the inherited attributes. However, if you change the Superior object classes on the General tab, a different set of inherited attributes is displayed.

Click OK to apply the changes or click Cancel to return to Manage object classes without making any changes.

Using the command line:

View the object classes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* objectclasses
Select the object class that you want to copy. Use an editor to change the appropriate information and save the changes to <filename>. The issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=schema
changetype: modify
replace: objectclasses
objectclasses: ( <mynewobjectClass-oid> NAME '<mynewObjectClass>'
              DESC '<A new object class I copied for my LDAP application>'
              SUP '<superiorclassobject>'<objectclasstype>
              MUST (<attribute1> $ <attribute2>) 
              MAY (>attribute3> $ <attribute4> $ <attribute3>) )
Deleting an object class

Not all schema changes are allowed. See Disallowed schema changes for change restrictions.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage object classes. To delete an object class:

Click the radio button next to the object class that you want to delete.
Click Delete.
You are prompted to confirm deletion of the object class. Click OK to delete the object class or click Cancel to return to Manage object classes without making any changes.

Using the command line:

View the object classes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* objectclasses
Select the object class you want to delete and issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( <myobjectClass-oid> NAME '<myObjectClass>' 
           DESC '<An object class I defined for my LDAP application>'
           SUP '<objectclassinheritance>' <objectclasstype > 
           MUST (<attribute1> $ <attribute2>) > 
           MAY (<attribute3> $ <attribute4>) )
Working with attributes

Each directory entry has a set of attributes associated with it through it's object class. While the object class describes the type of information that an entry contains, the actual data is contained in attributes. An attribute is represented by one or more name-value-pairs that hold specific data element such as a name, an address, or a telephone number. The IBM Tivoli Directory Server represents data as name-value-pairs, a descriptive attribute, such as commonName (cn), and a specific piece of information, such as John Doe.
For example, the entry for John Doe might contain several attribute name-value-pairs.
dn: uid=jdoe, ou=people, ou=mycompany, c=us,
objectClass: top 
objectClass: person 
objectClass: organizationalPerson 
cn: John Doe 
sn: Doe 
givenName: Jack 
givenName: John
While the standard attributes are already defined in the schema file, you can create, edit, copy, or delete attributes to suit the needs of your organization.

The IBMAttributeTypes attribute type

The IBMAttributeTypes attribute can be used to define schema information not covered by the LDAP Version 3 standard for attributes. Values of IBMAttributeTypes must comply with the following grammar:
IBMAttributeTypesDescription = "(" whsp
        numericoid whsp
      [ "DBNAME"   qdescrs ]            ; at most 2 names (table, column)
      [ "ACCESS-CLASS" whsp IBMAccessClass whsp ]
      [ "LENGTH" wlen whsp ]            ; maximum length of attribute
      [ "EQUALITY"  whsp ]   ; create index for matching rule
      [ "ORDERING"  whsp ]   ; create index for matching rule
      [ "APPROX"    whsp ]   ; create index for matching rule
      [ "SUBSTR"    whsp ]   ; create index for matching rule
      [ "REVERSE"   whsp ]   ; reverse index for substring
      [ "ENCRYPT"  whsp scheme whsp ]   ; encryption scheme
      [ "SECURE-CONNECTION-ONLY"  whsp ] ; secure connection required
      [ "RETURN-VALUE whsp returnValue whsp ]; value to be returned
      [ "NONMATCHABLE whsp ] ;          ; attribute can only be used in existence filters
      whsp ")" 
     scheme =
	     "SSHA" /
	     "AES-128" /
	     "AES-192" /
	     "AES-256" 
    returnValue =
	     "encrypted" /
	     "type-only" 
   IBMAccessClass =
      "NORMAL"            / ; this is the default
      "SENSITIVE"         /
      "CRITICAL"          /
      "RESTRICTED"        /
      "SYSTEM"            /
Numericoid

Used to correlate the value in attributetypes with the value in IBMAttributeTypes.

DBNAME

We can provide two names at the most. The first is the table name used for this attribute. The second is the column name used for the fully normalized value of the attribute in the table. If you provide only one name, it is used as the table name as well as the column name. If you do not provide any DBNAMEs, then the short attribute name is used (from the attributetypes).

ACCESS-CLASS

Attributes requiring similar permissions for access are grouped together in classes. Attributes are mapped to their attribute classes in the directory schema file. These classes are discreet; access to one class does not imply access to another class. Permissions are set with regard to the attribute access class as a whole. The permissions set on a particular attribute class apply to all attributes within that access class unless individual attribute access permissions are specified.
IBM defines five attribute classes that are used in evaluation of access to user attributes: normal, sensitive, critical, system, and restricted. As examples, the attribute commonName belongs to the normal class, and the attribute userPassword belongs to the critical class. User defined attributes belong to the normal access class unless otherwise specified. See Rights for more information.
If ACCESS-CLASS is omitted, it defaults to normal.

LENGTH
The maximum length of this attribute. The length is expressed as the number of bytes. (IBM Tivoli Directory Server has a provision for increasing the length of an attribute.) In the attributetypes value, the string:
( attr-oid ... SYNTAX syntax-oid{len} ... )
can be used to indicate that the attributetype with oid attr-oid has a maximum length.
If the length of an attribute needs to be reduced, see Manual procedure for changing existing attributes.
EQUALITY, ORDERING, APPROX, SUBSTR, REVERSE

If any of these attributes are used, an index is created for the corresponding matching rule. For good search performance, an EQUALITY index should be specified for any attribute that will be used in search filters.
Equality matching rules

A matching rule provides guidelines for string comparison during a search operation. These rules are divided into three categories:

Equality
Ordering
Substring

Table 1.

Equality matching rules
Matching Rule OID Syntax

bitStringMatch 2.5.13.16 Bit String
booleanMatch 2.5.13.13 Boolean
caseExactIA5Match 1.3.6.1.4.1.1466.109.114.1 Directory String syntax
caseExactMatch 2.5.13.5 Directory String syntax
caseIgnoreIA5Match 1.3.6.1.4.1.1466.109.114.2 IA5 String syntax
caseIgnoreListMatch 2.5.13.11 Directory String
caseIgnoreMatch 2.5.13.2 Directory String syntax
distinguishedNameMatch 2.5.13.1 DN - distinguished name
generalizedTimeMatch 2.5.13.27 Generalized Time syntax
ibm-entryUuidMatch 1.3.18.0.2.22.2 Directory String syntax
integerFirstComponentMatch 2.5.13.29 Integer syntax - integral number
integerMatch 2.5.13.14 Integer syntax - integral number
numericStringMatch 2.5.13.8 Numeric String
objectIdentifierFirstComponentMatch 2.5.13.30 String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.).
objectIdentifierMatch 2.5.13.0 String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.)
octetStringMatch 2.5.13.17 Directory String syntax
presentationAddressMatch 2.5.13.22 Presentation Address
protocolInformationMatch 2.5.13.24 Protocol Information
telephoneNumberMatch 2.5.13.20 Telephone Number syntax
uniqueMemberMatch 2.5.13.23 Name And Optional UID
uTCTimeMatch 2.5.13.25 UTC Time syntax

Table 2.

Ordering matching rules
Matching rule OID Syntax

caseExactOrderingMatch 2.5.13.6 Directory String syntax
caseIgnoreOrderingMatch 2.5.13.3 Directory String syntax
distinguishedNameOrderingMatch 1.3.18.0.2.4.405 DN - distinguished name
generalizedTimeOrderingMatch 2.5.13.28 Generalized Time syntax
integerOrderingMatch 2.5.13.15 Integer
numericStringOrderingMatch 2.5.13.9 Numeric String
octetStringOrderingMatch 2.5.13.18 Octet String

Table 3.

Substring matching rules
Matching rule OID Syntax

caseExactSubstringsMatch 2.5.13.7 Directory String syntax
caseIgnoreListSubstringsMatch 2.5.13.12 Substring Assertion
caseIgnoreSubstringsMatch 2.5.13.4 Directory String syntax
numericStringSubstringsMatch 2.5.13.10 Substring Assertion
telephoneNumberSubstringsMatch 2.5.13.21 Telephone Number syntax

UTC-Time is time string format defined by ASN.1 standards. See ISO 8601 and X680. Use this syntax for storing time values in UTC-Time format. uTCTimeMatch is a deprecated matching rule. Use generalizedTimeMach instead. See Generalized and UTC time.

Indexing rules

Index rules attached to attributes make it possible to retrieve information faster. If only the attribute is given, no indexes are maintained. IBM Directory provides the following indexing rules:

Equality
Ordering
Approximate
Substring
Reverse

Indexing rules specifications for attributes:

Specifying an indexing rule for an attribute controls the creation and maintenance of special indexes on the attribute values. This greatly improves the response time to searches with filters which include those attributes. The five possible types of indexing rules are related to the operations applied in the search filter.
Equality
Applies to the following search operations:

equalityMatch '='
For example:
"cn = John Doe" 
Ordering
Applies to the following search operation:

greaterOrEqual '>='
lessOrEqual '<='
For example:
"sn >= Doe"
Approximate
Applies to the following search operation:

approxMatch '~='
For example:
"sn ~= doe"
Substring
Applies to the search operation using the substring syntax:

substring '*'
For example:
"sn = McC*" "cn = J*Doe"
Reverse
Applies to the following search operation:

'*' substring
For example:
"sn = *baugh"
At a minimum, it is recommended that you specify equality indexing on any attributes that are to be used in search filters.

Viewing attributes

We can view the attributes in the schema using either the Web Administration Tool, the preferred method or using the command line.

Using Web Administration:

Expand Schema management in the navigation area and click Manage attributes. A read-only panel is displayed that enables you to view the attributes in the schema and their characteristics. The attributes are displayed in alphabetical order. Use the table options to locate the attribute that you want to view. See Using tables in the Web Administration Tool for information on how to use these options.

When the Web admin tool is used to access the admin daemon:

The status bar on the Manage attributes panel displays a message indicating that the tool is connected to the admin daemon. If you access panels that are not supported by admin daemon, a message is displayed indicating that the functions on the panels are not supported.
The Manage attributes panel is enabled based on the capabilities present in rootDSE for ibm-supportedcapabilities attribute.

After you have located the attribute that you want, we can view its syntax, whether it is multi-valued, and the object classes that contain it. Expand the drop-down menu for object classes to see the list of object classes for the attribute.
To view additional information about the attribute:

Select the attribute.
Click View.

The View attributes panel is displayed.
This panel has two tabs. The Formatted view tab supplies the attribute name, description, OID, superior attribute, syntax, attribute length, multiple values enabled status, matching rules, IBM extensions, and indexing rules. The information is displayed in a printable format. The Server view tab provides the information in the format used in the attribute file on the server.
When you are finished click Close to return to the IBM Tivoli Directory Server Manage attributes panel.

Using the command line:

To view the attributes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* attributeTypes IBMAttributeTypes
Adding an attribute

Use either of the following methods to create a new attribute. The Web Administration Tool is the preferred method.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage attributes. To create a new attribute:

Click Add.

We can also access this panel by expanding Schema management in the navigation area, then click Add an attribute.
Enter the Attribute name, for example, tempId. This is a required field and must begin with an alphabetical character.
Enter a Description of the attribute, for example, The ID number assigned to a temporary employee.
Enter the OID for the attribute. This is a required field. See Object identifier (OID). If you do not have a registered OID, we can use the attribute name appended with oid. For example, if the attribute name is tempID, then the OID is tempIDoid. We can change the value of this field.
Select a Superior attribute from the drop-down list. The superior attribute determines the attribute from which properties are inherited.
Select a Syntax from the drop-down list. See Attribute syntax for additional information about syntax.
Enter an Attribute length that specifies the maximum length of this attribute. The length is expressed as the number of bytes. The default value is 240.
Select the Allow multiple values check box to enable the attribute to have multiple values. See the glossary entry *** for additional information about multiple values.
Select a matching rule from each of the drop-down menus for equality, ordering, and substring matching rules. See the Equality matching rules for a complete listing of matching rules.
Click the IBM extensions tab to specify additional extensions for the attribute, or click OK to add the new attribute or click Cancel to return to Manage attributes without making any changes.
At the IBM extensions tab:

Enter the DB2® table name . This table name can be up to 128 bytes in length without truncating. The server generates the DB2 table name if this field is left blank. If you enter a DB2 table name, also enter a DB2 column name. For servers with version earlier than IBM Tivoli Directory Server version 6.0, the length is restricted to 16 bytes without truncating.
Modify the DB2 column name. The server generates the DB2 column name if this field is left blank. If you enter a DB2 column name, also enter a DB2 table name. This column name can be up to 16 bytes in length without truncating.
Set the Security class by selecting normal, sensitive, or critical from the drop-down list. See the Security class section under *** for information about security classes.
Set the Indexing rules by selecting one or more indexing rules. See Indexing rules for additional information about indexing rules.

At a minimum, it is recommended that you specify Equality indexing on any attributes that are to be used in search filters.
Select an encryption scheme from the Select encryption scheme box.
Select a search return type for the attribute value from the Value to return on search box.
Select the Require secure connection to view or change values check box to specify secure connection when accessing encrypted attributes.
Select the Allow attribute in search filters check box to specify whether the attributes are allowed in search filter.

Click OK to add the new attribute or click Cancel to return to Manage attributes without making any changes.

If you clicked OK on the General tab without adding any extensions, we can add extensions by editing the new attribute.

Using the command line:

The following example adds an attribute type definition for an attribute called "myAttribute", with Directory String syntax (see Attribute syntax) and Case Ignore Equality matching (see Equality matching rules). The IBM-specific part of the definition says that the attribute data is stored in a column named "myAttrColumn" in a table called "myAttrTable". If these names were not specified, both the column and table name would have defaulted to "myAttribute". The attribute is assigned to the "normal" access class, and values have a maximum length of 200 bytes.
idsldapmodify -D <admindn> -w <adminpw> -i myschema.ldif
where the myschema.ldif file contains:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( myAttribute-oid NAME ( 'myAttribute' ) 
                 DESC 'An attribute I defined for my LDAP application' 
                 EQUALITY 2.5.13.2 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
                 {200} USAGE userApplications )
-
add: ibmattributetypes
ibmattributetypes: ( myAttribute-oid  DBNAME ( 'myAttrTable' 'myAttrColumn' ) 
                    ACCESS-CLASS normal LENGTH 200 )
In this example, there are two locations where "length" can be specified. In this example, 200 is the specified length. For example:

{200} USAGE userApplications )
ACCESS-CLASS normal LENGTH 200 )
Both of these pieces of code demonstrate how to specify length. If length is specified in either of these locations, then they both must match..
See the idsldapmodify and idsldapadd command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.

Editing an attribute

Not all schema changes are allowed. See Disallowed schema changes for change restrictions.
Any part of a definition can be changed before you have added entries that use the attribute. After you have added entries that use the attribute, you can use the edit procedure to change the indexing rules and to increase the size of the attribute length. We can also change to enable multiple values.

We can disable multiple values only if the existing entries are single-valued. We cannot disable the multi-value option if any of the existing entries are multi-valued.
Use either of the following methods to edit an attribute. The Web Administration Tool is the preferred method.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage attributes. To edit an attribute:

Click the radio button next to the attribute that you want to edit.
Click Edit .

We can also open the Edit attribute panel to edit an attribute by clicking on the attribute name in the Name column.
Select a tab:

Use the General tab to:

Select a tab, either:

General to:

Modify the Description.
Change the Superior attribute.
Change the Syntax.
Set the Attribute length.

We can only increase the size of the attribute length. If we need to reduce the size of the attribute length, perform additional steps before editing the attribute. See Manual procedure for changing existing attributes.
Change the Multiple value settings.
Select a Matching rule.

Click the IBM extensions tab to edit the extensions for the attribute, or click OK to apply your changes or click Cancel to return to Manage attributes without making any changes.
IBM extensions (if you are connected to anIBM Tivoli Directory Server) to:

Change the Security class.

You cannot change the security class of attributes that have a security classification of system or restricted.
Change the Indexing rules.

Click OK to apply your changes or click Cancel to return to Manage attributes without making any changes.

When you are finished editing the attributes, click Close to return to Introduction panel.

Using the command line:

This example adds indexing to the attribute, so that searching on it is faster. Use the idsldapmodify command and the LDIF file to change the definition.

We can only increase the size of the attribute length. If we need to reduce the size of the attribute length, perform additional steps before editing the attribute. See Manual procedure for changing existing attributes.
idsldapmodify -D <admindn> -w <adminpw> -i myschemachange.ldif
Where the myschemachange.ldif file contains:
dn: cn=schema
changetype: modify
replace: attributetypes
attributetypes: ( myAttribute-oid NAME ( 'myAttribute' ) DESC 'An attribute 
                 I defined for my LDAP application' EQUALITY 2.5.13.2 
                 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 {200} USAGE userApplications )
-
replace: ibmattributetypes
ibmattributetypes: ( myAttribute-oid  DBNAME ( 'myAttrTable' 'myAttrColumn' ) 
                  ACCESS-CLASS normal LENGTH 200 EQUALITY SUBSTR )
Both portions of the definition (attributetypes and ibmattributetypes) must be included in the replace operation, even though only the ibmattributetypes section is changing. The only change is adding "EQUALITY SUBSTR" to the end of the definition to request indexes for equality and substring matching.
See the idsldapadd command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information about this utility.

Manual procedure for changing existing attributes

If an attribute definition needs to be changed and the table has already been populated for this attribute, perform the following operations:
Use the idsdb2ldif utility to export the directory data into an LDIF file.
Unconfigure the database.
idsucfgdb  -I <instance_name> -r 
Change the attribute definition in the schema file. See Editing an attribute.
Configure the database.
Use either the idsldif2db or the idsbulkload utility to import the data into the database.
Copying an attribute

Use either of the following methods to copy an attribute. The Web Administration Tool is the preferred method.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage attributes. To copy an attribute:

Click the radio button next to the attribute that you want to copy.
Click Copy.
Type the name of the new attribute in the Attribute name field. For example, you might copy tempID as tempID2.
Modify a Description of the attribute, for example, The ID number assigned to a temporary employee.
Type the new OID. See Object identifier (OID). If you do not have a registered OID for the attribute you have copied, we can create one for your local use. For example, if your new attribute is calledtempID2 you might use tempID2oid as the OID.
Select a Superior attribute from the drop-down list. The superior attribute determines the attribute from which properties are inherited.
Select a Syntax from the drop-down list. See Attribute syntax for additional information about syntax.
Enter a Attribute length that specifies the maximum length of this attribute. The length is expressed as the number of bytes.
Select the Allow multiple values check box to enable the attribute to have multiple values. See the glossary entry *** for additional information about multiple values.
Select a matching rule from the each of the drop-down menus for equality, ordering, and substring matching rules. See the Equality matching rules for a complete listing of matching rules.
Click the IBM extensions tab to modify additional extensions for the attribute, or click OK to apply your changes or click Cancel to return to Manage attributes without making any changes.
At the IBM extensions tab:

Enter the DB2 table name . This table name can be up to 128 bytes in length without truncating. The server generates the DB2 table name if this field is left blank. If you enter a DB2 table name, also enter a DB2 column name. For servers with version earlier than IBM Tivoli Directory Server version 6.0, the length is restricted to 16 bytes without truncating.
Enter the DB2 column name. This column name can be up to 16 bytes in length without truncating. The server generates the DB2 column name if this field is left blank. If you enter a DB2 column name, also enter a DB2 table name.
Modify the Security class by selecting normal, sensitive, or critical from the drop-down list.

We cannot change the security class of attributes that have a security classification of system or restricted.
Modify the Indexing rules by selecting one or more indexing rules. See Indexing rules for additional information about indexing rules.

At a minimum, it is recommended that you specify Equal indexing on any attributes that are to be used in search filters.

Click OK to apply your changes or click Cancel to return to Manage attributes without making any changes.

If you clicked OK on the General tab without adding any extensions, we can add or modify extensions by editing the new attribute.

Using the command line:

View the attributes contained in the schema issue the command:
idsldapsearch -b cn=schema -s base objectclass=* attributeTypes IBMAttributeTypes
Select the attribute that you want to copy. Use an editor to change the appropriate information and save the changes to <filename>. Then issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( <mynewAttribute-oid> NAME '<mynewAttribute>' DESC '<A new 
                 attribute I copied for my LDAP application> EQUALITY 2.5.13.2 
                 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 {200} USAGE userApplications )
-
add: ibmattributetypes
ibmattributetypes: ( myAttribute-oid  DBNAME ( 'myAttrTable' 'myAttrColumn' ) 
                    ACCESS-CLASS normal LENGTH 200 )
Deleting an attribute

Not all schema changes are allowed. See Disallowed schema changes for change restrictions.
Use either of the following methods to delete an attribute. The Web Administration Tool is the preferred method.

Using Web Administration:

If you have not done so already, expand Schema management in the navigation area, then click Manage attributes. To delete an attribute:

Click the radio button next to the attribute that you want to delete.
Click Delete.
You are prompted to confirm deletion of the attribute. Click OK to delete the attribute or click Cancel to return to Manage attributes without making any changes.

Using the command line:
idsldapmodify -D <admindn> -w <adminpw> -i myschemadelete.ldif
Where the myschemadelete.ldif file includes:
dn: cn=schema
changetype: modify
delete: attributetypes
attributetypes: ( myAttribute-oid  )
-
delete: ibmattributetypes
ibmattributetypes: ( myAttribute-oid )
See the idsldapadd command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.

Encrypted Attributes

Local Administrative group members who are assigned DirDataAdmin and SchemaAdmin roles can specify attributes that are to be encrypted in the directory database using a subset of the encryption schemes supported for password information. The attributes can be encrypted using either 2-way or 1-way encryption schemes. The supported encryption schemes include AES-256, AES-192, AES-128, and SSHA and the supported attribute syntaxes include directory string, IA5 string, distinguished name, and telephone number.
The encrypted attribute policy will allow local admin group members who are assigned DirDataAdmin and SchemaAdmin roles to specify access to encrypted attributes that will be limited to clients that use secure connections. Furthermore, the policy will allow group members to define specific attributes as being non-matchable. This means that such attributes can only be used in presence filters. Additionally, the policy also allows group members to specify if values to be returned on a search should be encrypted or if only attribute names should be returned.

Search filter assertions for encrypted attributes can be exact match or presence. Substring matches, ordering, and approximate matching cannot be used.
After specifying the attributes that are to be encrypted, the existing server data will be encrypted only after the next server startup. The time taken for this operation will depend on the number of entries that are to be encrypted. The encrypted attribute policy can be managed using the web administration tool.

Using Web Administration

If you have not done so already, expand Schema management in the navigation area and click Manage encrypted attributes.
The Manage encrypted attributes tab provides a way to manage encrypted attributes. Users can use this tab to manage and add existing encryptable attributes to encrypted attributes.
The Manage encrypted attributes tab will be available only if the server supports ibm-supportedcapability OID for encrypted attribute and returns the OID on rootDSE search.
To manage encryptable attributes:

To encrypt attributes, select the required encryptable attributes from the Select attribute list in the Attributes available for encryption section.
Select an encryption scheme from the Select encryption scheme box.
Select a search return type for the attribute value from the Value to return on search box.
Select the Require secure connection to view or change values check box to enable secure connection when accessing encrypted attributes.
Select the Allow attributes in search filters check box to specify whether the selected encryptable attributes are allowed in search filter.
Click the Add to encrypted button to populate the Encrypted attributes table with the selected encryptable attributes from the Select attribute box.
When you are finished, do one of the following:

Click OK to apply your changes and exit this panel.
Click Cancel to exit this panel without making any changes.

To manage encrypted attributes:

To remove an attribute from the Encrypted attributes table, click the Select column of the required encrypted attribute, and then click the Remove button or select Remove from the Select Action box and click Go.
To edit the encryption settings for an attribute, click the Select column of the required encrypted attribute, and then click the Edit encryption settings button or select Edit encryption settings from the Select Action box and click Go.
To remove all the attributes from the Encrypted attributes table, click the Remove all button or select Remove all from the Select Action box and click Go.
When you are finished, do one of the following:

Click OK to apply your changes and exit this panel.
Click Cancel to exit this panel without making any changes.

Edit encryption settings

This Edit encryption settings panel contains settings that are used for specifying and modifying the existing values of the encrypted attributes such as encryption type, search return type, type of connection for accessing attributes, and search filter.
To edit encrypted attributes:

Select an encryption scheme from the Select encryption scheme box.
Select a search return type for the attribute value from the Value to return on search box.
Select the Required secure connection to view or change values check box to enable secure connection when accessing the encrypted attribute.
Select the Allow attributes in search filters check box to specify whether the selected encrypted attribute is allowed in search filter.
When you are finished, do one of the following:

Click OK to save the changes made to the encrypted attribute values in the directory schema.
Click Cancel to exit this panel without making any changes.

Encrypted attributes in a replication environment

During replication it is ensured that attributes are replicated over secure connections. The replication process also determines if any incompatible features are used between the supplier and the consumer. For instance, if the supplier has encrypted attributes while the consumer does not support encryption, then the replication process will not start. Also, if the network includes servers running at earlier releases, such as TDS version 6.0, replicated schema changes will fail.
It is recommended that servers share a crypto key, and that the administrator ensure that attributes are encrypted on all servers. If the crypto keys differ between supplier and consumer, changes will be decoded and replicated as clear text.

Using command line

To encrypt an attribute, say for instance the uid attribute using the AES encryption scheme, issue the following command:
ldapmodify -D <adminDN> -w <adminPW>
dn: cn=schema
changetype: modify
replace: attributetypes
attributetypes:( 0.9.2342.19200300.100.1.1 NAME 'uid' DESC 'Typically a user shortname or userid.' 
EQUALITY 1.3.6.1.4.1.1466.109.114.2 ORDERING 2.5.13.3 SUBSTR 2.5.13.4 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) 
-
replace: IBMAttributetypes
IBMAttributetypes:( 0.9.2342.19200300.100.1.1 DBNAME( 'uid'  'uid' ) 
ACCESS-CLASS normal LENGTH 256 EQUALITY ORDERING SUBSTR APPROX 
ENCRYPT AES256 SECURE-CONNECTION-REQUIRED  RETURN-VALUE  encrypted)) 
Attribute syntax

Attribute syntax identifies the required format of the data.
Table 4.

Syntax OID

Attribute Type Description syntax 1.3.6.1.4.1.1466.115.121.1.3
Binary - octet string 1.3.6.1.4.1.1466.115.121.1.5
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean - TRUE/FALSE 1.3.6.1.4.1.1466.115.121.1.7
Certificate 1.3.6.1.4.1.1466.115.121.1.8
Certificate List 1.3.6.1.4.1.1466.115.121.1.9
Certificate Pair 1.3.6.1.4.1.1466.115.121.1.10
Country String 1.3.6.1.4.1.1466.115.121.1.11
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String syntax 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description syntax 1.3.6.1.4.1.1466.115.121.1.16
DITStructure Rule Description syntax 1.3.6.1.4.1.1466.115.121.1.17
DN - distinguished name 1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time syntax 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String syntax 1.3.6.1.4.1.1466.115.121.1.26
IBM Attribute Type Description 1.3.18.0.2.8.1
Integer syntax - integral number 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description syntax 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
MHS OR Address 1.3.6.1.4.1.1466.115.121.1.33
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description syntax 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Presentation Address 1.3.6.1.4.1.1466.115.121.1.43
Protocol Information 1.3.6.1.4.1.1466.115.121.1.42
Printable String 1.3.6.1.4.1.1466.115.121.1.44
String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.). See Object identifier (OID). 1.3.6.1.4.1.1466.115.121.1.38
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Supported Algorithm 1.3.6.1.4.1.1466.115.121.1.49
Telephone Number syntax 1.3.6.1.4.1.1466.115.121.1.50
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
UTC Time syntax. UTC-Time is time string format defined by ASN.1 standards. See ISO 8601 and X680. Use this syntax for storing time values in UTC-Time format. See Generalized and UTC time. 1.3.6.1.4.1.1466.115.121.1.53

Managing unique attributes

The Unique Attributes feature ensures that specified attributes always have unique values within a directory. These attributes can be specified in two entries only, cn=uniqueattributes,cn=localhost and cn=uniqueattributes,cn=IBMpolicies. The values for a unique attribute are stored on the server where the attribute has been designated as unique. Search results for unique attributes are unique for that server's database only. Search results that include results from referrals might not be unique.

Binary attributes, operational attributes, configuration attributes, and the objectclass attribute cannot be designated as unique.

Creating unique attributes

On a per attribute basis, language tags are mutually exclusive with unique attributes. If you designate a particular attribute as being a unique attribute, it cannot have language tags associated with it.
Using Web Administration:

Expand the Server administration category in the navigation area. Click Manage unique attributes.

Select the attribute that you want to add as a unique attribute from the Available attributes menu. The available attributes listed are those that can be designated as unique. For example, sn.

An attribute remains in the list of available attributes until it has been placed in both the cn=localhost and the cn=IBMpolicies containers.
Click either Add to cn=localhost or Add to cn=IBMpolicies. The difference between these two containers is that cn=IBMpolicies entries are replicated and cn=localhost entries are not. The attribute is displayed in the appropriate list box. We can list the same attribute in both containers.

If an entry is created under both cn=localhost and cn=IBMpolicies, the resultant union of these two entries is the consolidation of their unique attributes list. For example, if the attributes cn and employeeNumber are designated as unique in cn=localhost and the attributes cn and telephoneNumber are designated as unique on cn=IBMploicies, the server treats the attributes cn, employeeNumber, and telephoneNumber as unique attributes.
Repeat this process for each attribute you want to add to the attribute cache.
Click OK to save your changes or click Cancel to exit this panel without making any changes.

Using the command line:

To designate that an attribute must have unique values, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=uniqueattributes,cn=localhost
changetype: add
ibm-UniqueAttributeTypes:  sn
objectclass: top
objectclass: ibm-UniqueAttributeTypes
To add additional attributes, issue the command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=uniqueattributes,cn=localhost
cn: uniqueattributes
changetype: modify
add: ibm-UniqueAttributeTypes
ibm-UniqueAttributeTypes:  AIXAdminUserId 
-
add: ibm-UniqueAttributeTypes
ibm-UniqueAttributeTypes:  adminGroupNames
When adding or modifying a unique attribute entry, if establishing a unique constraint for any of the listed unique attribute types results in errors, the entry is not added or created in the directory. The problem must be resolved and the command to add or modify must be reissued before the entry can be created or modified. For example, while adding a unique attribute entry to the directory, if establishing a unique constraint on a table for one of the listed unique attribute types failed (that is, because of having duplicate values in the database), a unique attribute entry is not added to the directory. An error DSA is unwilling to perform is issued.

If an entry is created under both cn=localhost and cn=IBMpolicies, the resultant union of these two entries is the consolidation of their unique attributes list. For example, if the attributes cn and employeeNumber are designated as unique in cn=localhost and the attributes cn and telephoneNumber are designated as unique on cn=IBMploicies, the server treats the attributes cn, employeeNumber, and telephoneNumber as unique attributes.
When an application tries to add an entry to the directory with a value for the attribute that duplicates an existing directory entry, an error with result code 20 (LDAP: error code 20 - Attribute or Value Exists) from the LDAP server is issued.
When the server starts, it checks the list of unique attributes and determines if the DB2 constraints exist for each of them. If the constraint does not exist for an attribute because it was removed by the idsbulkload utility or because it was removed manually by the user, it is removed from the unique attributes list and an error message is logged in the error log, ibmslapd.log. For example, if the attribute cn is designated as unique in cn=uniqueattributes,cn=localhost and there is no DB2 constraint for it the following message is logged:
Values for the attribute CN are not unique.  
The attribute CN was removed from the unique attribute 
entry: CN=UNIQUEATTRIBUTES,CN=LOCALHOST
Removing an attribute from the list of unique attributes

To remove an attribute from the list of unique attributes, use either of the following methods.

If a unique attribute exists in both cn=uniqueattributes,cn=localhost and cn=uniqueattributes,cn=IBMpolicies and it is removed from only one entry, the server continues to treat that attribute as a unique attribute. The attribute become nonunique when it has been removed from both entries.
Using Web Administration:

Expand the Server administration category in the navigation area. Click Manage unique attributes.

Select the attribute that you want to remove from the unique attributes list by clicking the attribute in the appropriate list box. For example AIXAdminUserId from the previous task.
Click Remove.
Repeat this process for each attribute you want to remove from the list.
Click OK to save your changes or click Cancel to exit this panel without making any changes.

If you remove the last unique attribute from the cn=localhost or the cn=IBMpolicies list boxes, the container entry for that list box, cn=uniqueattributes,cn=localhost or cn=uniqueattributes,cn=IBMpolicies is automatically deleted.
Using the command line:

To remove an attribute from the list of unique attributes using the command line, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=uniqueattributes,cn=localhost
changetype: modify
cn: uniqueattributes
ibm-UniqueAttributeTypes:  AIXAdminUserId
To remove all of the unique attributes stored in, for example, cn=localhost issue the command:
idsldapdelete -D <adminDN> -w <Adminpw> "cn=uniqueattributes,cn=localhost"
By deleting this unique attributes entry from the directory, the unique constraints enforced on the unique attributes are dropped to allow nonunique values for the attributes again.

The subschema entries

There is one subschema entry per server. All entries in the directory have an implied subschemaSubentry attribute type. The value of the subschemaSubentry attribute type is the DN of the subschema entry that corresponds to the entry. All entries under the same server share the same subschema entry, and their subschemaSubentry attribute type has the same value. The subschema entry has the hardcoded DN 'cn=schema'.
The subschema entry belongs to the object classes 'top', 'subschema', and 'IBMsubschema'. The 'IBMsubschema' object class has no MUST attributes and one MAY attribute type ('IBMattributeTypes').

The IBMsubschema object class

The IBMsubschema object class is used only in the subschema entry as follows:
( <objectClass-oid-TBD> NAME 'IBMsubschema' AUXILIARY
     MAY IBMattributeTypes )
Schema queries

The ldap_search() API can be used to query the subschema entry, as shown in the following example:
DN           : "cn=schema"    
search scope : base    
filter       : objectclass=subschema or objectclass=*
This example retrieves the full schema. To retrieve all of the values of selected attribute types, use the attrs parameter in ldap_search. We cannot retrieve only a specific value of a specific attribute type.
See the IBM Directory Version 6.1: Client SDK Programming Reference for more information about the ldap_search API.

Dynamic schema

To perform a dynamic schema change, use the ldap_modify API with a DN of "cn=schema". It is permissible to add, delete, or replace only one schema entity (for example, an attribute type or an object class) at a time.
To delete a schema entity, provide the oid in parentheses:
 ( oid )
We can also provide a full description. In either case, the matching rule used to find the schema entity to delete is objectIdentifierFirstComponentMatch.
To add or replace a schema entity, you MUST provide a LDAP Version 3 definition and you MAY provide the IBM definition. In all cases, provide only the definition or definitions of the schema entity that you want to affect.
For example, to delete the attribute type 'cn' (its OID is 2.5.4.3), use ldap_modify() with:
   LDAPMod  attr;    LDAPMod *attrs[] = { &attr, NULL };    char    *vals [] = { "( 2.5.4.3 )", NULL };    attr.mod_op      = LDAP_MOD_DELETE;    attr.mod_type    = "attributeTypes";    attr.mod_values  = vals;    ldap_modify_s(ldap_session_handle, "cn=schema", attrs);
To add a new attribute type bar with OID 20.20.20 that has a NAME of length 20 chars:
char    *vals1[] = { "( 20.20.20 NAME 'bar' SUP NAME )", NULL };    char    *vals2[] = { "( 20.20.20 LENGTH 20 )", NULL };    LDAPMod  attr1;    LDAPMod  attr2;    LDAPMod *attrs[] = { &attr1, &attr2, NULL };    attr1.mod_op = LDAP_MOD_ADD;    attr1.mod_type = "attributeTypes";    attr1.mod_values = vals1;    attr2.mod_op = LDAP_MOD_ADD;    attr2.mod_type = "IBMattributeTypes";    attr2.mod_values = vals2;    ldap_modify_s(ldap_session_handle, "cn=schema", attrs);
We cannot change the ACCESS-CLASS type to or from "system" or "restricted".
See Working with attributes for examples using the Web Administration Tool and the idsldapmodify command.
See the IBM Directory Version 6.1: Client SDK Programming Reference for more information about the ldap_modify API.

Access controls

Dynamic schema changes can be performed only by a replication supplier, the server administrator or a member of an administrator group.

Replication

Schema replication needs to be explicitly setup on cn=ibmpolicies to have the changes under cn=schema replicated to the specified replicationAgreements. In previous releases, schema changes were propagated to all the agreements mentioned in the directory server. However, for IBM Tivoli Directory Server versions 6.0 and above schema changes are propagated only to those agreements, that occur below cn=ibmpolicies and to no other agreements occurring in the Directory Information Tree (DIT).
When a dynamic schema change is performed, it is replicated just like any other ldap_modify operation. See Replicating schema and password policy updates.
See Replication for more additional information.

Disallowed schema changes

Not all schema changes are allowed. Change restrictions include the following:

Any change to the schema must leave the schema in a consistent state.
An attribute type that is a supertype of another attribute type may not be deleted. An attribute type that is a "MAY" or a "MUST" attribute type of an object class may not be deleted.
An object class that is a superclass of another may not be deleted.
Attribute types or object classes that refer to nonexisting entities (for example, syntaxes or object classes) cannot be added.
Attribute types or object classes cannot be modified in such a way that they end up referring to nonexisting entities (for example, syntaxes or object classes).

Changes to the schema that affect the operation of the server are not allowed. The following schema definitions are required by the directory server. They must not be changed.

Object classes

The following object class definitions must not be modified:

accessGroup
accessRole
alias
referral
replicaObject
top
ibm-slapdPwdPolicyAdmin
ibm-pwdPolicyExt
pwdPolicy

Attributes

The following attribute definitions must not be modified:

Operational attributes

There are attributes that have special meaning to the directory server, known as operational attributes. These are attributes that are maintained by the server, and either reflect information the server manages about an entry, or affect server operation. These attributes have special characteristics:

The attributes are not returned by a search operation unless they are specifically requested (by name) in the search request.
These attributes cannot be deleted.
The attributes are not part of any object class. The server controls what entries have the attributes.

The following lists of operational attributes are supported by the IBM Tivoli Directory Server:

aclEntry
aclPropagate
aclSource
aliasedObjectName, aliasedentryName
createTimestamp
creatorsName
entryOwner
hasSubordinates
ibm-allGroups
ibm-allMembers
ibm-capabilitiessubentry
ibm-effectiveAcl
ibm-entryChecksum
ibm-entryChecksumOp
ibm-entryUuid
ibm-filterAclEntry
ibm-filterAclInherit
ibm-pwdAccountLocked
ibm-replicationChangeLDIF
ibm-replicationFailedChangeCount
ibm-replicationFailedChanges
ibm-replicationIsQuiesced
ibm-replicationLastActivationTime
ibm-replicationLastChangeId
ibm-replicationLastFinishTime
ibm-replicationLastGlobalChangeId
ibm-replicationLastResult
ibm-replicationLastResultAdditional
ibm-replicationNextTime
ibm-replicationPendingChangeCount
ibm-replicationPendingChanges
ibm-replicationperformance
ibm-replicationState
ibm-replicationThisServerIsMaster
ibm-searchSizeLimit
ibm-searchTimeLimit
ibm-slapdCryptoSalt
modifiersName
modifyTimestamp
numSubordinates
ownerPropagate
ownerSource
pwdAccountLockedTime
pwdChangedTime
pwdExpirationWarned
pwdFailureTime
pwdGraceUseTime
pwdHistory
pwdReset
subschemaSubentry
subtreeSpecification

See Appendix I. Required attribute definitions for IBM Tivoli Directory Server version 6.0 and above for more information about these attributes.
A special attribute description, "+", can be used in the attribute list of a search request to return all operational attributes. If a "+" is present in the search request, the server returns all operational attributes to which the client is authorized. For further information, see the idsldapsearch command information in the IBM Tivoli Directory Server version 6.1 Command Reference.
Given below is a table that lists the supported special attributes, and the associated list of operational attributes:
Table 5. Supported special attributes and associated list of operational attributes

Attribute Attributes returned by "+" attribute Attributes added by ++

+ Returns all attributes listed in this column. ++ returns all attributes listed in this column
+ibmaci
aclentry
aclsource
aclpropagate
entryowner
ownersource
ownerpropagate
ibm-filterAclEntry
ibm-filterAclInherit
ibm-effectiveAcl

+ibmentry
creatorsname
createtimestamp
modifiersname
modifytimestamp
subschemasubentry
ibm-entryuuid
ibm-capabilitiessubentry
ibm-enabledcapabilities (1)
ibm-supportedcapabilities (1)
ibm-replicationThisServerIsMaster
ibm-replicationIsQuiesced

++ibmentry includes the attributes from +ibmentry and adds:
ibm-allgroups
ibm-allmembers
ibm-entryChecksum
ibm-entryChecksumOp
numsubordinates
hassubordinates
+ibmpwdpolicy
pwdAccountLockedTime
pwdChangedTime
pwdExpirationWarned
pwdFailureTime
pwdGraceUseTime
pwdHistory
pwdReset
ibm-pwdAccountLocked
ibm-pwdGroupPolicyDN
ibm-pwdIndividualPolicyDN

+ibmrepl
ibm-replicationChangeLDIF
ibm-replicationLastActivationTime
ibm-replicationLastChangeId
ibm-replicationLastFinishTime
ibm-replicationLastResult
ibm-replicationLastResultAdditional
ibm-replicationNextTime
ibm-replicationPendingChangeCount
ibm-replicationState
ibm-replicationFailedChangeCount
ibm-replicationperformance

++ibmrepl includes the attributes from +ibmrepl and adds:
ibm-replicationPendingChanges
ibm-replicationFailedChanges

Restricted attributes

The following lists of restricted attributes are supported by the IBMTivoli Directory Server:

aclEntry
aclPropagate
entryOwner
ibm-filterAclEntry
ibm-filterAclInherit
ownerPropagate

Root DSE attributes

The following attributes relate to the root DSE and must not be modified:

altServer
changelog
firstchangenumber
IBMDirectoryVersion
ibm-effectiveReplicationModel
ibm-enabledCapabilities
ibm-ldapservicename
ibm-sasldigestrealmname
ibm-serverId
ibm-supportedCapabilities
ibm-supportedReplicationModels
lastchangenumber
namingContexts
supportedControl
vendorName
vendorVersion

See Appendix I. Required attribute definitions for IBM Tivoli Directory Server version 6.0 and above for more information about these attributes.

Schema definition attributes

The following attributes are related to Schema definitions and must not be modified:

attributeTypes
ditContentRules
ditStructureRules
IBMAttributeTypes
ldapSyntaxes
matchingRules
matchingRuleUse
nameForms
objectClasses
supportedExtension
supportedLDAPVersion
supportedSASLMechanisms

See Appendix I. Required attribute definitions for IBM Tivoli Directory Server version 6.0 and above for more information about these attributes.

Configuration attributes

The following are attributes that affect the configuration of the server. While the values can be modified, the definitions of these attributes must not be changed for the server to operate correctly

ibm-audit
ibm-auditAdd
ibm-auditAttributesOnGroupEvalOp
ibm-auditBind
ibm-auditCompare
ibm-auditDelete
ibm-auditExtOp
ibm-auditExtOpEvent
ibm-auditFailedOpOnly
ibm-auditGroupsOnGroupControl
ibm-auditLog
ibm-auditModify
ibm-auditModifyDN
ibm-auditSearch
ibm-auditUnbind
ibm-auditVersion
ibm-pwdPolicy
ibm-replicaConsumerConnections
ibm-replicaConsumerId
ibm-replicaCredentialsDN
ibm-replicaGroup
ibm-replicaKeyfile
ibm-replicaKeylabel
ibm-replicaKeypwd
ibm-replicaMethod
ibm-replicaReferralURL
ibm-replicaScheduleDN
ibm-replicaServerId
ibm-replicaURL
ibm-replicationBatchStart
ibm-replicationExcludedCapability
ibm-replicationImmediateStart
ibm-replicationOnHold
ibm-replicationServerIsMaster
ibm-replicationTimesUTC
ibm-scheduleFriday
ibm-scheduleMonday
ibm-scheduleSaturday
ibm-scheduleSunday
ibm-scheduleThursday
ibm-scheduleTuesday
ibm-scheduleWednesday
ibm-slapdAclCache
ibm-slapdAclCacheSize
ibm-slapdAdminDN
ibm-slapdAdminGroupEnabled
ibm-slapdAdminPW
ibm-slapdAllowAnon
ibm-slapdAllReapingThreshold
ibm-slapdAnonReapingThreshold
ibm-slapdAuthIntegration
ibm-slapdBoundReapingThreshold
ibm-slapdBulkloadErrors
ibm-slapdCachedAttribute
ibm-slapdCachedAttributeSize
ibm-slapdChangeLogMaxAge
ibm-slapdChangeLogMaxEntries
ibm-slapdCLIErrors
ibm-slapdConfigPwdPolicyOn
ibm-slapdCryptoSync
ibm-slapdDB2CP
ibm-slapdDBAlias
ibm-slapdDbConnections
ibm-slapdDbInstance
ibm-slapdDbLocation
ibm-slapdDbName
ibm-slapdDbUserID
ibm-slapdDbUserPW
ibm-slapdDerefAliases
ibm-slapdDigestAdminUser
ibm-slapdDigestAttr
ibm-slapdDigestRealm
ibm-slapdDistributedDynamicGroups
ibm-slapdDN
ibm-slapdEnableEventNotification
ibm-slapdErrorLog
ibm-slapdESizeThreshold
ibm-slapdEThreadActivate
ibm-slapdEThreadEnable
ibm-slapdETimeThreshold
ibm-slapdFilterCacheBypassLimit
ibm-slapdFilterCacheSize
ibm-slapdIdleTimeOut
ibm-slapdIncludeSchema
ibm-slapdInvalidLine
ibm-slapdIpAddress
ibm-slapdKrbAdminDN
ibm-slapdKrbEnable
ibm-slapdKrbIdentityMap
ibm-slapdKrbKeyTab
ibm-slapdKrbRealm
ibm-slapdLanguageTagsEnabled
ibm-slapdLdapCrlHost
ibm-slapdLdapCrlPassword
ibm-slapdLdapCrlPort
ibm-slapdLdapCrlUser
ibm-slapdLog
ibm-slapdLogArchivePath
ibm-slapdLogMaxArchives
ibm-slapdLogOptions
ibm-slapdLogSizeThreshold
ibm-slapdMasterDN
ibm-slapdMasterPW
ibm-slapdMasterReferral
ibm-slapdMaxEventsPerConnection
ibm-slapdMaxEventsTotal
ibm-slapdMaxNumOfTransactions
ibm-slapdMaxOpPerTransaction
ibm-slapdMaxPendingChangesDisplayed
ibm-slapdMaxTimeLimitOfTransactions
ibm-slapdMigrationInfo
ibm-slapdPagedResAllowNonAdmin
ibm-slapdPagedResLmt
ibm-slapdPlugin
ibm-slapdPort
ibm-slapdProxyBackendServerDn
ibm-slapdProxyBindMethod
ibm-slapdProxyConnectionPoolSize
ibm-slapdProxyDigestRealm
ibm-slapdProxyDigestUserName
ibm-slapdProxyDn
ibm-slapdProxyNumPartitions
ibm-slapdProxyPartitionBase
ibm-slapdProxyPartitionIndex
ibm-slapdProxyPw
ibm-slapdProxyTargetURL
ibm-slapdPwEncryption
ibm-slapdReadOnly
ibm-slapdReferral
ibm-slapdReplConflictMaxEntrySize
ibm-slapdReplContextCacheSize
ibm-slapdReplDbConns
ibm-slapdReplMaxErrors
ibm-slapdReplicaSubtree
ibm-slapdSchemaAdditions
ibm-slapdSchemaCheck
ibm-slapdSecurePort
ibm-slapdSecurity
ibm-slapdServerBackend
ibm-slapdServerId
ibm-slapdSetenv
ibm-slapdSizeLimit
ibm-slapdSortKeyLimit
ibm-slapdSortSrchAllowNonAdmin
ibm-slapdSslAuth
ibm-slapdSslCertificate
ibm-slapdSslCipherSpec
ibm-slapdSslCipherSpecs
ibm-slapdSslFIPsModeEnabled
ibm-slapdSslFIPsProcessingMode
ibm-slapdSSLKeyDatabase
ibm-slapdSSLKeyDatabasePW
ibm-slapdSslKeyRingFile
ibm-slapdSslKeyRingFilePW
ibm-slapdStartupTraceEnabled
ibm-slapdSuffix
ibm-slapdsupportedCapabilities
ibm-slapdSupportedWebAdmVersion
ibm-slapdSysLogLevel
ibm-slapdTimeLimit
ibm-slapdTraceEnabled
ibm-slapdTraceMessageLevel
ibm-slapdTraceMessageLog
ibm-slapdTransactionEnable
ibm-slapdUseProcessIdPW
ibm-slapdVersion
ibm-slapdWriteTimeout
ibm-UniqueAttributeTypes
ids-instanceDesc
ids-instanceLocation
ids-instanceVersion
paswordMaxRepeatedChars
passwordMinAlpaChars
passwordMinDiffChars
passwordMinOtherChars
pwdAllowUserChange
pwdAttribute
pwdCheckSyntax
pwdExpireWarning
pwdFailureCountInterval
pwdGraceLoginLimit
pwdInHistory
pwdLockout
pwdLockoutDuration
pwdMaxAge
pwdMaxFailure
pwdMinAge
pwdMinLength
pwdMustChange
pwdSafeModify
replicaBindDN
replicaBindMethod
replicaCredentials, replicaBindCredentials
replicaHost
replicaPort
replicaUpdateTimeInterval
replicaUseSSL

See Appendix I. Required attribute definitions for IBM Tivoli Directory Server version 6.0 and above or Configuration attributes for more information about these attributes.

User application attributes

Additionally, there are several user application attributes that must not have their definitions modified:

businessCategory
cn, commonName
changeNumber
changes
changeTime
changeType
deleteOldRdn
description
dn, distinguishedName
globalGroupName
ibm-changeInitiatorsName
ibm-kn, 'ibm-kerberosName
ibm-replCredName
ibm-replDailySchedName
ibm-replWeeklySchedName
krbAliasedObjectName
krbHintAliases
krbPrincSubtree
krbPrincipalName
krbRealmName
krbRealmName-V2
member
name
newRdn
newSuperior
o, organizationName, organization
objectClass
ou, organizationalUnit, organizationalUnitName
owner
ref
secretKey
seeAlso
targetDN

See Appendix I. Required attribute definitions for IBM Tivoli Directory Server version 6.0 and above for more information about these attributes.

Syntaxes

No syntaxes are allowed to be modified.

Matching rules

No matching rules are allowed to be modified.

Schema checking

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).
The following items are checked for attribute types:

Two different attribute types cannot have the same name or OID.
The inheritance hierarchy of attribute types does not have cycles.
The supertype of an attribute type must also be defined, although its definition might be displayed later, or in a separate file.
If an attribute type is a subtype of another, they both have the same USAGE.
All attribute types have a syntax either directly defined or inherited.
Only operational attributes can be marked as NO-USER-MODIFICATION.

The following items are checked for object classes:

Two different object classes cannot have the same name or OID.
The inheritance hierarchy of object classes does not have cycles.
The superclasses of an object class must also be defined, although its definition might appear later or in a separate file.
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.
Every structural object class is a direct or indirect subclass of top.
If an abstract object class has superclasses, the superclasses must also be abstract.

Checking an 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, we can selectively disable some of them by providing an ibm-slapdSchemaCheck value to the ibmslapd.conf configuration directive. See the IBM Tivoli Directory Server Version 6.1 Installation and Configuration Guide 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, 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.
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 DistinguishedNames. If it does not comply, the entry is rejected.
It is verified that the RDN is made up with only attribute types that are valid for that entry.
It is verified that the values of attribute types used in the RDN appear in the entry.

iPlanet compatibility

The parser used by the IBM Tivoli Directory Server allows the attribute values of schema attribute types (objectClasses and attributeTypes ) to be specified using the grammar of iPlanet. For example, descrs and numeric-oids can be specified with surrounding single quotation marks (as if they were qdescrs). However, the schema information is always made available through ldap_search. As soon as a single dynamic change (using ldap_modify) is performed on an attribute value in a file, the whole file is replaced by one where all attribute values follow the specifications of IBM Tivoli Directory Server Version 6.0 and above. Because the parser used on the files and on ldap_modify requests is the same, an ldap_modify that uses the iPlanet grammar for attribute values is also handled correctly.
When a query is made on the subschema entry of a iPlanet server, the resulting entry can have more than one value for a given OID. For example, if a certain attribute type has two names (such as 'cn' and 'commonName'), then the description of that attribute type is provided twice, once for each name. The IBM Tivoli Directory Server can parse a schema where the description of a single attribute type or object class appears multiple times with the same description (except for NAME and DESCR). However, when the IBM Tivoli Directory Server publishes the schema it provides a single description of such an attribute type with all of the names listed (the short name comes first). For example, here is how iPlanet describes the common name attribute:
   ( 2.5.4.3 NAME 'cn'
     DESC 'Standard Attribute'
      SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

   ( 2.5.4.3 NAME 'commonName'
     DESC 'Standard Attribute, alias for cn'
     SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
This is how the IBM Tivoli Directory Server describes it:
  ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )
The IBM Tivoli Directory Server supports subtypes. If you do not want 'cn' to be a subtype of name (which deviates from the standard), we can declare the following:
( 2.5.4.3 NAME ( 'cn' 'commonName' )
     DESC 'Standard Attribute'
     SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
The first name ('cn') is taken as the preferred or short name and all other names after 'cn' as alternate names. From this point on, the strings '2.5.4.3', 'cn' and 'commonName' (as well as their case-insensitive equivalents) can be used interchangeably within the schema or for entries added to the directory.

Generalized and UTC time

There are different notations used to designate date and time-related information. For example, the fourth day of February in the year 1999 can be written as:
2/4/99
4/2/99
99/2/4
4.2.1999
04-FEB-1999
as well as many other notations.
IBM Tivoli Directory Server standardizes the timestamp representation by requiring the LDAP servers to support two syntaxes:
The Generalized Time syntax, which takes the form:
YYYYMMDDHHMMSS[.|,fraction][(+|-HHMM)|Z]
There are 4 digits for the year, 2 digits each for the month, day, hour, minute, and second, and an optional fraction of a second. Without any further additions, a date and time is assumed to be in a local time zone. To indicate that a time is measured in Coordinated Universal Time, append a capital letter Z to a time or a local time differential. For example:
 "19991106210627.3"
which in local time is 6 minutes, 27.3 seconds after 9 p.m. on 6 November 1999.
"19991106210627.3Z"
which is the coordinated universal time.
"19991106210627.3-0500"
which is local time as in the first example, with a 5 hour difference in relation to the coordinated universal time.
If you designate an optional fraction of a second, a period or a comma is required. For local time differential, a '+' or a '-' must precede the hour-minute value
The Universal time syntax, which takes the form:
YYMMDDHHMM[SS][(+ | -)HHMM)|Z]
There are 2 digits each for the year, month, day, hour, minute, and optional second fields. As in GeneralizedTime, an optional time differential can be specified. For example, if local time is a.m. on 2 January 1999 and the coordinated universal time is 12 noon on 2 January 1999, the value of UTCTime is either:
"9901021200Z"      or
"9901020700-0500"
If the local time is a.m. on 2 January 2001 and the coordinated universal time is 12 noon on 2 January 2001, the value of UTCTime is either:
"0101021200Z"      or
"0101020700-0500"
UTCTime allows only 2 digits for the year value, therefore the usage is not recommended.
The supported matching rules are generalizedTimeMatch for equality and generalizedTimeOrderingMatch for inequality. Substring search is not allowed. For example, the following filters are valid:
 generalized-timestamp-attribute=199910061030
 utc-timestamp-attribute>=991006
 generalized-timestamp-attribute=*
The following filters are not valid:
generalized-timestamp-attribute=1999*
utc-timestamp-attribute>=*1010
[ Top of Page | Previous Page | Next Page | Contents | Index ]

Equality matching rules
Matching Rule	OID	Syntax
bitStringMatch	2.5.13.16	Bit String
booleanMatch	2.5.13.13	Boolean
caseExactIA5Match	1.3.6.1.4.1.1466.109.114.1	Directory String syntax
caseExactMatch	2.5.13.5	Directory String syntax
caseIgnoreIA5Match	1.3.6.1.4.1.1466.109.114.2	IA5 String syntax
caseIgnoreListMatch	2.5.13.11	Directory String
caseIgnoreMatch	2.5.13.2	Directory String syntax
distinguishedNameMatch	2.5.13.1	DN - distinguished name
generalizedTimeMatch	2.5.13.27	Generalized Time syntax
ibm-entryUuidMatch	1.3.18.0.2.22.2	Directory String syntax
integerFirstComponentMatch	2.5.13.29	Integer syntax - integral number
integerMatch	2.5.13.14	Integer syntax - integral number
numericStringMatch	2.5.13.8	Numeric String
objectIdentifierFirstComponentMatch	2.5.13.30	String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.).
objectIdentifierMatch	2.5.13.0	String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.)
octetStringMatch	2.5.13.17	Directory String syntax
presentationAddressMatch	2.5.13.22	Presentation Address
protocolInformationMatch	2.5.13.24	Protocol Information
telephoneNumberMatch	2.5.13.20	Telephone Number syntax
uniqueMemberMatch	2.5.13.23	Name And Optional UID
uTCTimeMatch	2.5.13.25	UTC Time syntax

Ordering matching rules
Matching rule	OID	Syntax
caseExactOrderingMatch	2.5.13.6	Directory String syntax
caseIgnoreOrderingMatch	2.5.13.3	Directory String syntax
distinguishedNameOrderingMatch	1.3.18.0.2.4.405	DN - distinguished name
generalizedTimeOrderingMatch	2.5.13.28	Generalized Time syntax
integerOrderingMatch	2.5.13.15	Integer
numericStringOrderingMatch	2.5.13.9	Numeric String
octetStringOrderingMatch	2.5.13.18	Octet String

Substring matching rules
Matching rule	OID	Syntax
caseExactSubstringsMatch	2.5.13.7	Directory String syntax
caseIgnoreListSubstringsMatch	2.5.13.12	Substring Assertion
caseIgnoreSubstringsMatch	2.5.13.4	Directory String syntax
numericStringSubstringsMatch	2.5.13.10	Substring Assertion
telephoneNumberSubstringsMatch	2.5.13.21	Telephone Number syntax

Syntax	OID
Attribute Type Description syntax	1.3.6.1.4.1.1466.115.121.1.3
Binary - octet string	1.3.6.1.4.1.1466.115.121.1.5
Bit String	1.3.6.1.4.1.1466.115.121.1.6
Boolean - TRUE/FALSE	1.3.6.1.4.1.1466.115.121.1.7
Certificate	1.3.6.1.4.1.1466.115.121.1.8
Certificate List	1.3.6.1.4.1.1466.115.121.1.9
Certificate Pair	1.3.6.1.4.1.1466.115.121.1.10
Country String	1.3.6.1.4.1.1466.115.121.1.11
Delivery Method	1.3.6.1.4.1.1466.115.121.1.14
Directory String syntax	1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description syntax	1.3.6.1.4.1.1466.115.121.1.16
DITStructure Rule Description syntax	1.3.6.1.4.1.1466.115.121.1.17
DN - distinguished name	1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide	1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number	1.3.6.1.4.1.1466.115.121.1.22
Fax	1.3.6.1.4.1.1466.115.121.1.23
Generalized Time syntax	1.3.6.1.4.1.1466.115.121.1.24
Guide	1.3.6.1.4.1.1466.115.121.1.25
IA5 String syntax	1.3.6.1.4.1.1466.115.121.1.26
IBM Attribute Type Description	1.3.18.0.2.8.1
Integer syntax - integral number	1.3.6.1.4.1.1466.115.121.1.27
JPEG	1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description syntax	1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description	1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description	1.3.6.1.4.1.1466.115.121.1.31
MHS OR Address	1.3.6.1.4.1.1466.115.121.1.33
Name And Optional UID	1.3.6.1.4.1.1466.115.121.1.34
Name Form Description	1.3.6.1.4.1.1466.115.121.1.35
Numeric String	1.3.6.1.4.1.1466.115.121.1.36
Object Class Description syntax	1.3.6.1.4.1.1466.115.121.1.37
Octet String	1.3.6.1.4.1.1466.115.121.1.40
Other Mailbox	1.3.6.1.4.1.1466.115.121.1.39
Postal Address	1.3.6.1.4.1.1466.115.121.1.41
Presentation Address	1.3.6.1.4.1.1466.115.121.1.43
Protocol Information	1.3.6.1.4.1.1466.115.121.1.42
Printable String	1.3.6.1.4.1.1466.115.121.1.44
String for containing OIDs. The OID is a string containing digits (0-9) and decimal points (.). See Object identifier (OID).	1.3.6.1.4.1.1466.115.121.1.38
Substring Assertion	1.3.6.1.4.1.1466.115.121.1.58
Supported Algorithm	1.3.6.1.4.1.1466.115.121.1.49
Telephone Number syntax	1.3.6.1.4.1.1466.115.121.1.50
Telex Number	1.3.6.1.4.1.1466.115.121.1.52
Teletex Terminal Identifier	1.3.6.1.4.1.1466.115.121.1.51
UTC Time syntax. UTC-Time is time string format defined by ASN.1 standards. See ISO 8601 and X680. Use this syntax for storing time values in UTC-Time format. See Generalized and UTC time.	1.3.6.1.4.1.1466.115.121.1.53

Attribute	Attributes returned by "+" attribute	Attributes added by ++
+	Returns all attributes listed in this column.	++ returns all attributes listed in this column
+ibmaci	aclentry aclsource aclpropagate entryowner ownersource ownerpropagate ibm-filterAclEntry ibm-filterAclInherit ibm-effectiveAcl
+ibmentry	creatorsname createtimestamp modifiersname modifytimestamp subschemasubentry ibm-entryuuid ibm-capabilitiessubentry ibm-enabledcapabilities (1) ibm-supportedcapabilities (1) ibm-replicationThisServerIsMaster ibm-replicationIsQuiesced	++ibmentry includes the attributes from +ibmentry and adds: ibm-allgroups ibm-allmembers ibm-entryChecksum ibm-entryChecksumOp numsubordinates hassubordinates
+ibmpwdpolicy	pwdAccountLockedTime pwdChangedTime pwdExpirationWarned pwdFailureTime pwdGraceUseTime pwdHistory pwdReset ibm-pwdAccountLocked ibm-pwdGroupPolicyDN ibm-pwdIndividualPolicyDN
+ibmrepl	ibm-replicationChangeLDIF ibm-replicationLastActivationTime ibm-replicationLastChangeId ibm-replicationLastFinishTime ibm-replicationLastResult ibm-replicationLastResultAdditional ibm-replicationNextTime ibm-replicationPendingChangeCount ibm-replicationState ibm-replicationFailedChangeCount ibm-replicationperformance	++ibmrepl includes the attributes from +ibmrepl and adds: ibm-replicationPendingChanges ibm-replicationFailedChanges