IBM Security 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 that are allowed, their attribute structure, and the syntax of the attributes.
Data is stored in the directory by 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 Directory entries for more information about entries.
The schema for the IBM® Security Directory is predefined. However, you can modify the schema, if you have more requirements.
IBM Security 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"
). You can query the schema by using the
ldap_search()
API and modify it by using ldap_modify()
. See the
Programming Reference section in the IBM Security Directory Server documentation for more information about the 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 an attribute, you can state which
indexes must be maintained. This extra configuration information is maintained in the subschema
entry as appropriate. An extra object class that is defined for the subschema entry
IBMsubschema
, which has MAY
attributes that hold the extended
schema information.
cn=schema
. The entry contains all of the schema that is defined for the server. To
retrieve schema information, you can perform an ldap_search
by using the following
entry: DN: "cn=schema", search scope: base, filter: objectclass=subschema
or objectclass=*
objectClasses
(See Object classes.)attributeTypes
(See Working with attributes.)IBMAttributeTypes
(See IBMAttributeTypes attribute.)matching rules
(See Equality matching rules).ldap syntaxes
(See Attribute syntax).
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 an attribute type be provided in a single production.The schema information can be modified through the ldap_modify
API. Refer the
Programming Reference section in the IBM Security Directory Server documentation for more information. With the DN
cn=schema
you 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. You can add or replace a schema entry with the LDAP Version 3 definition or with the
IBM attribute extension definition or with both
definitions.