ldapschema(1)

NAME

ldapschema — determines the status of an LDAP schema on the LDAP directory server and extends the LDAP directory server schema with new attribute types and object classes.

SYNOPSIS

ldapschema -q schema -T ds_type -V ds_version [options]

ldapschema -e schema -T ds_type -V ds_version [options]

DESCRIPTION

The ldapschema utility allows schema developers to define LDAP schemas using a universal XML syntax, greatly simplifying the ability to support different directory server variations. It can be used to query the current status of the LDAP schema on the LDAP directory server, as well as extend the LDAP directory server schema with new attribute types and object classes. The ldapschema utility was designed to support directory servers from several vendors and is currently supported with Netscape Directory Server/Red Hat Directory Server and Microsoft Windows Active Directory Server.

ldapschema supports two modes of operation:

1.: Query mode determines the current status of the LDAP schema on the LDAP directory server. ldapschema checks if any attribute types and object classes of the LDAP schema are already installed on the LDAP server. Also, it determines if definitions installed on the LDAP server match definitions specified in the schema definition file being queried.
2.: Extend mode adds definitions of attribute types and object classes that are not yet installed on the LDAP server to that LDAP server's schema. Only new valid attribute types and object classes can be added to the LDAP server schema. To execute the ldapschema utility in the Extend mode, most LDAP directory servers require specifying the distinguished name and password of an administrator who has permissions to modify the schema on that server.

ldapschema uses the following XML files:

LDAP schema definition files (see the SCHEMA DEFINITION FILE section below).
Files containing matching rules and syntaxes supported on the LDAP server in case the LDAP server does not provide them directly (see the LDAP DIRECTORY SERVER DEFINTION FILE section below).
Mapping rules for unsupported matching rules and syntaxes file (see the MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES section below).

This manpage describes the use of ldapschema, including the command line, environment variables and the XML files format.

Required Command Options

ldapschema requires these options:

-q schema

Queries schema status on the LDAP directory server without applying any changes to the LDAP directory server. Schema definition is obtained from the specified schema file. See the SCHEMA DEFINITION FILE section for details.

-e schema

Extends the LDAP directory server schema with attribute types and object classes defined in the specified schema. Schema definition is obtained from the schema file. See the SCHEMA DEFINITION FILE section for details. On most LDAP directory servers this option requires specifying the -D binddn option and either the -j filename or the -w - option to specify the credentials of an administrator who has permissions to modify the schema on the directory server.

-T ds_type

Specifies the type of LDAP directory server. The following types of LDAP directory servers are fully supported by ldapschema:

Type of Directory Server: ds_type
Active Directory Server: ads
Red Hat Directory Server: rhds

The ldapschema utility may work with other types of LDAPv3 directory servers, although its behavior has not been verified.

The names of the following LDAPv3 directory servers are reserved for future support:

Type of Directory Server: ds_type
Oracle Internet Directory: oracle
Novell e-Directory: eDirectory
IBM Tivoli Directory Server: ibm
MAC OS X Directory Server: mac
Computer Associates DS: ca
Sun ONE Directory Server: sun
iPlanet Directory Server: iPlanet

-V ds_version

Specifies the version of LDAP directory server. The strcasecmp() function compares the version specified by this -V option and the version defined in the XML files the ldapschema utility processes.

For example, the schema definition file contains the following object class definition:

<objectClassDefinition> <oid>1.2.345.6.789</oid> <name>sampleObject</name> <must>sampleAttributeA</must> <must only="rhds" versionGreaterOrEqual="6.2">sampleAttributeB</must> </objectClassDefinition>

If the ldapschema utility is called with ds_version set to 6.2.1 the sampleObject definition has two mandatory attributes, sampleAttributeA and sampleAttributeB. The strcasecmp ("6.2.1", "6.2") returns a positive integer, so sampleAttributeB is included in the definition of the object class sampleObject.

On the other hand, if the ldapschema utility is called with ds_version set to 6.02.1 the sampleObject definition has only one mandatory attribute, sampleAttributeA. The strcasecmp ("6.02.1", "6.2") returns a negative integer, so sampleAttributeB is not included in the definition of the object class sampleObject.

The ldapschema utility ignores ds_version if the LDAP directory server version-specific attributes versionGreaterOrEqual and versionLessThan are not used in the XML files being processed (that is, the schema definition files, the LDAP directory server definition file and the mapping rules file). If the XML files include any definitions with versionGreaterOrEqual attribute set, strcasecmp() must return zero or a positive integer to include directory-specific information in the LDAP schema definition. If the XML files include any definitions with versionLessThan attribute set, strcasecmp() must return a negative integer to include directory-specific information in the LDAP schema definition. Also, versionGreaterOrEqual and versionLessThan can be used simultaneously to define a range of version of the LDAP directory server. See the SPECIFYING DIRECTORY-SPECIFIC INFORMATION section for details.

Additional Options (Optional)

ldapschema support these additional options:

-h hostname

Specifies the LDAP directory server hostname or IP address.

Default: localhost

-p port

Specifies the LDAP directory server TCP port number.

Default: 389 for regular connections, 636 for SSL connections.

-D binddn

Specifies the distinguished name of an administrator who has permissions to read and modify LDAP directory server schema.

-j filename

Reads administrator's password from the specified file (for simple authentication).

-w -

Reads the administrator's password from the prompt (for simple authentication).

-Z

Establishes an SSL-encrypted connection.

-ZZ

Starts TLS request.

-ZZZ

Enforces start of TLS request (requires successful server response).

-P path

Specifies path to SSL certificate database containing cert8.db and key3.db files.

Default: /etc/opt/ldapux.

-3

Verifies hostnames in SSL certificates.

-s -

Disables syntax substitution in attribute types. Normally, if an attribute type uses an LDAP syntax not supported on the LDAP directory server, it is mapped to use a higher-level (more inclusive) syntax supported by that server. If this option is specified, any attribute types that use unsupported LDAP syntax will not be added to the LDAP directory server schema. See the MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES section for more details.

-m -

Disables matching rule substitution in attribute types. Normally, if an attribute type uses a matching rule not supported on the LDAP directory server, it is mapped to use a higher-level (less specific) matching rule supported by that server. If this option is specified, any attribute types that use unsupported matching rules will not be added to the LDAP directory server schema. See the MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES section for more details.

-f filename

Stores schema extension instructions in the specified file.

File format depends on the vendor and version of the LDAP directory server (usually LDIF). When this option is specified, ldapschema will not apply any changes to the LDAP directory server or its schema.

This option requires specifying the -e option. If filename is set to a dash (-f -), the output is redirected to standard output; otherwise, it is stored in the specified filename.

-F

Forces installation of schema even if it contains any invalid attribute type or object class definitions, or the LDAP directory server already has some of its components installed and their definitions are different from those specified in the schema file.

-v

Displays verbose information to standard output.

To extend schema on the LDAP server, HP recommends the following process:

1.: Execute ldapschema in query mode (use the -q option) first to determine the overall status of the schema.
2.: Correct any invalid attribute type or object class definitions, if present.
3.: Execute ldapschema in extend mode (use the -e option) to install new schema elements on the LDAP server.

Extending schema containing invalid or incompatible attribute types or object classes is not recommended. To install elements defined in a schema file containing invalid or incompatible definitions requires specifying the force option (-F).

SECURITY

For security reasons, the LDAP administrator password may not be specified on the command line. It can be specified at the prompt (using the -w - option), in a file (using -j filename), or using the LDAP_BINDCRED environmental variable described in the CONFIGURATION VARIABLES section below.

