HOME | BLOG | UnboundID LDAP SDK | Attributes | ldapsearch example
Directory Servers must provide information about themselves when asked, although that information is subject to access control. If a client knows the hostname and port upon which a directory server is listening, the client should query the root DSE for this information. The root DSE is that entry with zero RDNs, that is, it is the entry that is defined as a zero-length string. The root DSE contains information about the directory server in the form of attributes, some of which are multi-valued attributes.
The root DSE may contain information about the vendor, the naming contexts the server supports (or shadows), the request controls the server supports, the supported SASL mechanisms, features, schema location, and other information. Some of this information is listed in the table below.
'') and a scope of one or sub.To query the root DSE from the shell, use the following command (the old Sun Directory Server is not fully LDAP-compliant and does not
support the ‘(&)’ filter. If you are still using the Sun Directory Server ldapsearch supplied with Solaris (based on netscape), substitute
the filter (objectClass=*)):
$ ldapsearch --hostname hostname --port port --baseDn '' --searchScope base --sizeLimit 1 --timeLimit 10 '(&)' +
The legacy OpenLDAP syntax:
$ ldapsearch -x -LLL -H ldap://hostname:port -b '' -s base -z 1 -l 10 '(&)' +
In Java using the UnboundID LDAP SDK, this example retrieves the vendor name. Vendor name and vendor version may be provided by the directory server, but applications should not be coded with data dependencies, therefore, this information should be treated as informational, not normative. Some commercially available software uses vendor information from the root DSE to make decisions about interacting with the LDAP directory server - this a terrible idea and should be discouraged.
import com.unboundid.ldap.sdk.LDAPConnection;
import com.unboundid.ldap.sdk.RootDSE;
...
// Creates a new, unsecure, unauthentication connection
LDAPConnection ldapConnection = new LDAPConnection(hostname,port);
// Gets the root DSE
RootDSE rootDSE = ldapConnection.getRootDSE();
// Gets the vendor name
String vendorName = rootDSE.getVendorName();
Since the attributes defined in the root DSE are operational attributes they have to be requested explicitly, or + can be given as
an attribute name. Some servers will not return all operational attributes if + is used, however.
The following attributes might be available in the root DSE:
| Attribute Type | Description |
| altServer | a multi-valued attribute whose values are a list of alternative servers that can be used when the server is not available |
| namingContexts | a multi-valued attribute whose values are context prefixes that the server masters, hosts, or shadows |
| supportedControl | a multi-valued attribute whose values are request control OIDs that the server supports. Note: the supported controls are the request controls. The response controls the server supports need not be listed. Some incorrectly written software, notably ldap_cachemgr on Solaris and OpenSolaris, expects supported response controls to be listed in the root DSE, and fail to operate correctly in some cases when the response controls are not listed. |
| supportedExtension | a multi-valued attribute whose values are 'elective' features that the server supports. Listed as OIDs. |
| supportedLDAPVersion | a multi-valued attribute describing which LDAP protocol versions that the server supports. As of 10-JUL-2012, the only two versions of LDAP are '2' and '3'. |
| supportedSASLMechanisms | Clients may determine the SASL mechanisms a server supports by reading the 'supportedSASLMechanisms' attribute from the root DSE (DSA-Specific Entry) (RFC4512, Section 5.1). The values of this attribute, if any, list the mechanisms the server supports in the current LDAP session state. LDAP servers SHOULD allow all clients -- even those with an anonymous authorization -- to retrieve the 'supportedSASLMechanisms' attribute of the root DSE both before and after the SASL authentication exchange. The purpose of the latter is to allow the client to detect possible downgrade attacks (see Section 6.4 and RFC4422, Section 6.1.2). |
| vendorName | the name of the LDAP server implementer |
| vendorVersion | the version of the LDAP server implementer |
| supportedAuthPasswordSchemes | The values of this attribute are names of supported authentication password schemes which the server supports eg, SHA256. |
This is the output of the legacy OpenLDAP ldapsearch tool that is the result of retrieving the root
DSE of a public LDAP server, directory.Verisign.COM. Note that the root DSE is specified by the
zero-length base DN, and the search scope is specified as base.
This server is a Sun server which fails to support the valid search filter '(&)', therefore, the example uses the presence
filter '(objectClass=*)':
$ /usr/bin/ldapsearch -LLLxH ldap://directory.verisign.com:389 \
-b '' -s base '(objectClass=*)' supportedControl supportedExtension supportedSASLMechanisms
dn:
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
The following example uses perl to retrieve and display attributes from the root DSE.
#! /usr/bin/perl
use warnings;
use strict;
use Net::LDAP;
my $ldap = Net::LDAP->new('ldap://ldap.example.com:1389') or die "$@";
# search
my $baseObject = "";
# The root DSE should be only be returned when scope is 'base'
my $scope = "base";
# my $filter = "(&)";
my $filter = "(objectClass=*)";
# The code explicity specifies a size limit
# and a time limit. It is a good practice to get into
# the habit of explicitly supplying size and time limit.
my $searchResult = $ldap->search(base => $baseObject,
scope => $scope,
filter => $filter,
sizelimit => 1,
timelimit => 1,
attrs => [ "+", "*" ] );
$searchResult->code and die $searchResult->error;
foreach my $entry ($searchResult->entries) { $entry->dump; }
# finished
$ldap->unbind;
Caution: the Net::LDAP module is not thread-safe. Perl code which requires the use of threads with LDAP must not use Net::LDAP
"targetattribute=*" allows access to all operational attributes, not just user attributes. This
construct allows LDAP clients access to operational attributes (perhaps unintended) and should be avoided. Use a modern,
professional-quality directory server instead or avoid this syntax entirely.ldap_cachemgr on Solaris and OpenSolaris, expects supported response controls to be listed in
the root DSE, and fail to operate correctly in some cases when the response controls are not listed.vendorVersion and vendorName. For this reason, in the absence of an
approved business reason to expose vendorName and vendorVersion, administrators should prevent the values of these attributes from
being exposed© 2012 Terry Gardner