Many LDAP servers provide information about their configuration and functional abilities. This information is stored in such a way that LDAP clients can directly access it using a search operation. For example, a client can fetch the root DSE record to find out the basic capabilities of the server. It can also access the subschema of the server and find out what object classes, syntaxes, matching rules, and attributes are supported.
The root DSE (DSA-Specific Entry, where DSA stands for Directory Service Agent) is a special entry that provides information about the server itself. The DN of the root DSE is an empty string (""). To retrieve it we need a carefully-crafted LDAP search that will set an empty search base and then retrieve that root entry:
$ ldapsearch -x -LLL -b '' -s base -W -D \ 'cn=Manager,dc=example,dc=com' '+'
Note that the base is set to an empty string, and the search scope is limited to the base record. These parameters combined have the effect of requesting only the record that has an empty DN. Also, since most of the attributes in the root DSE are operational attributes, we need to specify '+' at the end of the search.
The results of running this search look something like this:
dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=example,dc=com supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 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: NTLM supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 entryDN: subschemaSubentry: cn=Subschema
Among other things, this record gives us information about what controls, features, and extensions are understood by and enabled on the server. For example, there is a supportedFeature line that reads:
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
This line indicates that this LDAP server supports an LDAPv3 extension for Change Password operations as defined in RFC 3062 (http://www.rfc-editor.org/rfc/rfc3062.txt).
Using this information, a well-crafted LDAP client would be able to perform a server-side Change Password operation instead of changing the password on the client side and then using a Modify operation to send the change to the server.
Note
The advantage of the Change Password operation is in the server's storage. If the client changes a password through a Modify operation it must know in advance what types of encryption are supported on the server, it must do the encrypting itself, and then submit the encrypted password to the server. Usually, it is better to have the client securely contacting the server (over TLS, for example), and then using a Change Password operation so that the server can do the storage.
The root DSE record also points to the configuration (cn=config) and subschema (cn=subschema) records.
The subschema record is stored in cn=subschema. This record contains detailed information about the schemas supported by the server, including what types of matching rules it has available, what sort of syntaxes are allowed in attributes, and what attributes and object classes are recognized by the server.
This information can be used by client applications to correctly craft records or searches, and then correctly interpret the responses.
The subschema record can be retrieved with ldapsearch using the following command:
ldapsearch -x -LLL -b 'cn=subschema' -s base -W \ -D 'cn=Manager,dc=example,dc=com' '+'
In this example we request the desired record by setting the base DN to cn=config, and then requesting a search type of base (-b 'cn=subschema' -s base). This returns the exact record with the DN cn=subschema.
Also, most of the attributes we want are operational attributes, which means they will not be returned in a normal search, so at the end we specify '+' to indicate that we want the operational attributes.
The record returned looks like this:
dn: cn=Subschema
structuralObjectClass: subentry
createTimestamp: 20061216235843Z
modifyTimestamp: 20061216235843Z
ldapSyntaxes: ( 1.3.6.1.1.16.1 DESC 'UUID' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.1 DESC 'RFC2307 Boot Parameter' )
# ... lots of lines removed
objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson STRUCTURAL
MAY ( audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $
roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $
userPKCS12 ) )
objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.1.2 NAME
'olcHdbConfig' DESC 'HDB backend configuration'
SUP olcDatabaseConfig STRUCTURAL
MUST olcDbDirectory
MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbNoSync
$ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $
olcDbLinearIndex $ olcDbLockDetect $ olcDbMode $
olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree ) )
entryDN: cn=Subschema
subschemaSubentry: cn=SubschemaA subschema record contains all of the schema information and thus, it may be well over a thousand lines.
Subschema records can be particularly useful to learn about what schemas a server supports, or when developing and debugging custom schemas, as discussed in Chapter 6.
An experimental feature of OpenLDAP 2.3 (and one that will probably reach production quality in OpenLDAP 2.4) is the ability to store the LDAP configuration inside of the directory. To do this you must first re-create your configuration in LDIF format using a special configuration schema, and instruct SLAPD to read its configuration from this new LDIF file.
The configuration is stored inside of the directory with the DN cn=config. It can be accessed with a search similar to the one used in the previous section:
ldapsearch -x -LLL -b 'cn=config' -s base -W \ -D 'cn=Manager,dc=example,dc=com' '*'
In OpenLDAP 2.3, not all of the overlays and features of OpenLDAP work correctly with this new configuration style, and that is a significant drawback to its use. But improving this alternate configuration mechanism is a priority for development in OpenLDAP 2.4.
What might be the advantages of storing your configuration in the directory? Here are a few:
Easy access to configuration information through
ldapsearchand other LDAP clients.The ability to edit configuration information through directory tools like
ldapmodify.Replication support for SLAPD configuration. You may be able to use SyncRepl to synchronize directory configurations across the network.
If you would like to implement the new LDAP-based configuration file format, you can learn about it in the LDAP Administrators Guide at the OpenLDAP site: http://www.openldap.org/doc/admin23/slapdconf2.html.