CONFIGURATION VARIABLES

The ldapschema utility tool recognizes the following shell environmental variables.

LDAP_BINDDN

Distinguished name of an administrator who has permissions to read and modify LDAP directory server schema.

LDAP_BINDCRED

The password for the above privileged LDAP user.

LDAP_HOST

The host name of the LDAP directory server.

LDAP_HOST uses the following format: hostname:port.

If port is not specified, the default port number is 389 for regular connections, or 636 for SSL connections.

Options specified on the command line override the environmental variables. For example, if -j /tmp/secret.txt is specified on the command line, and LDAP_BINDCRED environmental variable is set, the password of the LDAP directory server administrator is obtained from file name /tmp/secret.txt.

SCHEMA DEFINITION FILE

The ldapschema utility queries and extends the LDAP directory server based on the XML schema definition file. The schema argument used with the -q or -e option must correspond to the XML file containing the appropriate schema definition.

Each schema definition file must adhere to Document Type Definition (DTD) template specified in the /etc/opt/ldapux/schema/schema.dtd file. So every XML file used by ldapschema must include /etc/opt/ldapux/schema/schema.dtd as its DTD. See line 2 in the example below.

WARNING: Every XML file used with the ldapschema utility must include /etc/opt/ldapux/schema/schema.dtd file as its DTD template. Do not modify this file, or create your own DTD template file. File /etc/opt/ldapux/schema/schema.dtd is created to validate attribute type and object class definitions before they can be added to the LDAP directory server schema. Altering this file will cause ldapschema to fail.

The schema definition, enclosed by the <schemaDefinition> tags, specifies the schema name, schema description and schema source, followed by any number of attribute type and object class definitions.

There are no restrictions on the schema name, description and source XML tag. See lines 6-8 in the example below. These tags are optional. Schema source is used to specify the X-ORIGIN field of extended attribute types and object classes, if used.

After general schema information is specified, attribute types, if any, must be specified followed by any object class definitions. The example below defines two attribute types, printer-name (lines 10-19) and printer-aliases (lines 21-29), followed by one object class printerLPR (lines 31-38) as specified in RFC 3712.

Line 1:  <?xml version="1.0" encoding="UTF-8"?>
Line 2:  <!DOCTYPE schemaDefinition SYSTEM "/etc/opt/ldapux/schema/schema.dtd">
Line 3:
Line 4:  <schemaDefinition>
Line 5:
Line 6:  <schemaName>rfc3712</schemaName>
Line 7:  <schemaDescription>Printer Services Schema</schemaDescription>
Line 8:  <schemaSource>RFC 3712</schemaSource>
Line 9:
Line 10: <attributeTypeDefinition>
Line 11:    <oid>1.3.18.0.2.4.1135</oid>
Line 12:    <name>printer-name</name>
Line 13:    <desc>A site-specific administrative name of this printer</desc>
Line 14:    <equality>caseIgnoreMatch</equality>
Line 15:    <substr>caseIgnoreSubstringsMatch</substr>
Line 16:    <syntax>1.3.6.1.4.1.1466.115.121.1.15</syntax>
Line 17:    <length>127</length>
Line 18:    <singleValued/>
Line 19: </attributeTypeDefinition>
Line 20:
Line 21: <attributeTypeDefinition>
Line 22:    <oid>1.3.18.0.2.4.1108</oid>
Line 23:    <name>printer-aliases</name>
Line 24:    <desc>Names in addition to the printer-name value</desc>
Line 25:    <equality>caseIgnoreMatch</equality>
Line 26:    <substr>caseIgnoreSubstringsMatch</substr>
Line 27:    <syntax>1.3.6.1.4.1.1466.115.121.1.15</syntax>
Line 28:    <length>127</length>
Line 29: </attributeTypeDefinition>
Line 30:
Line 31: <objectClassDefinition>
Line 32:    <oid>1.3.18.0.2.6.253</oid>
Line 33:    <name>printerLPR</name>
Line 34:    <desc>LPR information</desc>
Line 35:    <type>AUXILIARY</type>
Line 36:    <must>printer-name</must>
Line 37:    <may>printer-aliases</may>
Line 38: </objectClassDefinition>
Line 39:
Line 40: </schemaDefinition>

Lines 1-2 are required in every schema definition file. Attribute type and object class definitions closely follow the format specified in RFC 2252. Values specified for all XML tags, except the <dsSpecific> fields must not be quoted. Only the description field (enclosed by <desc>...</desc> tags) can contain spaces.

Defining Attribute Types

Each <attributeTypeDefinition> can contain the following case-sensitive tags, in the order specified:

<oid>

Required. Exactly one numeric id must be specified. <oid> value must adhere to RFC 2252 format specification.

<name>

Required. At least one attribute type name must be specified. Do not use quotes around the name values. <name> value must adhere to RFC 2252 format specification.

<displayName>

Optional. At most one display name can be specified. This tag specifies a display name of the attribute type used by LDAP clients and administrative tools. Currently, <displayName> applies only to Active Directory Server (ADS) to specify lDAPDisplayName and adminDisplayName if different from the <name> value.

<desc>

Optional. At most one description can be specified. Do not use quotes around the description value.

<obsolete>

Optional, use only if applicable. Obsolete attribute types cannot be used in definitions of any other attribute types or object classes. At most one obsolete flag can be specified.

<subTypeOf>

Optional, use if an attribute type has a super-type. At most one super-type can be specified. The specified super-type must already exist on the LDAP directory server, or its definition must be specified in the same schema definition file.

<equality>

Optional. At most one equality rule can be specified.

<ordering>

Optional. At most one ordering rule can be specified.

<substr>

Optional. At most one substrings rule can be specified.

<syntax>

Required if an attribute type has no super-type. At most one LDAP syntax can be specified.

<length>

Optional. Indicates the maximum length of a value of this attribute. RFC 2252 specifies this value in curly braces following the attribute type's syntax. For instance, SYNTAX 1.3.6.4.1.1466.0{64} can be expressed using the following tags:

At most one attribute length can be specified. <length> must contain a positive integer value.

<singleValued>

Optional, use if the SINGLE-VALUE flag is set. At most one singleValued flag can be specified.

<collective>

Optional, use if the COLLECTIVE-VALUE flag is set. At most one collective flag can be specified.

<noUserModification>

Optional, use if the NO-USER-MODIFICATION flag is set. At most one noUserModification flag can be specified.

<usage>

Optional, must contain one of the following possible values: userApplications, directoryOperation, distributedOperation, or dSAOperation. At most one usage value can be specified.

<indexed>

Optional, use if an attribute type requires indexing. At most one indexed flag can be set.

<dsSpecific>

Optional, use to specify any directory-specific information about the attribute type. See the SPECIFYING DIRECTORY-SPECIFIC INFORMATION section for details.

Each attribute type definition must meet the following conditions in order to be added to the LDAP directory server schema:

The attribute type has a numeric OID which adheres to RFC 2252 format specification.
The attribute type has at least one name. Each name must adhere to RFC 2252 format specification.
No other attribute types in the schema definition file or on the LDAP directory server have the same OID or any of its name values.
The super-type used by this attribute type is defined.
The attribute type specifies either an LDAP syntax value or a super-type. Some directory servers, for example ADS, do not support attribute type inheritance. For such directory servers, the LDAP syntax for the sub-type attribute is obtained from the super-type definition and the super-type/sub-type relationship is ignored.
The matching rules and syntaxes used by this attribute type are supported by the LDAP directory server. See the MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES section for details.
The inheritance hierarchy has no cycles (no circular dependencies exist in the super-class/sub-class relationships).
If the attribute type has a super-type, they both have the same USAGE value.

