At this point, we have a SLAPD server configured and running, and we have an
ldap.conf file that specifies many of the defaults for our tools. Now we are going to query the directory and fetch some information.
We haven’t actually put any entries in our database, though. So what will we query? SLAPD does provide directory-based access to certain information, including currently-loaded schemas and subschemas, configuration information, and a special record called the root DSE. The root DSE (DSA-Specific Entry, where DSA stands for Directory Service Agent—the technical term for an LDAP server) is a special entry that provides information about the server itself. Like all other entries in an LDAP, the root DSE has a DN. Unlike all other entries, the root DSE’s DN is an empty string.
Why use an empty string for a DN? The answer is simple: any client can connect to the server and find out about what sorts of operations the server supports, and all of this can be done without requiring the client to know anything about the directory structures hosted on the server. All it must do is perform a search with an empty DN.
The LDAPv3 Directory Information Models specification (RFC 4512) states that a root DSE with an empty DN be provided by any standards-compliant LDAP server.
The root DSE contains information about what version of the LDAP protocol the server supports, what extensions to that protocol the server supports, and other useful information that helps clients fruitfully interact with the directory.
We will search for this entry using the
ldapsearch command-line client.
Because of the restrictive way in which we set up our ACLs, we will have to authenticate to the directory in order to see the root DSE. And since we have only one defined user, the directory manager, we will log in as that user and perform a search for the root DSE:
$ ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
All of the above should go on one line at a shell prompt. In order to do the search, we must specify several different parameters:
-x: This tells the server to use simple authentication (instead of the more complicated, but more secure, SASL authentication).
-W: This tells the client to prompt us for an interactive password. The client will give the following prompt:
Enter LDAP Password:
dc=com': This specifies the DN that we want to use to connect to the directory. In this case, we are using the directory manager account.
-b "": This sets the base DN for the search. In the
ldap.conffile we set the default base to be
dc=example,dc=com. But to get the root DSE, which is not under
dc=example,dc=com, we need to specify an empty search base.
-s base: This indicates that we want to search for just one (base) entry—the entry with the DN specified in the
-bparameter (the empty DN of the root DSE).
When we run this search, this is the result returned from the server:
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
At the top of the result is a summary of how the search was processed. The highlighted portion shows the root DSE entry. The server returned three attributes: the
dn (which is empty) and two object class specifications.
The last section, beneath the highlighted section, displays a summary, including how many records were returned (two: the DSE entry and the summary) and the error code (
0 for success).
This record is sparse, containing only a few attributes. And it doesn’t give us much information about the directory’s configuration or capabilities. But the root DSE contains much more information than appears here. How to we get at that information?
To get more extensive information out of the root DSE, we need to query for all of the operational attributes for the record.
Operational attributes, as explained in Chapter 1, are attributes that are intended for internal use. RFC 4512 states that many of the root DSE’s attributes be treated as operational attributes.
Here’s a modified version of the search that adds a filter for any object class
'(objectclass=*)', and a request for all operational attributes (
+). Since we are using the asterisk character (
*) in the filter, the filter must be enclosed in single quotes to avoid shell expansion:
$ ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base (objectclass=*)' +
The output of this command looks something like this:
Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=example,dc=com supportedControl: 184.108.40.206.4.1.4220.127.116.11.1 supportedControl: 2.16.840.1.113718.104.22.168 supportedControl: 2.16.840.1.113722.214.171.124 supportedControl: 126.96.36.199.4.1.4188.8.131.52 supportedControl: 1.2.840.1135184.108.40.2069 supportedControl: 1.2.8220.127.116.114810.2.3 supportedControl: 1.2.818.104.22.16844810.2.3 supportedControl: 22.214.171.124.1.13.2 supportedControl: 126.96.36.199.1.13.1 supportedControl: 188.8.131.52.1.12 supportedExtension: 184.108.40.206.4.1.4220.127.116.11 supportedExtension: 18.104.22.168.4.1.422.214.171.124 supportedFeatures: 126.96.36.199.1.14 supportedFeatures: 188.8.131.52.4.1.4184.108.40.206 supportedFeatures: 220.127.116.11.4.1.418.104.22.168 supportedFeatures: 22.214.171.124.4.1.4126.96.36.199 supportedFeatures: 188.8.131.52.4.1.4184.108.40.206 supportedFeatures: 220.127.116.11.4.1.418.104.22.168 supportedLDAPVersion: 3 supportedSASLMechanisms: NTLM supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 entryDN: subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Again the results above are for the same record—the root DSE record. Only now we get a much bigger record, containing all of the operational attributes for the record.
The information returned from the server this time includes lists of supported features, extensions, controls, and SASL mechanisms (most of which are not particularly human-friendly).
While many of the items in this record are not useful to us right now, some can be very useful in practice. For example, the supportedLDAPVersion attribute indicates what version of the LDAP protocol this server uses. The namingContexts attribute gives the base DN for each directory information tree hosted on this server. The supportedSASLMechanisms list tells us what sort of authentication routines can be performed when doing a SASL bind.
Some LDAP client programs will even query the root DSE and use this information to determine what kinds of operations the server will support, adjusting the client’s own features to the level of service provided by the server.
What is most important about this exercise though, is that we have verified that we have successfully configured the SLAPD server, as well as the OpenLDAP clients. We have connected, authenticated (using a simple bind), and retrieved a record from the LDAP server.