5.4 Determining a Server's Capabilities

Chapter 2 alluded to two new LDAPv3 features: the subschemaSubentry and the rootDSE objects. Both of these objects allow clients to find out information about a previously unknown directory server.

The rootDSE object contains information about features such as the server naming context, implemented SASL mechanisms, and supported LDAP extensions and controls. LDAPv3 requires that the rootDSE has an empty DN. To list the rootDSE, perform a base-level search using a DN of "". OpenLDAP will provide only values held by the rootDSE if the search requests that operational attributes be returned, so the + character is appended to the search request.

$ ldapsearch -x -s base -b "" "(objectclass=*)" +
      
dn:
structuralObjectClass: OpenLDAProotDSE
namingContexts: dc=plainjoe,dc=org
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.2
supportedControl: 1.2.826.0.1.334810.2.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
subschemaSubentry: cn=Subschema

This list can change over time and will vary from server to server. Our example shows us that this server supports:

• StartTLS (OID 1.3.6.1.4.1.1466.20037) and two other extended operations

• ManageDsaIT (OID 2.16.840.1.113730.3.4.2) and two other LDAP controls

• LDAPv3 operations only

• The GSSAPI, DIGEST-MD5, and CRAM-MD5 SASL mechanisms

• A single naming context of "dc=plainjoe,dc=org"

There may be additional attributes and values, depending on the LDAP server.

The SubSchemaSubentry attribute specifies the base search suffix for querying the schema supported by the server. This means that clients can verify that the server supports a given matching rule, attribute type, or object class prior to performing an operation that depends on a certain characteristic. The output from the following ldapsearch command shows the kind of information that is in the SubSchemaSubentry tree. Since this tree contains many entries, I've shortened it for convenience.

$ ldapsearch -D "cn=Manager,dc=plainjoe,dc=org"
> -w n0pass -x -s base -b "cn=SubSchema" \
> "(objectclass=*)" +
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
. . . 
matchingRules: ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 )
 . . . 
attributeTypes: ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) 
EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.50 )
 . . . 
objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY  
( userPassword $ telephoneNumber $ seeAlso $ description ) )
 . . .

You can't modify the schema supported by an OpenLDAP directory server by modifying entries contained in the cn=SubSchema tree.