Defining Object Classes

Each <objectClassDefinition> can contain the following case-sensitive tags, in the order specified:

<oid>: Required. Exactly one numeric id must be specified. <oid> value must adhere to RFC 2252 format specification.
<name>: Required. At least one object class name must be specified. Do not use quotes around the name values. <name> value must adhere to RFC 2252 format specification.
<displayName>: Optional. At most one display name can be specified. This tag specifies a display name of the object class used by LDAP clients and administrative tools. Currently, <displayName> applies only to Active Directory Server (ADS) to specify lDAPDisplayName and adminDisplayName if different from the <name> value.
<desc>: Optional. At most one description can be specified. Do not use quotes around the description value.
<obsolete>: Optional, use only if applicable. Obsolete object classes cannot be used in definitions of any other object classes. At most one obsolete flag can be specified.
<subClassOf>: Optional, use if an object class has super-classes. The specified super-class must already exist on the LDAP directory server, or must its definition must be specified in the same schema definition file.
<type>: Optional, must contain one of the following possible values: STRUCTURAL, AUXILIARY, ABSTRACT. At most one type value can be specified.
<must>: Optional, use if an object class has mandatory attributes. The specified attributes must already exist on the LDAP directory server, or must its definition must be specified in the same schema definition file.
<may>: Optional, use if an object class has optional attributes. The specified attributes must already exist on the LDAP directory server, or must its definition must be specified in the same schema definition file.
<rdn>: Optional. Defines the recommended attribute to use for the Relative Distinguished Name (RDN) for new entries created with this object class. Currently, <rdn> applies only to Active Directory Server (ADS). At most one RDN can be specified.
extendAuxiliaryClass: Optional, applies to AUXILIARY object classes only. This tag is used to extend an object class already defined in the LDAP server schema with this new AUXILIARY object class. Currently, <extendAuxiliaryClass> applies only to Active Directory Server (ADS) to include the new AUXILIARY class as an auxiliaryClass in the definition of another object class already defined in the LDAP server schema.
<dsSpecific>: Optional, use to specify any directory-specific information about the attribute type. See the SPECIFYING DIRECTORY-SPECIFIC INFORMATION section for details.

Each object class definition must meet the following conditions in order to be added to the LDAP directory server schema:

The object class has a numeric OID which adheres to RFC 2252 format specification.
The object class has at least one name. Each name must adhere to RFC 2252 format specification.
No other object classes in the schema definition file or on the LDAP directory server have the same OID or any of its name values.
The super-class(es) used by this object classes are defined.
The attribute(s) used by this object classes are defined.
The inheritance hierarchy has no cycles (no circular dependencies exist in the super-class/sub-class relationships).
An ABSTRACT object class can specify only ABSTRACT object class(es) as its super-class(es).
An AUXILIARY object class can specify ABSTRACT or AUXILIATY object class(es) as its super-class(es).
A STRUCTURAL object class can specify ABSTRACT or STRUCTURAL object class(es) as its super-class(es).

Predefined Schema Definition Files

The following LDAP schema definition files are delivered with the LDAP-UX product:

/etc/opt/ldapux/schema/rfc2256.xml
/etc/opt/ldapux/schema/rfc2307.xml
/etc/opt/ldapux/schema/rfc2307-bis.xml
/etc/opt/ldapux/schema/rfc2926.xml
/etc/opt/ldapux/schema/rfc3712.xml

These files are provided as examples to demonstrate how to define new LDAP schema definition files to use with the ldapschema utility. Since these files define attribute types and object classes that come pre-installed on most LDAP directory servers they are not intended for extending the LDAP directory server schema. Instead, these files are provided for reference when creating the new schema definition files to query and extend the LDAP directory server schema with the new attribute type and object class definitions.

SPECIFYING DIRECTORY-SPECIFIC INFORMATION

Attribute type and object class definitions can be extended with directory-specific information using the <dsSpecific> tag. This is useful to maintain a single schema definition file for different types and versions of LDAP directory servers. The following example illustrates how a single attribute type definition can be altered to support Red Hat Directory Server and Active Directory Server directory server specific definitions simultaneously.

Line 1:  <attributeTypeDefinition>
Line 2:    <oid>1.23.456.7.89101112.1.314.1.51.6</oid>
Line 3:    <name>sampleAttribute</name>
Line 4:    <displayName only="ads"
Line 5:     versionGreaterOrEqual="2003">my-sample-attribute</displayName>
Line 6:    <equality>caseIgnoreMatch</equality>
Line 7:    <syntax>1.3.6.1.4.1.1466.115.121.1.15</syntax>
Line 8:    <dsSpecific vendor="rhds" versionGreaterOrEqual="6.2"
Line 9:                              versionLessThan="7.1">
Line 10:         <field attr="X-ORIGIN">'Custom Schema'</field>
Line 11:   </dsSpecific>
Line 12:   <dsSpecific vendor="ads" versionLessThan="2003">
Line 13:         <field attr="systemOnly">TRUE</field>
Line 14:         <field attr="rangeLower">256</field>
Line 15:   </dsSpecific>
Line 16:   <dsSpecific vendor="ads" versionGreaterOrEqual="2003">
Line 17:         <field attr="rangeLower">512</field>
Line 18:   </dsSpecific>
Line 19: </attributeTypeDefinition>

On Red Hat Directory Server 6.2 through 7.0, the X-ORIGIN flag for the sampleAttribute will be set to 'Custom Schema' as specified in the dsSpecific field. On Red Hat Directory Server 6.1 and earlier, or 7.1 and later, the X-ORIGIN flag for sampleAttribute will be set to the value specified in the <schemaSource> tag.

On Active Directory Server 2000, the sampleAttribute is added using the same display name as specified by the <name> value, with rangeLower attribute set to 256, and systemOnly attribute set to TRUE.

On Active Directory Server 2003, the sampleAttribute is added using my-sample-attribute display name, with rangeLower attribute set to 512, and systemOnly attribute set to FALSE, which is the default value.

Also, since 1.3.6.1.4.1.1466.115.121.1.15 syntax is not supported on the ADS, it is mapped to the corresponding Directory String syntax supported on ADS, which is attributeSyntax=2.5.5.12 oMSyntax=64. See the MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES section for details.

Directory specific information can also be specified in the object class definitions.

Line 1:  <objectClassDefinition>
Line 2:    <oid>1.23.456.7.89101112.1.314.1.51.7</oid>
Line 3:    <name>sampleObject</name>
Line 4:    <must only="ads">serverRole</must>
Line 5:    <must not="ads">userPassword</must>
Line 6:    <may>sampleAttribute</may>
Line 7:    <dsSpecific vendor="ads">
Line 8:          <field attr="systemOnly">TRUE</field>
Line 9:    </dsSpecific>
Line 10: </objectClassDefinition>

On Active Directory Server, this object class has a mandatory attribute type serverRole and an optional attribute sampleAttribute. On all other types of directory servers, this object class has a mandatory attribute type userPassword and an optional attribute sampleAttribute. Also, on Active Directory Server this object class has the systemOnly attribute set to TRUE.

WARNING: Directory-specific attributes and values specified using <dsSpecific> fields are not validated. Make sure the values specified in these fields are legitimate and adhere to the LDAP directory server rules. The field value must be specified exactly as it is to appear in the attribute type or object class definition, using single and double quotes as applicable. <dsSpecific> attributes and values override the default attribute type and object class configurations. For instance, on Active Directory Server the isDefunct setting by default is set to FALSE. However, specifying

       <dsSpecific vendor="ads">
              <field attr="isDefunct">TRUE</field>
       </dsSpecific>

