14.4. Examples of Common ldapsearches
14.4. Examples of Common ldapsearches The set of examples assumes the following: 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.11.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 . 14.4.1. Returning All Entries Given the information, the following call will return all entries in the directory (subject to the configured size and time resource limits): "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. 14.4.2. Specifying Search Filters on the Command Line A search filter can be specified directly on the command line as long as the filter is enclosed in quotation marks ("filter"). If the filter is supplied with the command, do not specify the -f option. For example: 14.4.3. Searching the Root DSE Entry The root DSE is a special entry that contains information about the directory server instance, including all of the suffixes supported by the local Directory Server. This entry can be searched by supplying a search base of "", a search scope of base , and a filter of "objectclass=*" . For example: 14.4.4. Searching the Schema Entry The cn=schema entry is a special entry that contains information about the directory schema, such as object classes and attribute types. The following command lists the content of the cn=schema entry: 14.4.5. Using LDAP_BASEDN 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. For example, set LDAP_BASEDN to dc=example,dc=com and search for cn=babs jensen in the directory, use the following command-line call: In this example, the default scope of sub is used because the -s option was not used to specify the scope. 14.4.6. Displaying Subsets of Attributes 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. It may not be necessary to have all of the attributes for an entry returned in the search results. The returned attributes can be limited to just a few specific attributes by specifying the required ones on the command line immediately after the search filter. For example, to show the cn and sn attributes for every entry in the directory, use the following command-line call: 14.4.7. Searching for 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. Operational attributes are not returned in regular ldapsearch es. According to RFC3673 , use + to return all operational attributes in a search request: To return only some defined operational attributes, explicitly specify them in the ldapsearch request: The complete list of operational attributes is in the "Operational Attributes and Object Classes" chapter in the Red Hat Directory Server 11 Configuration, Command, and File Reference . Note 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. 14.4.8. Specifying Search Filters Using a File 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. For example: ldapsearch first finds all the entries with the surname set to example , then all the entries with the givenname set to user . If an entry is found that matches both search criteria, then the entry is returned twice. For example, in this search, the filters are specified in a file named searchdb : The set of attributes returned here can be limited by specifying the attribute names at the end of the search line. For example, the following ldapsearch command performs both searches but returns only the DN and the givenname and sn attributes of each entry: 14.4.9. Specifying DNs That Contain Commas in Search Filters When a DN within a search filter contains a comma as part of its value, the comma must be escaped with a backslash (\). For example, to find everyone in the example.com Bolivia, S.A. subtree, use the following command: 14.4.10. Using a Client Certificate to Bind to Directory Server See Section 9.9.4, "Authenticating Using a Certificate" . 14.4.11. Searching with Language Matching Rules To explicitly submit a matching rule in a search filter, insert the matching rule after the attribute: Matching rules are frequently used for searching internationalized directories. For example, this searches 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" . 14.4.12. Searching for Attributes with Bit Field Values Bitwise searches use the bitwise AND or bitwise OR matching rules to perform bitwise search operations on attributes with values that are bit fields. Note 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.
ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" 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=*" ldapsearch -o ldif-wrap=no -D "cn=Directory Manager" -W -b "cn=schema" '(objectClass=subSchema)' -s sub objectClasses attributeTypes matchingRules matchingRuleUse dITStructureRules nameForms ITContentRules ldapSyntaxes export LDAP_BASEDN="dc=example,dc=com" ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=babs jensen" ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" sn cn ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" '+' ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" "*" aci sn= example givenname= user ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -f searchdb ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -f searchdb sn givenname 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=*" attr:matchingRule := value departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709 "(UserAccountControl:1.2.840.113556.1.4.803:=2)" "(UserAccountControl:1.2.840.113556.1.4.803:=6)" "(UserAccountControl:1.2.840.113556.1.4.804:=6)"