The search is for all entries in the directory.
The directory is configured to support anonymous access for search and read. This means that no bind information has to be supplied in order to perform the search. For more information on anonymous access, see Section 18.13.1.1.3, “Granting Anonymous Access”.
The server is located on a host named server.example.com.
The server uses port number 389. Since this is the default port, the port number does not have to be sent in the search request.
TLS is enabled for the server on port 636 (the default LDAPS port number).
The suffix under which all data are stored is dc=example,dc=com.
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)"
"objectclass=*" is a search filter that matches any entry in the directory. Since every entry must have an object class, and the objectclass attribute is always indexed, this is a useful search filter to return every entry.
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "cn=babs jensen"
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -b "" -s base "objectclass=*"
The cn=schema entry is a special entry that contains information about the directory schema, such as object classes and attribute types.
To make searching easier, it is possible to set the search base using the LDAP_BASEDN environment variable. Doing this means that the search base does not have to be set with the -b option. For information on how to set environment variables, see the documentation for the operating system.
Typically, set LDAP_BASEDN to the directory's suffix value. Since the directory suffix is equal to the root, or topmost, entry in the directory, this causes all searches to begin from the directory's root entry.
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=babs jensen"
In this example, the default scope of sub is used because the -s option was not used to specify the scope.
The ldapsearch command returns all search results in LDIF format. By default, ldapsearch returns the entry's distinguished name and all of the attributes that a user is allowed to read. The directory access control can be set such that users are allowed to read only a subset of the attributes on any given directory entry. Only operational attributes are not returned. For operational attributes to be returned as a result of a search operation, explicitly specify them in the search command or use + to return all operational attributes.
Operational attributes are special attributes set by the Directory Server itself that are used by the server to perform maintenance tasks, like processing access control instructions. They also show specific information about the entry, like the time it was initially created and the name of the user who created it. Operational attributes are available for use on every entry in the directory, regardless of whether the attribute is specifically defined for the object class of the entry.
The complete list of operational attributes is in the "Operational Attributes and Object Classes" chapter in the Red Hat Directory Server 10 Configuration, Command, and File Reference.
To return all of the regular entry attributes along with the specified operational attributes, use the special search attribute, "*", in addition to the operational attributes that are listed.
The asterisk must be enclosed in quotation marks to prevent it from being interpreted by the shell.
Search filters can be entered into a file instead of entering them on the command line. In this case, specify each search filter on a separate line in the file. The ldapsearch command runs each search in the order in which it appears in the file.
ldapsearch first finds all the entries with the surname Francis, then all the entries with the givenname Richard. If an entry is found that matches both search criteria, then the entry is returned twice.
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s base -b "l=Bolivia\,S.A.,dc=example,dc=com" "objectclass=*"
See Section 9.8.4, “Authenticating Using a Certificate”.
Matching rules are frequently used for searching internationalized directories. For example, this seearches for the department numbers after N4709 in the Swedish (2.16.840.1.113730.3.3.2.46.1) matching rule.
More examples of performing internationalized searches are given in Section D.4, “Searching an Internationalized Directory”.
Bitwise searches use the bitwise AND or bitwise OR matching rules to perform bitwise search operaions on attributes with values that are bit fields.
Attributes with values for bit fields are not common in LDAP. (No default Directory Server schema use bit fields as attribute syntax.) However, several LDAP syntaxes support integer-style values. Custom attributes can be defined which use bit field values, and applications can use those custom attributes to perform bitwise operations against bit field values.
The bitwise AND matching rule (1.2.840.113556.1.4.803) checks that the bit given in the assertion value is set in the bit field attribute value. (This is somewhat analogous to an equality search.) In this example, the userAccountControl value must be set to the bit representing 2.
In this example, the userAccountControl value must have all of the bits set that are set in the value 6 (bits 2 and 4).
The bitwise OR matching rule (1.2.840.113556.1.4.804) checks to see if any of the bits in the assertion string are represented in the attribute value. (This is somewhat analogous to a substring search.) In this example, the userAccountControl value must have any of the bits which are set in the bit field of 6, meaning that the attribute value can be 2, 4, or 6.
Bitwise searches can be used with Windows-Red Hat Enterprise Linux integration, such as using Samba file servers.
Microsoft has good documentation on bitwise operators at http://msdn.microsoft.com/en-us/library/aa746475.