will override this default setting and will result in the element being defunct (that is, obsolete).

LDAP DIRECTORY SERVER DEFINTION FILE

In order to properly install new attribute types on the LDAP directory server schema, the ldapschema utility needs to determine whether the LDAP server supports the matching rules and LDAP syntaxes used by the new attribute type definitions. The ldapschema utility performs an LDAP search for supported matching rules and syntaxes on the LDAP server. However, some types of directory servers do not provide this information as part of the search. Perform the following command to determine if your directory server returns information about supported matching rules and LDAP syntaxes:

First, determine the <schemaDN>:

/opt/ldapux/bin/ldapsearch -b "" -s base \ 
     "(objectclass=*)" subschemasubentry 

Then, obtain the list of supported matching rules and LDAP syntaxes:

/opt/ldapux/bin/ldapsearch -b "<schemaDN>" -s base \ 
     "(objectclass=*)" matchingRules ldapSyntaxes 

If the latter search does not return a complete listing of supported matching rules and LDAP syntaxes, they need to be specified in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility.

The LDAP directory server definition, enclosed by the <dsSchemaDefinition> tags, may specify the schema description, followed by any number of supported matching rules and LDAP syntax definitions.

Using Active Directory Server as an example, run ldapschema with the -T ads option, so the corresponding directory server definition is obtained from /etc/opt/ldapux/schema/schema-ads.xml file provided with the utility.

After general schema information is specified, supported matching rules, if any, must be specified followed by any supported LDAP syntaxes definitions. The example below defines two syntaxes supported on ADS (lines 8-12 and 14-18).

Line 1: <?xml version="1.0" encoding="UTF-8"?>
Line 2: <!DOCTYPE dsSchemaDefinition SYSTEM "/etc/opt/ldapux/schema/schema.dtd">
Line 3:
Line 4: <dsSchemaDefinition>
Line 5:
Line 6: <schemaDescription>ADS Syntaxes</schemaDescription>
Line 7:
Line 8: <syntaxDefinition>
Line 9:    <oid>2.5.5.1</oid>
Line 10:   <desc>Distinguished Name</desc>
Line 11:   <oMSyntax>127</oMSyntax>
Line 12: </syntaxDefinition>
Line 13:
Line 14: <syntaxDefinition>
Line 15:   <oid>2.5.5.2</oid>
Line 16:   <desc>Object Identifier</desc>
Line 17:   <oMSyntax>6</oMSyntax>
Line 18: </syntaxDefinition>
Line 19:
Line 20: </dsSchemaDefinition>

Lines 1-2 are required in every LDAP directory server definition file. LDAP syntax and matching rules definitions closely follow the format specified in RFC 2252. Values specified for all XML tags must not be quoted. Only the description field (enclosed by <desc>...</desc> tags) can contain spaces.

Defining LDAP Syntaxes

Each <syntaxDefinition> can contain the following case-sensitive tags, in the order specified:

<oid>: Required. Exactly one numeric id must be specified.
<desc>: Optional. At most one description can be specified.
<oMSyntax>: Required on ADS only, ignored on other types of LDAP directory servers.

Defining Matching Rules

Each <matchingRuleDefinition> can contain the following case-sensitive tags, in the order specified:

<oid>: Required. Exactly one numeric id must be specified.
<name>: Required. At least one matching rule type name must be specified. Do not use quotes around the name values.
<desc>: Optional. At most one description can be specified.
<obsolete>: Optional, use only if applicable. Obsolete matching rules cannot be used in definitions of any other attribute types. At most one obsolete flag can be specified.
<syntax>: Required. Specified LDAP syntax must also be supported on the LDAP directory server. At most one LDAP syntax can be specified per matching rule definition.

Only syntaxes and matching rules fully supported by the LDAP directory server can be specified in this file. Attributes vendor, versionGreaterOrEqual, and versionLessThan can be used to specify directory-specific information.

See /etc/opt/ldapux/schema/schema-ads.xml for an example of LDAP directory server definition files.

MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES

If matching rules and/or LDAP syntaxes used in attribute type definitions in the schema definition file are not supported on the LDAP directory server, they need to be mapped to use alternate matching rules and syntaxes the LDAP server does support.

The matching rules are specified in <equality>, <ordering>, or <substr> tags in the attribute type definition. The LDAP syntax is specified in the <syntax> tag. The mapping rules that determine how the matching rules and syntaxes are replaced are specified in /etc/opt/ldapux/schema/map-rules.xml file. If ldapschema cannot successfully map the attribute's matching rules and syntax, ldapschema will not be able to add the attribute type to the LDAP directory server schema.

The purpose of the mapping rules file is to allow an LDAP schema to be installed on an LDAP directory server even if some of matching rules and LDAP syntaxes used in the definition of that schema are not supported by the directory server. File /etc/opt/ldapux/schema/map-rules.xml uses the following mapping rules guideline:

map more restrictive syntaxes to less restrictive syntaxes
map more specific matching rules to less specific matching rules

For example, the Integer syntax contains a subset of characters of the IA5 string syntax. Therefore, it is acceptable to map the Integer syntax to the IA5 string syntax, since the IA5 string syntax is a superset of the Integer syntax.

The following example illustrates a sample /etc/opt/ldapux/schema/map-rules.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mappingPolicies SYSTEM "schema.dtd">

<mappingPolicies>

<defaultMatchingRulesReplacements>
   <defaultMatchingRule>
      <matchingRule>caseIgnoreMatch</matchingRule>
   </defaultMatchingRule>
</defaultMatchingRulesReplacements>

<defaultSyntaxesReplacements>
   <defaultSyntax only="ads">
      <syntax>2.5.5.12</syntax>
      <desc>Active Directory String syntax.</desc>
      <oMSyntax>64</oMSyntax>
   </defaultSyntax>

   <defaultSyntax not="ads">
      <syntax>1.3.6.1.4.1.1466.115.121.1.15</syntax>
      <desc>Directory String syntax.</desc>
   </defaultSyntax>
</defaultSyntaxesReplacements>

<matchingRulesReplacements>
   <matchingRules>
      <matchingRule>integerMatch</matchingRule>
      <subRule>
         <matchingRule>numericStringMatch</matchingRule>
      </subRule>
   </matchingRules>
</matchingRulesReplacements>

<syntaxesReplacements>
   <syntaxes>
      <syntax>1.3.6.1.4.1.1466.115.121.1.26</syntax>
      <desc>IA5 String syntax.</desc>
      <equivSyntax>
         <syntax>2.5.5.5</syntax>
         <desc>Active Directory IA5 String LDAP Syntax.</desc>
         <oMSyntax>22</oMSyntax>
      </equivSyntax>
      <subSyntax>
         <syntax>1.3.6.1.4.1.1466.115.121.1.15</syntax>
         <desc>Directory String syntax.</desc>
      </subSyntax>
   </syntaxes>
</syntaxesReplacements>

</mappingPolicies>

If any mapping rules or the syntax used by an attribute type are not supported on the LDAP server, the ldapschema utility checks if the appropriate substitution rule is specified in the /etc/opt/ldapux/schema/map-rules.xml file. If it is specified, ldapschema locates the first available matching rule or syntax supported on the LDAP server, and uses it in the attribute type definition instead. If the substitution rule is not specified, or if the substitution matching rules or syntaxes are not supported on the LDAP server, ldapschema checks if the default substitution can be used.

