LDAP System Administration [Electronic resources] نسخه متنی

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.