Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. LDAP search (ldapsearch) examples

The following examples provide the most common ldapsearches used for searching though the directory.

Prerequisites

  • You perform the search for all entries in the directory.
  • You configured the directory to support anonymous access for search and read operations. Therefore, you do not need to use -W and -D options in the command to supply any bind information. For more information on anonymous access, see Granting anonymous access.
  • The server uses the default port number 389. You do not need to specify it in the search request.
  • The server has the server.example.com hostname.
  • You enabled TLS for the server on the port 636, the default LDAPS port number.
  • Directory Server store all data under the dc=example,dc=com suffix.

Returning all entries

The following LDAP search returns all entries in the directory: 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)"

Use the (objectclass=*) search filter to return every entry in the directory. Each entry must have an object class, and the objectclass attribute is always indexed.

Specifying search filters on the command line

You can specify a search filter directly on the command by enclosing the filter in quotation marks ("filter"). If you supply the filter in the command, do not specify the -f option. For example, to specify the "cn=babs jensen", enter: 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "cn=babs jensen"

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 that the local Directory Server supports. Search for this entry by supplying a search base of "", a search scope base, and the filter "objectclass=*", for example: 

# ldapsearch -H ldap://server.example.com -x -b "" -s base "objectclass=*"

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.

To list the content of the cn=schema entry, enter either of the following commands: 

# ldapsearch -x -o ldif-wrap=no -b "cn=schema" \ '(objectClass=subSchema)' -s sub objectClasses attributeTypes matchingRules \ matchingRuleUse dITStructureRules nameForms ITContentRules ldapSyntaxes

or 

# ldapsearch -x -o ldif-wrap=no -b "cn=schema" \ '(objectClass=subSchema)' -s sub "+"

Using LDAP_BASEDN variable

To simplify the search, you can set the search base by using the LDAP_BASEDN environment variable. You can set LDAP_BASEDN instead of using the ldapsearch command with the -b option. For more information about setting environment variables, see the documentation for the operating system.

Set LDAP_BASEDN to the directory suffix value. Because the directory suffix is equal to the root entry in the directory, all searches begin from the directory root entry.

For example, to set the LDAP_BASEDN variable to dc=example,dc=com and search for cn=babs jensen in the directory, enter: 

# export LDAP_BASEDN="dc=example,dc=com"

# ldapsearch -H ldap://server.example.com -x "cn=babs jensen"

The command uses the default scope sub because the -s option was not supplied to specify the scope.

Displaying subsets of attributes

The ldapsearch command returns all search results in the LDIF format. By default, ldapsearch returns the entry distinguished name (DN) and all of the attributes that the user is allowed to read. You can set the directory access control to allow users to read only a subset of the attributes on any given directory entry.

Directory Server does not return operational attributes by default. To return operational attributes as a result of a search operation, explicitly specify these attributes in the search command or use the + argument to return all operational attributes. For more information, see Searching for operational attributes.

You can limit the returned attributes to a few specific attributes by specifying the required attributes on the command line after the search filter.

For example, to show the cn and sn attributes for every entry in the directory, enter: 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" sn cn

Searching for operational attributes

Operational attributes are special attributes that Directory Server sets itself. Directory Server uses operational attributes to perform maintenance tasks, such as processing access control instructions. These attributes show specific information about the entry, such as the time this entry was initially created and the name of the user who created it.

You can use operational attributes on every entry in the directory, even if the attribute is specifically defined for the object class of the entry.

Regular ldapsearch commands do not return operational attributes. According to RFC3673, use + to return all operational attributes in a search request: 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" '+'

To return only certain defined operational attributes, explicitly specify them in the ldapsearch request: 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp

For the complete list of operational attributes, see Operational Attributes and Object Classes.

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 you list. 

# ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" "*" aci

Note that you must enclose the asterisk (*) in quotation marks to prevent the shell from interpreting it.

Specifying search filters by using a file

You can specify search filters in a file instead of entering them on the command line.

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, the file contains the following filters: 

sn=example
givenname=user

The ldapsearch command first finds all the entries with the surname set to example, then all the entries with the givenname set to user. If the search request finds an entry that matches both search criteria, then the entry is returned twice.

In the following search, the filters are specified in a file named searchdb: 

# ldapsearch -H ldap://server.example.com -x -f searchdb

You can limit the set of returned attributes 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: 

# ldapsearch -H ldap://server.example.com -x -f searchdb sn givenname

Specifying DNs that contain commas in search filters

When a DN within a search filter contains a comma as part of its value, the search command must escape the comma with a backslash (\). For example, to find everyone in the example.com Bolivia, S.A. subtree, enter: 

# ldapsearch -H ldap://server.example.com -x -s base -b "l=Bolivia\, S.A.,dc=example,dc=com" "objectclass=*"

Using the nsRole virtual attribute in the filter

In the following example, the ldapsearch command searches for DNs of all user entries that contain the nsrole attribute set to the managed_role value: 

# ldapsearch -H ldap://server.example.com -x -b "dc=example,dc=com" "(nsrole=cn=managed_role,dc=example,dc=com)" dn

Using a client certificate to bind to Directory Server

For more information about certificate-based authentication, see Configuring certificate-based authentication.

Searching with language matching rules

To explicitly submit a matching rule in a search filter, insert the matching rule after the attribute: 

attr:matchingRule:=value

Matching rules are frequently used for searching internationalized directories. The following command searches for the department numbers after N4709 in the Swedish (2.16.840.1.113730.3.3.2.46.1) matching rule. 

departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709

For more examples of performing internationalized searches, see Searching an Internationalized Directory.

Finding groups a user belongs to

To find all direct or indirect groups of which the user uid=jdoe,ou=people,dc=example,dc=com is a member, enter: 

# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -xLL -b "dc=example,dc=com" "(member:1.2.840.113556.1.4.1941:=uid=jdoe,ou=people,dc=example,dc=com)" dn

The search with inchainMatch matching rule does not support anonymous access. For more details about using the inchainMatch matching rule, see Using inchainMatch matching rule to find the ancestry of an LDAP entry.

Finding members of a group

To find all direct or indirect members of the marketing group, enter: 

# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -xLL -b "dc=example,dc=com" "(memberof:1.2.840.113556.1.4.1941:=cn=marketing,ou=groups,dc=example,dc=com)" dn

The search with inchainMatch matching rule does not support anonymous access. For more details about using the inchainMatch matching rule, see Using inchainMatch matching rule to find the ancestry of an LDAP entry.

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. Default Directory Server schemas do not use bit fields as attribute syntax. However, several LDAP syntaxes support integer-style values. You can define custom attributes to use bit field values. Applications can use custom attributes to perform bitwise operations against bit field values.

The bitwise AND matching rule (1.2.840.113556.1.4.803) checks if the bit given in the assertion value is set in the bit field attribute value. It is similar to an equality search. The following example sets userAccountControl value to the bit that represents 2: 

"(UserAccountControl:1.2.840.113556.1.4.803:=2)"

The following example show that the userAccountControl value must have all of the bits that are set in the value 6 (bits 2 and 4): 

"(UserAccountControl:1.2.840.113556.1.4.803:=6)"

The bitwise OR matching rule (1.2.840.113556.1.4.804) checks if any of the bits in the assertion string are represented in the attribute value. It is similar to a substring search. In this example, the UserAccountControl value must have any of the bits that are set in the bit field of 6, meaning that the attribute value can be 2, 4, or 6: 

"(UserAccountControl:1.2.840.113556.1.4.804:=6)"

You can use bitwise searches with the Windows-Linux integration, such as using Samba file servers.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top