Attributes vendor, versionGreaterOrEqual, and versionLessThan can be used to specify directory-specific information stored in <defaultSubMatchingRule> and <defaultSubSyntax> tags. If the default substitution is supported on the LDAP server, it is used in the attribute type definition instead. If even the default substitution is not supported on the LDAP server, the attribute type cannot be added to the LDAP directory server schema.

For example, an attribute type with IA5String syntax (1.3.6.1.4.1.1466.115.121.1.26) is being installed on ADS, where this syntax oid is not supported. ldapschema will try using the first equivalent or substitution syntax supported by the target LDAP server as specified in /etc/opt/ldapux/schema/map-rules.xml file. The specified equivalent syntax 2.5.5.5 with oMSyntax value of 22 is supported on ADS and will be used in place of the original syntax value when installing this attribute type definition on ADS.

As another example, for instance, attribute type with a Boolean equality matching rule is being installed on the LDAP server where this matching rule is not supported. Since no substitution policy is specified for this matching rule in the example above, the default substitution matching rule, caseIgnoreMatch, would be used instead, if the LDAP server supports it. If the LDAP server does not support caseIgnoreMatch, that attribute type cannot be installed on the LDAP server, unless its definition is modified to use another supported equality matching rule.

If the -s option is specified, syntax substitution in attribute types is disabled. Any attribute types with unsupported LDAP syntaxes will not be added to the LDAP directory server schema. The -m option disables matching rule substitution. Any attribute types with unsupported matching rules will not be added to the LDAP directory server schema.

EXAMPLES

To query the status of RFC 3712 schema on the Red Hat Directory Server 7.1, execute the following command:

ldapschema  -q /etc/opt/ldapux/schema/rfc3712.xml  -T rhds  -V 7.1 

Note that LDAP directory server version number bears no effect unless also specified in the XML files being processed. Version specification must follow the same format as version specification used in the /etc/opt/ldapux/schema/rfc3712.xml and /etc/opt/ldapux/schema/map-rules.xml files.

To extend Windows 2000 Active Directory Server with custom SampleA schema, follow the following procedure:

1.

Create schema definition file containing attribute type and object class definitions for SampleA schema (that is, /etc/opt/ldapux/schema/sampleA.xml).

2.

Recommended : Query the current status of SampleA schema on the server:

ldapschema -q /etc/opt/ldapux/schema/sampleA.xml -T ads -V 2000 -D "<binddn>" -j /tmp/secret.txt

3.

Based on the results produced by Step 2, correct any invalid definitions.

4.

Extend the Active Directory Server schema with new SampleA schema elements by executing the following command:

ldapschema -e /etc/opt/ldapux/schema/sampleA.xml -T ads -V 2000 -D "<binddn>" -j /tmp/secret.txt

Note that LDAP directory server version number bears no effect unless also specified in the XML files being processed. Version specification must follow the same format as version specification used in the /etc/opt/ldapux/schema/sampleA.xml, /etc/opt/ldapux/schema/schema-ads.xml, and /etc/opt/ldapux/schema/map-rules.xml files.

RETURN VALUES

The ldapschema utility returns the following values:

0: Successful completion.
1: Failure.

In addition, ldapschema prints to STDOUT the overall status of the schema being queried or extended. Based on the schema status, any combination of the following messages is displayed. Detailed explanations of each message are specified in the square brackets following the message body text.

Schema Status Messages

SCHEMA_NEW:: file "<schema>" contains attribute types and object classes that are not defined in the LDAP server schema.

[The SCHEMA_NEW message indicates all attribute types and object classes defined in the <schema> file are new to the LDAP directory server. The SCHEMA_NEW message indicates none of the specified definitions are currently installed in the LDAP server schema.]

----------------------------------------------------------------------

SCHEMA_EXISTS:: All attribute types and object classes defined in file "<schema>" are already part of the LDAP server schema.

[The SCHEMA_EXISTS message indicates the schema specified in the <schema> file is already installed on the LDAP directory server. All attribute types and object classes defined in the <schema> file are already part of the schema on the LDAP directory server. Only attribute types and object classes with new and unique numeric oids and names can be added to the LDAP server schema. Check the messages containing ATTRIB_FOUND and OBJECT_FOUND described below for details. Since the definitions specified in the <schema> file are already installed in the LDAP server schema, the ldapschema utility will make no changes to the LDAP directory server schema.]

----------------------------------------------------------------------

SCHEMA_FOUND:: subset of attribute types and/or object classes defined in file "<schema>" are already part of the LDAP server schema.

[The SCHEMA_FOUND message indicates one or more attribute type or object class definitions specified in the <schema> file are already installed in the LDAP server schema. Such elements will be excluded from being extended on the LDAP server. Only attribute types and object classes with new and unique numeric oids and names can be added to the LDAP server schema. Check the messages containing ATTRIB_FOUND and OBJECT_FOUND described below for details.

The ldapschema utility may install any remaining new elements that are not already defined in the LDAP server schema if both of the following two conditions are met.

1.

The LDAP schema defined in the <schema> file is compatible with the LDAP server schema. The two schemas are compatible if the definitions of any elements found in the LDAP server schema match their definitions specified in the <schema> file.

If the SCHEMA_MISMATCH message is displayed, the two schemas are not compatible. This means one or more elements installed on the LDAP server have definitions different from those specified in the <schema> file. Installation of any remaining new elements is not recommended. See definition of the SCHEMA_MISMATCH message below.

If the SCHEMA_MISMATCH message is not displayed, the two schemas are compatible. The schema specified in the <schema> file partially exists on the LDAP server schema, and can be extended with any remaining new valid attribute type and object class definitions.

2.

The LDAP schema defined in the <schema> file is valid.

If the SCHEMA_INVALID message is displayed, one or more definitions specified in the <schema> file are invalid and cannot be added to the LDAP server schema. Such definitions need to be corrected before the new schema elements can be extended on the LDAP server.

If the SCHEMA_INVALID message is not displayed, the schema definition in the <schema> file is valid. It partially exists on the LDAP server schema, and can be extended with any remaining new valid attribute type and object class definitions.]

----------------------------------------------------------------------

SCHEMA_MISMATCH:: file "<schema>" contains one or more attribute types or object classes already installed in the LDAP server schema with incompatible (that is, mismatching) definitions. Review the messages above and verify definitions of any mismatching schema elements. If any remaining valid schema elements defined in the "<schema>" file exist, use the force flag ("-F" option) to add them to the LDAP server schema.

[The SCHEMA_MISMATCH message indicates one or more attribute types or object classes defined in the <schema> file are already installed on the LDAP directory server, however, their definitions do not match. This means that some attribute type or object class definitions specified in the <schema> file do not match the LDAP server schema definitions of the elements with the same numeric oids or names. Check the messages containing ATTRIB_MISMATCH and OBJECT_MISMATCH described below for the exact instances of attribute types and object classes, respectively, causing the schema mismatch.

The mismatch is caused by any differences in element definitions, such as equality matching rule, single-valued setting, attribute syntax, object class type, attribute types an object class includes, etc. For example, if an attribute type 'sampleAttributeA' installed on the LDAP directory server specifies IA5 String syntax, but the definition of 'sampleAttributeA' in the <schema> file specifies Unicode String syntax, the two attribute types are mismatching. HP does not recommend installing schemas containing mismatching definitions. If the <schema> file defines any new valid attribute types or object classes that are not present in the LDAP directory server schema and you would like to install them anyway, use the force flag (the -F option) to add them to the LDAP server schema.]

