LDAP-UX Client Services B.05.01 Administrator Guide for HP directory servers and Windows ADS

Line 8: <field attr="systemOnly">TRUE</field>
Line 9 </dsSpecific>
Line 10: </objectClassDefinition>
For the preceding example, on Windows Active Directory Server, this object class has a mandatory
attribute type, serverRole, and an optional attribute type, sampleAttribute. On all other
types of directory servers, this object class has a mandatory attribute type, userPassword and
an optional attribute, sampleAttribute. On Windows Active Directory Server, this object class
has the systemOnly attribute set to TRUE.
NOTE: Directory-specific attributes and values specified in <dsSpecific> fields are not validated.
You must ensure that 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.
Attributes and values specified in the <dsSpecific> fields override the default attribute type and
object class configurations. For example, on Windows Active Directory Server the default value
of the isDefunct attribute is set to False. If the following <dsSpecific> attribute is defined,
the specific setting will override the default setting and will result in the element being defunct.
<dsSpecific vendor="ads">
<field attr="isDefunct">TRUE</field>
</dsSpecific>
9.5.6 LDAP directory server definition file
To properly install new attribute types in an 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.
You can perform the following commands to determine if your directory server returns information
about supported matching rules and LDAP syntaxes
1. To determine <schema DN>, run the following command:
/opt/ldapux/bin/ldapsearch —b "" —s base “(objectclass=*)” subsechemasubentry
2. To obtain a list of supported matching rules and LDAP syntaxes, run the following command
using schema DN information obtained from step 1:
/opt/ldapux/bin/ldapsearch —b "<schema DN>" —s base “(objectclass=*)” \
matchingRules ldapSyntaxes
If the latter LDAP search in step 2 does not return a complete list of supported matching rules and
LDAP syntaxes, the directory server definitions must be specified in the /etc/opt/ldapux/
schema/schema-<ds_type>.xml file. The <ds_type> value must correspond to the same
value specified with the -T option on the ldapschema command line. The case defined in
<ds_type> must match identically to the case specified in the -T argument.
The LDAP directory server definition, enclosed by <dsSchemaDefintion> tags, optionally
specifies schema description, followed by any number of supported matching rules and LDAP
syntaxes definitions. For example, LDAP-UX provides the /etc/opt/ldapux/schema/
schema-ads.xml file that can be used to obtain a list of syntaxes and matching rules that
Windows ADS supports. Run ldapschema with the –T ads option, the corresponding directory
server definition is obtained from the /etc/opt/ldapux/schema/schema-ads.xml file.
After general schema information is specified, supported matching rules, if any, must be specified
followed by any supported LDAP syntaxes definitions.
9.5 Schema extension utility 371