----------------------------------------------------------------------

SCHEMA_OK:: all attribute types and object classes defined in "<schema>" file are valid.

[The SCHEMA_OK message indicates the definitions of attribute types and object classes specified in the <schema> file have valid XML format and conform to the DTD template and the LDAP directory server schema policies. This message also indicates no mismatching/incompatible definitions specified in the <schema> file are installed on the LDAP server.]

----------------------------------------------------------------------

SCHEMA_INVALID:: file "<schema>" contains one or more invalid definitions of attribute types and/or object classes. Review the messages above and correct any errors in the schema definition file.

[The SCHEMA_INVALID message indicates some of the attribute types and/or object classes specified in the <schema> file have invalid definitions. This condition occurs if the definition does not conform to the LDAP directory server schema policies or the DTD template. Review the Defining Attribute Types and Defining Object Classes sections for details. Also, check the messages containing ATTRIB_INVALID, ATTRIB_UNRESOLVED, OBJECT_INVALID and OBJECT_UNRESOLVED described below for details.

Any invalid elements and any elements that depend on them will be excluded from being extended on the LDAP server. For example, if an attribute type 'sampleAttributeA' has an invalid <usage> value, and an object class 'sampleObjectO' includes 'sampleAttributeA' as a mandatory or an optional attribute, neither 'sampleAttributeA' nor 'sampleObjectO' can be added to the LDAP server schema until the <usage> value is corrected. Running the ldapschema utility in verbose mode (the -v option) can provide additional information about invalid attribute type and object class definitions. HP recommends correcting any invalid definitions before extending the LDAP directory server schema with any remaining new valid definitions.]

----------------------------------------------------------------------

SCHEMA_REJECTED:: file "<schema>" contains no valid attribute type or object class definitions that can be added to the LDAP server schema. It defines elements already installed in the LDAP server schema, or contains invalid definitions that hence cannot be installed. Review the messages above and correct any errors in the schema definition file.

[The SCHEMA_REJECTED message indicates no attribute type or object class definitions specified in the <schema> file meet the requirement of being both new and valid, and, therefore, cannot be added to the LDAP server schema. Any invalid definitions need to be corrected before they can be added to the LDAP directory server schema.

Check the messages containing ATTRIB_INVALID, ATTRIB_UNRESOLVED, ATTRIB_MISMATCH, OBJECT_INVALID, OBJECT_UNRESOLVED, OBJECT_MISMATCH, SCHEMA_INVALID and SCHEMA_MISMATCH for details on which attribute type and object class definitions prevent the schema from being installed.

If the <schema> file contains any mismatching or invalid definitions, HP does not recommend installing the schema on the LDAP server.]

----------------------------------------------------------------------

Attribute Type Status Messages

ATTRIB_INVALID:: attribute type definition is missing a numericoid. Edit the schema definition file to specify one <oid> tag and its value for every <attributeTypeDefinition> definition.

[This message indicates the <oid> tag and its value need to be specified in the <attributeTypeDefinition> definition in the <schema> file.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type definition is missing a name. Edit the schema definition file to specify at least one <name> tag and its value for every <attributeTypeDefinition> definition.

[This message indicates the <name> tag and its value need to be specified in the <attributeTypeDefinition> definition in the <schema> file.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" specifies an unrecognized <usage> value. Supported values are: directoryOperation, distributedOperation, dSAOperation or userApplications.

[This message indicates the <usage> tag value needs to be corrected in the <attributeTypeDefinition> definition in the <schema> file. Possible attribute type usage values are directoryOperation, distributedOperation, dSAOperation or userApplications. Any other usage values are rejected. If the <usage> tag is not specified in the <attributeTypeDefinition> definition, the default attribute type usage value is userApplications. See RFC 2252 for details.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" has an invalid numericoid. Edit the schema definition file to specify an RFC 2252 compliant <oid> value for this attribute type. Valid numericoid must consist of digits (0-9) that can be separated by a period (.). Leading zeroes are not allowed. See RFC 2252 for details.

[This message indicates the <oid> tag value needs to be corrected in the <attributeTypeDefinition> definition in the <schema> file. The <oid> value must be compliant with RFC 2252. See RFC 2252 for details.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" has an invalid name. Edit the schema definition file to specify an RFC 2252 compliant <name> value for this attribute type. Valid name characters include letters (A-z), digits (0-9), semicolons (;) and dashes (-). Valid name must begin with an alphabet letter (A-z). See RFC 2252 for details.

[This message indicates the <name> tag value needs to be corrected in the <attributeTypeDefinition> definition in the <schema> file. The attribute type name value must be compliant with RFC 2252. See RFC 2252 for details.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" must have the same usage (<usage> tag) value as its supertype. Edit the schema definition file to correct the usage value for this attribute or its supertype.

[If the attribute type specifies a supertype, both this attribute type and its supertype must have the same <usage> tag value. This message indicates the <usage> tag value of the specified attribute type and the <usage> tag value of its supertype do not match. Edit the <schema> file to correct the discrepancy.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" is missing a syntax value. Edit the schema definition file to specify a syntax (<syntax> tag) value, or a valid supertype (<subTypeOf> tag) value.

[Most LDAP directory servers require attribute type definitions to specify either the syntax value or a supertype value. This message indicates that the specified attribute type definition in the <schema> file does not specify either of these values. Edit the <schema> file to specify either the <syntax> tag and its value, or a <subTypeOf> tag and its value in the specified attribute type definition.]

----------------------------------------------------------------------

ATTRIB_INVALID:: attribute type "<attribute name>" cannot be labeled as obsolete (<obsolete> tag) if any other attribute types or object classes depend on it. Edit the schema definition file to remove the <obsolete> tag from this attribute type definition in order for it to be added to the LDAP server schema.

[Obsolete attribute types cannot be added to the LDAP directory server schema if any other attribute types or object classes depend on them. This messages indicates the given attribute type cannot specify the <obsolete> tag in its definition if it is used as a supertype in any other attribute types, or if it is used as a mandatory or optional attribute in any object classes. Edit the <schema> file to correct this discrepancy.]

----------------------------------------------------------------------

ATTRIB_UNRESOLVED:: super-type used in "<attribute name>" attribute type definition is not defined in any LDAP schema.

[This message indicates the supertype specified with the <subTypeOf> tag in the given attribute type definition is undefined. Edit the <schema> file to correct the name of the supertype in the attribute type definition. The supertype used in the attribute type definition must be defined either in the LDAP directory server schema or in the <schema> file before this attribute type can be installed.]

----------------------------------------------------------------------

ATTRIB_UNRESOLVED:: matching rule "<matching rule name>" used in "<attribute name>" attribute type definition cannot be mapped because "-m -" option is specified. This matching rule is not supported on the LDAP server.

[This message indicates the matching rule specified with the <equality>, <ordering> or <substr> tag in the given attribute type definition is not supported on the LDAP directory server. Option -m - disables matching rule substitution in attribute types. Edit the <schema> file to specify an alternate matching rule supported on the LDAP server, or execute the ldapschema utility without the -m - option to substitute this matching rule with an alternative matching rule supported on the LDAP server.]

----------------------------------------------------------------------

ATTRIB_UNRESOLVED:: matching rule "<matching rule name>" used in "<attribute name>" attribute type definition cannot be mapped. This matching rule is not supported on the LDAP server.

[This message indicates the matching rule specified with the <equality>, <ordering> or <substr> tag in the given attribute type definition is not supported on the LDAP directory server. The default substitution matching rule specified in the /etc/opt/ldapux/schema/map-rules.xml file is not supported on the LDAP directory server either. Edit the <schema> file to specify an alternate matching rule supported on the LDAP server, or edit the /etc/opt/ldapux/schema/map-rules.xml file to specify a default substitution matching rule supported on the LDAP server.]

----------------------------------------------------------------------

ATTRIB_UNRESOLVED:: LDAP syntax "<syntax oid>" used in "<attribute name>" attribute type definition cannot be mapped because "-s -" option is specified. This LDAP syntax is not supported on the LDAP server.

[This message indicates the LDAP syntax specified with the <syntax> tag in the given attribute type definition is not supported on the LDAP directory server. Option -s - disables syntax substitution in attribute types. Edit the <schema> file to specify an alternate syntax supported on the LDAP server, or execute the ldapschema utility without the -s - option to substitute this syntax with an alternative syntax supported on the LDAP server.]

----------------------------------------------------------------------

ATTRIB_UNRESOLVED:: LDAP syntax "<syntax oid>" used in "<attribute name>" attribute type definition cannot be mapped. This LDAP syntax is not supported on the LDAP server.

[This message indicates the LDAP syntax specified with the <syntax> tag in the given attribute type definition is not supported on the LDAP directory server. The default substitution syntax specified in the /etc/opt/ldapux/schema/map-rules.xml file is not supported on the LDAP directory server either. Edit the <schema> file to specify an alternate syntax supported on the LDAP server, or edit the /etc/opt/ldapux/schema/map-rules.xml file to specify a default substitution syntax supported on the LDAP server.]

----------------------------------------------------------------------

ATTRIB_FOUND:: attribute type "<attribute name>" is already installed in the LDAP server schema.

[This message indicates the LDAP directory server schema already includes a definition of an attribute type definition with the same numeric oid or name. If the ldapschema utility is executed in the extend mode, the given attribute type will not be added to the LDAP directory server schema. This message is displayed in verbose mode only. Also, the following message will appear:]

----------------------------------------------------------------------

ATTRIB_REJECTED:: attribute type "<attribute name>" will not be added to the LDAP server schema because it is already part of the LDAP schema.

[This message indicates the LDAP directory server schema already includes a definition of an attribute type definition with the same numeric oid or name.]

----------------------------------------------------------------------

ATTRIB_REJECTED:: attribute type "<attribute name>" will not be added to the LDAP server schema because its definition is invalid.

[This message indicates definition of the specified attribute type is invalid. If the ldapschema utility is executed in the extend mode, the given attribute type will not be added to the LDAP directory server schema. Check the messages containing ATTRIB_INVALID for details.]

----------------------------------------------------------------------

ATTRIB_MISMATCH:: definition of attribute type "<attribute name>" is incompatible with the definition already installed in the LDAP server schema.

[The ATTRIB_MISMATCH message indicates the attribute type is already installed on the LDAP directory server, however, its definition does not match the LDAP server schema definition of the attribute type with the same numeric oid or name. The mismatch can be caused by any differences in the attribute type definition. For example, if an attribute type 'sampleAttributeB' installed on the LDAP directory server is multi-valued, but the definition of 'sampleAttributeB' in the <schema> file specifies the <singleValued/> tag, the two attribute types are mismatching. HP does not recommend installing a schema containing mismatching definitions. If the <schema> file defines any new valid attribute types or object classes that are not present in the LDAP directory server schema and you would like to install them anyway, use the force flag (the -F option) to add them to the LDAP server schema.]

----------------------------------------------------------------------

Object Class Status Messages

OBJECT_INVALID:: object class definition is missing a numericoid. Edit the schema definition file to specify one <oid> tag and its value for every <objectClassDefinition> definition.

[This message indicates the <oid> tag and its value need to be specified in the <objectClassDefinition> definition in the <schema> file.]

----------------------------------------------------------------------

OBJECT_INVALID:: object class definition is missing a name. Edit the schema definition file to specify at least one <name> tag and its value for every <objectClassDefinition> definition.

[This message indicates the <name> tag and its value need to be specified in the <objectClassDefinition> definition in the <schema> file.]

----------------------------------------------------------------------

OBJECT_INVALID:: object class "<object name>" has an invalid numericoid. Edit the schema definition file to specify an RFC 2252 compliant <oid> value for this object class. Valid numericoid must consist of digits (0-9) that can be separated by a period (.). Leading zeroes are not allowed. See RFC 2252 for details.

[This message indicates the <oid> tag value needs to be corrected in the <objectClassDefinition> definition in the <schema> file. The <oid> value must be compliant with RFC 2252. See RFC 2252 for details.]

----------------------------------------------------------------------

OBJECT_INVALID:: object class "<object name>" has an invalid name. Edit the schema definition file to specify an RFC 2252 compliant <name> value for this object class. Valid name characters include letters (A-z), digits (0-9), semicolons (;) and dashes (-). Valid name must begin with an alphabet letter (A-z). See RFC 2252 for details.

[This message indicates the <name> tag value needs to be corrected in the <objectClassDefinition> definition in the <schema> file. The object class name value must be compliant with RFC 2252. See RFC 2252 for details.]

----------------------------------------------------------------------

OBJECT_INVALID:: object class "<object name>" specifies an invalid object type value. Edit the schema definition file to modify the value specified with the <type> tag, which can be one of the following: STRUCTURAL, AUXILIARY, ABSTRACT.

[This message indicates the <type> tag value needs to be corrected in the <objectClassDefinition> definition in the <schema> file. Possible object class type values are STRUCTURAL, AUXILIARY or ABSTRACT. Any other type values are rejected. If the <type> tag is not specified in the <objectClassDefinition> definition, the default object class type value is STRUCTURAL. See RFC 2252 for details.]

----------------------------------------------------------------------

OBJECT_INVALID:: object class "<object name>" cannot be labeled as obsolete (<obsolete> tag) if any other object classes depend on it.

[Obsolete object classes cannot be added to the LDAP directory server schema if any other object classes depend on them. This messages indicates the given object class cannot specify the <obsolete> tag in its definition if it is used as a superclass in any other object classes. Edit the <schema> file to correct this discrepancy.]

----------------------------------------------------------------------

OBJECT_INVALID:: abstract object class "<object name>" cannot have a non-abstract superclass "<superclass object name>".

[Abstract object classes can specify only abstract superclasses. This message indicates the specified abstract object class specifies a superclass (using a <subClassOf> tag) that is not abstract. Edit the <schema> file to correct this discrepancy.]

----------------------------------------------------------------------

OBJECT_INVALID:: structural object class "<object name>" cannot have an auxiliary superclass "<superclass object name>".

[Structural object classes can specify only abstract or structural superclasses. Structural object classes cannot specify auxiliary superclasses. This message indicates the specified structural object class specifies a superclass (using a <subClassOf> tag) that is auxiliary. Edit the <schema> file to correct this discrepancy.]

----------------------------------------------------------------------

OBJECT_INVALID:: auxiliary object class "<object name>" cannot have a structural superclass "<superclass object name>".

[Auxiliary object classes can specify only abstract or auxiliary superclasses. Auxiliary object classes cannot specify structural superclasses. This message indicates the specified auxiliary object class specifies a superclass (using a <subClassOf> tag) that is structural. Edit the <schema> file to correct this discrepancy.]

----------------------------------------------------------------------

OBJECT_UNRESOLVED:: super-class used in "<object name>" object class definition is not defined in any LDAP schema.

[This message indicates the superclass specified with the <subClassOf> tag in the given object class definition is undefined. Edit the <schema> file to correct the name of the superclass in the object class definition. The superclass used in the object class definition must be defined either in the LDAP directory server schema or in the <schema> file before this object class can be installed.]

----------------------------------------------------------------------

OBJECT_UNRESOLVED:: mandatory attribute used in "<object name>" object class definition is not defined in any LDAP schema.

[This message indicates the mandatory attribute type specified with the <must> tag in the given object class definition is undefined. Edit the <schema> file to correct the name of the mandatory attribute in the object class definition. The mandatory attribute used in the object class definition must be defined either in the LDAP directory server schema or in the <schema> file before this object class can be installed.]

----------------------------------------------------------------------

OBJECT_UNRESOLVED:: optional attribute used in "<object name>" object class definition is not defined in any LDAP schema.

[This message indicates the optional attribute type specified with the <may> tag in the given object class definition is undefined. Edit the <schema> file to correct the name of the optional attribute in the object class definition. The optional attribute used in the object class definition must be defined either in the LDAP directory server schema or in the <schema> file before this object class can be installed.]

----------------------------------------------------------------------

OBJECT_FOUND:: object class "<object name>" is already installed in the LDAP server schema.

[This message indicates the LDAP directory server schema already includes a definition of an object class definition with the same numeric oid or name. If the ldapschema utility is executed in the extend mode, the given object class will not be added to the LDAP directory server schema. This message is displayed in verbose mode only. Also, the following message will appear:]

----------------------------------------------------------------------

OBJECT_REJECTED:: object class "<object name>" will not be added to the LDAP server schema because it is already part of the LDAP schema.

[This message indicates the LDAP directory server schema already includes a definition of an object class definition with the same numeric oid or name.]

----------------------------------------------------------------------

OBJECT_REJECTED:: object class "<object name>" will not be added to the LDAP server schema because its definition is invalid.

[This message indicates definition of the specified object class is invalid. If the ldapschema utility is executed in the extend mode, the given object class will not be added to the LDAP directory server schema. Check the messages containing OBJECT_INVALID for details.]

----------------------------------------------------------------------

OBJECT_MISMATCH:: definition of object class "<object name>" is incompatible with the definition already installed in the LDAP server schema.

[The OBJECT_MISMATCH message indicates the object class is already installed on the LDAP directory server, however, its definition does not match the LDAP server schema definition of the object class with the same numeric oid or name. The mismatch can be caused by any differences in the object class definition. For example, if an object class 'sampleObjectB' installed on the LDAP directory server has two optional attributes ( 'sampleAttributeA' and 'sampleAttributeB' ), but the definition of 'sampleObjectB' in the <schema> file specifies three optional attributes ('sampleAttributeA','sampleAttributeB'and'sampleAttributeC' ), the two attribute types are mismatching. HP does not recommend installing a schema containing mismatching definitions. If the <schema> file defines any new valid attribute types or object classes that are not present in the LDAP directory server schema and you would like to install them anyway, use the force flag (the -F option) to add them to the LDAP server schema.]

----------------------------------------------------------------------

Matching Rule Status Messages

RULE_INVALID:: matching rule is missing a numericoid. Edit the schema definition file to specify one <oid> tag and its value for every <matchingRuleDefinition> definition.

[This message indicates the <oid> tag and its value need to be specified in the <matchingRuleDefinition> definition in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility.]

----------------------------------------------------------------------

RULE_INVALID:: matching rule is missing a name. Edit the schema definition file to specify at least one <name> tag and its value for every <matchingRuleDefinition> definition.

[This message indicates the <name> tag and its value need to be specified in the <matchingRuleDefinition> definition in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility.]

----------------------------------------------------------------------

RULE_INVALID:: matching rule is missing an LDAP syntax. Edit the schema definition file to specify one <syntax> tag and its value for every <matchingRuleDefinition> definition.

[This message indicates the <syntax> tag and its value need to be specified in the <matchingRuleDefinition> definition in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility.]

----------------------------------------------------------------------

RULE_UNRESOLVED:: matching rule "<matching rule name>" used in "<attribute name>" attribute type definition is not supported on the LDAP server. Matching rule "<substitute matching rule name>" will be used instead.

[This message indicates the specified matching rule <matching rule name> is not supported on the LDAP directory server. However, it was successfully mapped with a higher level (less specific) matching rule supported by that server, <substitute matching rule name> , as specified in the /etc/opt/ldapux/schema/map-rules.xml file. The attribute types which uses this matching rule with the <equality>, <ordering> or <substr> tags will use be queried or extended on the LDAP directory server using the <substitute matching rule name>.]

----------------------------------------------------------------------

LDAP Syntax Status Messages

SYNTAX_INVALID:: LDAP syntax is missing a numericoid. Edit the schema definition file to specify one <oid> tag and its value for every <syntaxDefinition> definition.

[This message indicates the <oid> tag and its value need to be specified in the <syntaxDefinition> definition in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility.]

----------------------------------------------------------------------

SYNTAX_INVALID:: LDAP syntax is missing an oMSyntax value. Edit the schema definition file to specify one <oMSyntax> tag and its value for every <syntaxDefinition> definition.

[This message indicates the <oMSyntax> tag and its value need to be specified in the <syntaxDefinition> definition in the /etc/opt/ldapux/schema/schema-ds_type.xml file, where ds_type corresponds to the same value specified with the -T option on the command line when executing the ldapschema utility. The <oMSyntax> tag is required for LDAP syntax definitions supported by the Active Directory Server.]

----------------------------------------------------------------------

SYNTAX_UNRESOLVED:: LDAP syntax "<syntax oid>" used in "<attribute name>" attribute type definition is not supported on the LDAP server. LDAP syntax "<substitute syntax oid>" will be used instead.

[This message indicates the specified syntax <syntax oid> is not supported on the LDAP directory server. However, it was successfully mapped with a higher level (more inclusive) syntax supported by that server, <substitute syntax oid>, as specified in the /etc/opt/ldapux/schema/map-rules.xml file. The attribute types which uses this syntax with the <syntax> tag will use be queried or extended on the LDAP directory server using the <substitute syntax oid>.]

----------------------------------------------------------------------

FILES

/opt/ldapux/bin/ldapschema 
/etc/opt/ldapux/schema/schema.dtd 
/etc/opt/ldapux/schema/map-rules.xml 
/etc/opt/ldapux/schema/schema-ads.xml 
/etc/opt/ldapux/schema/rfc2256.xml 
/etc/opt/ldapux/schema/rfc2307.xml 
/etc/opt/ldapux/schema/rfc2307-bis.xml 
/etc/opt/ldapux/schema/rfc2926.xml 
/etc/opt/ldapux/schema/rfc3712.xml 

ldapschema(1)

Technical documentation

» Table of Contents

» Index

NAME

SYNOPSIS

DESCRIPTION

Required Command Options

Additional Options (Optional)

SECURITY

CONFIGURATION VARIABLES

SCHEMA DEFINITION FILE

Defining Attribute Types

Defining Object Classes

Predefined Schema Definition Files

SPECIFYING DIRECTORY-SPECIFIC INFORMATION

LDAP DIRECTORY SERVER DEFINTION FILE

Defining LDAP Syntaxes

Defining Matching Rules

MAPPING UNSUPPORTED MATCHING RULES AND LDAP SYNTAXES

EXAMPLES

RETURN VALUES

Schema Status Messages

Attribute Type Status Messages

Object Class Status Messages

Matching Rule Status Messages

LDAP Syntax Status Messages

FILES

SEE ALSO