Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. LDAP search filters

Search filters select specific entries that search operation returns. You can use search filters with the ldapsearch command-line utility or in the Directory Server web console.

Directory Server searches for entries based on the attribute-value pairs the entries store, not based on the attributes used in the distinguished names (DN) of these entries. For example, if an entry has the DN uid=user_name,ou=People,dc=example,dc=com, then a search for dc=example matches the entry only when the attribute-value pair dc:example exists in this entry.

When using ldapsearch, you can define multiple search filters in a file with each filter on a separate line. Alternatively, you can specify a search filter directly on the command line.

A search filter has the following basic syntax: 

(<attribute><operator><value>)
Copy to Clipboard Toggle word wrap

For example, the search filter (employeeNumber>=500) has employeeNumber as the attribute, >= as the operator, and 500 as the value.

A search filter with a matching rule has the following syntax: 

(<attribute>:<matching_rule>:=<value>)
Copy to Clipboard Toggle word wrap

For example, the search filter (givenName:caseExactMatch:=Daniel) has givenName as the attribute, caseExactMatch as the matching rule, and Daniel as the value.

You can define filters that use different attributes combined together with Boolean operators.

3.1. Using attributes in LDAP search filters
Copy link

A basic search looks for the presence of attributes or specific values in entries. A search can look for attributes in entries in several ways:

  • Checks if the attribute exists (presence search). A presence search uses an asterisk (*) to return every entry that has a certain attribute set, regardless of value.

    For example, "(manager=*)" filter returns every entry that has the manager attribute.

  • Matchs an exact attribute value (equality search). Equality search looks for an attribute with a specific value. For example, the "(cn=example)" filter returns all entries that contain the common name (cn) set to example.

    When an attribute has values associated with a language tag, the search returns all values. Therefore, the following two attribute values both match the "(cn=example)" filter: 

    cn: example
cn;lang-fr: example
    Copy to Clipboard Toggle word wrap

  • Lists matches against a partial value (substring search). For example, the "(sn=*erson)" search filter returns the following values: 

    sn: Derson
sn: Anderson
    Copy to Clipboard Toggle word wrap

    For more details about configuring the length of the substring searches, see Changing the search key length in a substring index.

3.2. Using operators in LDAP search filters
Copy link

Operators in LDAP search filters set the relationship between the attribute and the given search value. When searching for people, you can use operators to set a range, to return last names within a subset of letters in the alphabet or employee numbers that come after a certain number. 

(employeeNumber>=500)
(sn~=suret)
(salary<=150000)
Copy to Clipboard Toggle word wrap

When having imperfect information or searching in internationalized directories, you can use operators for phonetic and approximate searches to make the search operation more effective.

You can use the following operators in the search filters:

Expand
Search typeOperatorDescription

Equality

=

Returns entries with attributes which values exactly match the specified value. For example, cn=example.

Substring

=string* string

Returns entries that contain attributes with a specified substring in the value. For example, cn=exa*l. The asterisk (*) indicates zero (0) or more characters.

Greater than or equal to

>=

Returns entries that contain attributes with values that are greater than or equal to the specified value. For example, uidNumber>=5000

Less than or equal to

<=

Returns entries that contain attributes with values that are less than or equal to the specified value. For example, uidNumber<=5000

Presence

=*

Returns entries that contain one or more values for the specified attribute. For example, cn=*.

Approximate

~=

Returns entries that contain the specified attribute with a value that is approximately equal to the value specified in the search filter. For example, l~=san fransico returns l=san francisco.

3.3. Using compound LDAP search filters
Copy link

You can combine multiple LDAP search filter components by using Boolean operators expressed in the prefix notation as follows: 

(<boolean-operator>(filter)(filter)(filter)...)
Copy to Clipboard Toggle word wrap

You can use the following Boolean operators:

Expand
OperatorSymbolDescription

AND

Ampersand (&)

All specified filters must be true for the statement to be true. For example, (&(filter)(filter)(filter)…​)

OR

Vertical bar (|)

At least one specified filter must be true for the statement to be true. For example, (|(filter)(filter)(filter)…​)

NOT

Exclamation point (!)

The specified statement must not be true for the statement to be true. Only one filter is affected by the NOT operator. For example, (!(filter))

A search operation evaluates Boolean expressions in the following order:

  • Innermost to outermost parenthetical expressions first.
  • Then the server changes the order to try to evaluate the most restrictive expression first.

Compound search filters are most useful when they are nested together into completed expressions, such as: 

(<boolean-operator>(filter)((<boolean-operator>(filter)(filter))))
Copy to Clipboard Toggle word wrap

You can combine compound filters with other types of searches (approximate, substring, and other operators) to get detailed results. The following example filter returns all entries which have the organizational unit (ou) as Marketing and which description attribute does not contain the substring X.500: 

(&(ou=Marketing)(!(description=*X.500*)))
Copy to Clipboard Toggle word wrap

In addition, you can expand the filter to return also entries that have a manager set to example or demo: 

(&(ou=Marketing)(!(description=*X.500*))(|(manager=cn=example,ou=Marketing,dc=example,dc=com)(manager=cn=demo,ou=Marketing,dc=example,dc=com)))
Copy to Clipboard Toggle word wrap

The following example filter returns all entries that do not represent a person: 

(!(objectClass=person))
Copy to Clipboard Toggle word wrap

The following filter returns all entries that do not represent a person and which common name (cn) is similar to printer3b: 

(&(!(objectClass=person))(cn~=printer3b))
Copy to Clipboard Toggle word wrap

3.4. Using matching rules in LDAP search filters
Copy link

A matching rule specifies how Directory Server compares the value stored in the attribute with the value in the search filter. Matching rules are related to attribute syntaxes. When attribute syntaxes define the format of an attribute values, the matching rules define how that format is compared and indexed. A matching rule also defines how to generate index keys.

A matching rule is a schema element that has an object identifier (OID). All attributes in Directory Server have defined matching rules. For more information about matching rules types, see Matching rule types. By specifying a matching rule in a search filter, you can search for an attribute value with a matching rule that differs from the one defined for the attribute in the schema.

A filter with an extensible matching rule has the following syntax: 

(<attribute>:<matching_rule>:=<value>)
Copy to Clipboard Toggle word wrap

Where:

  • <attribute> is an attribute that belongs to entries that you search, such as cn, mail, name.
  • <matching_rule> is a string that contains the name or OID of the rule that you want to use for matching attribute values according to the required syntax. For example, caseExactMatch matching rule.
  • <value> is the attribute value or a relational operator plus the attribute value to search for.

The matching rule must be compatible with the syntax of the attribute that you search. You can run a case-sensitive search for an attribute that has a case-insensitive matching rule defined for it. For example, the name attribute has the predefined caseIgnoreMatch equality matching rule in the schema definition. The basic equality search with the filter (name=Daniel) retrieves entries that contain the name attribute values like DAniel, daniel, DanIel. The equality search with the matching rule filter (name:caseExactMatch:=Daniel) retrieves entries that contain the name attribute value of Daniel only.

Many matching rules defined for Directory Server relate to language codes and set internationalized collation orders. For example, the OID 2.16.840.1.113730.3.3.2.17.1 identifies the Finnish collation order. For the full list of supported internationalized collation orders, see Language ordering matching rules and Language substring matching rules.

3.4.1. Matching rule types
Copy link

A search filter without a specified matching rule, such as (employeeNumber>=500) or (sn=*erson), uses a matching rule defined by the syntax of the attribute in its schema definition. You can define the following types of matching rules for an attribute in the schema definition:

EQUALITY
An EQUALITY matching rule specifies how to compare two values for an equal match. For example, how to handle strings like Fred and FRED. Update operations use the EQUALITY rule to generate the index keys. Search operations with filters, such as (name=Fred), use the EQUALITY rule to compare the value in the filter with values in an entry.
ORDERING
An ORDERING matching rule specifies how to compare two values to determine if one value is greater or less than another value. Search filters that set a range, such as (employeeNumber>=500) or (attribute⇐value), use the ORDERING rule. An index for an attribute with an ORDERING rule orders the equality values.
SUBSTR
A SUBSTR matching rule specifies how to compare a substring value. Substring search filters, such as (name=*ed), use the SUBSTR rule. Substring (sub) indexes use the SUBSTR rule to generate the index keys.

In addition to equality, ordering, and substring matching rules, you can specify approximate and other extensible matching rules in a search filter.

Important

A directory requires matching rules to support searching or indexing for the corresponding search filter or index type. For example, an attribute must have an EQUALITY matching rule in order to support equality search filters and eq indexes for that attribute. An attribute must have both an ORDERING matching rule and an EQUALITY matching rule in order to support range search filters and indexed range searches.

Directory Server rejects a search operation with PROTOCOL_ERROR or UNWILLING_TO_PERFORM if the search operation uses a search filter for an attribute that has no corresponding matching rule.

Matching rules and custom attributes

For example, you want to create a custom attribute MyFirstName with IA5 String (7-bit ASCII) syntax and an EQUALITY matching rule of caseExactIA5Match in the schema definition. A search with the filter (MyFirstName=Fred) returns entries that have the MyFirstName value equal to Fred only; however, Fred, FRED, and fred are all valid IA5 String values. If you want a search to return all variants of the attribute value, you must define the MyFirstName attribute to use the equality matching rule caseIgnoreIA5Match or explicitly specify the matching rule (MyFirstName:caseIgnoreIA5Match:=Fred) in the search filter.

3.4.2. Commonly used matching rules
Copy link

The following is the list of commonly used matching rules:

Expand
Matching ruleDescriptionObject identifiers (OIDs)Compatible syntaxes

Bitwise AND match

Performs bitwise AND matches.

1.2.840.113556.1.4.803

Typically used with Integer and numeric strings. Directory Server converts numeric strings automatically to integer.

Bitwise OR match

Performs bitwise OR matches.

1.2.840.113556.1.4.804

Typically used with Integer and numeric strings. Directory Server converts numeric strings automatically to integer.

booleanMatch

Evaluates whether the values to match are TRUE or FALSE.

2.5.13.13

Boolean

caseExactIA5Match

Makes a case-sensitive comparison of values.

1.3.6.1.4.1.1466.109.114.1

IA5 Syntax, URI

caseExactMatch

Makes a case-sensitive comparison of values.

2.5.13.5

Directory String, Printable String, OID

caseExactOrderingMatch

Allows case-sensitive ranged searches (less than and greater than).

2.5.13.6

Directory String, Printable String, OID

caseExactSubstringsMatch

Performs case-sensitive substring and index searches.

2.5.13.7

Directory String, Printable String, OID

caseIgnoreIA5Match

Performs case-insensitive comparisons of values.

1.3.6.1.4.1.1466.109.114.2

IA5 Syntax, URI

caseIgnoreIA5SubstringsMatch

Performs case-insensitive searches on substrings and indexes.

1.3.6.1.4.1.1466.109.114.3

IA5 Syntax, URI

caseIgnoreListMatch

Performs case-insensitive comparisons of values.

2.5.13.11

Postal address

caseIgnoreListSubstringsMatch

Performs case-insensitive searches on substrings and indexes.

2.5.13.12

Postal address

caseIgnoreMatch

Performs case-insensitive comparisons of values.

2.5.13.2

Directory String, Printable String, OID

caseIgnoreOrderingMatch

Allows case-insensitive ranged searches (less than and greater than).

2.5.13.3

Directory String, Printable String, OID

caseIgnoreSubstringsMatch

Performs case-insensitive searches on substrings and indexes.

2.5.13.4

Directory String, Printable String, OID

distinguishedNameMatch

Compares distinguished name values.

2.5.13.1

Distinguished name (DN)

generalizedTimeMatch

Compares values that are in a Generalized Time format.

2.5.13.27

Generalized Time

generalizedTimeOrderingMatch

Allows ranged searches (less than and greater than) on values that are in a Generalized Time format.

2.5.13.28

Generalized Time

integerMatch

Evaluates integer values.

2.5.13.14

Integer

integerOrderingMatch

Allows ranged searches (less than and greater than) on integer values.

2.5.13.15

Integer

keywordMatch

Compares the given search value to a string in an attribute value.

2.5.13.33

Directory String

numericStringMatch

Compares more general numeric values.

2.5.13.8

Numeric String

numericStringOrderingMatch

Supports ranged searches (less than and greater than) on more general numeric values.

2.5.13.9

Numeric String

numericStringSubstringMatch

Compares more general numeric values.

2.5.13.10

Numeric String

objectIdentifierMatch

Compares object identifier (OID) values.

2.5.13.0

Object Identifier (OID)

octetStringMatch

Evaluates octet string values.

2.5.13.17

Octet String

octetStringOrderingMatch

Supports ranged searches (less than and greater than) on a series of octet string values.

2.5.13.18

Octet String

telephoneNumberMatch

Evaluates telephone number values.

2.5.13.20

Telephone Number

telephoneNumberSubstringsMatch

Performs substring and index searches on telephone number values.

2.5.13.21

Telephone Number

uniqueMemberMatch

Compares an assertion value of the Name And Optional UID syntax to an attribute value of a syntax

2.5.13.23

Name and Optional UID

wordMatch

Compares the given search value to a string in an attribute value. This matching rule is case-insensitive.

2.5.13.32

Directory String

3.4.3. Language ordering matching rules
Copy link

For international searches, you can use the following language ordering matching rules:

Expand
Matching ruleObject identifiers (OIDs)

English (Case Exact Ordering Match)

2.16.840.1.113730.3.3.2.11.3

Albanian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.44.1

Arabic (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.1.1

Belorussian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.2.1

Bulgarian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.3.1

Catalan (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.4.1

Chinese - Simplified (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.49.1

Chinese - Traditional (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.50.1

Croatian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.22.1

Czech (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.5.1

Danish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.6.1

Dutch (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.33.1

Dutch - Belgian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.34.1

English - US (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.11.1

English - Canadian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.12.1

English - Irish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.14.1

Estonian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.16.1

Finnish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.17.1

French (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.18.1

French - Belgian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.19.1

French - Canadian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.20.1

French - Swiss (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.21.1

German (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.7.1

German - Austrian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.8.1

German - Swiss (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.9.1

Greek (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.10.1

Hebrew (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.27.1

Hungarian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.23.1

Icelandic (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.24.1

Italian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.25.1

Italian - Swiss (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.26.1

Japanese (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.28.1

Korean (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.29.1

Latvian, Lettish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.31.1

Lithuanian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.30.1

Macedonian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.32.1

Norwegian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.35.1

Norwegian - Bokmul (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.36.1

Norwegian - Nynorsk (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.37.1

Polish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.38.1

Romanian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.39.1

Russian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.40.1

Serbian - Cyrillic (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.45.1

Serbian - Latin (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.41.1

Slovak (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.42.1

Slovenian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.43.1

Spanish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.15.1

Swedish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.46.1

Turkish (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.47.1

Ukrainian (Case Insensitive Ordering Match)

2.16.840.1.113730.3.3.2.48.1

3.4.4. Language substring matching rules
Copy link

For international searches, you can use the following language substring matching rules:

Expand
Matching ruleObject identifiers (OIDs)

English (Case Exact Substring Match)

2.16.840.1.113730.3.3.2.11.3.6

Albanian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.44.1.6

Arabic (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.1.1.6

Belorussian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.2.1.6

Bulgarian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.3.1.6

Catalan (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.4.1.6

Chinese - Simplified (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.49.1.6

Chinese - Traditional (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.50.1.6

Croatian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.22.1.6

Czech (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.5.1.6

Danish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.6.1.6

Dutch (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.33.1.6

Dutch - Belgian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.34.1.6

English - US (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.11.1.6

English - Canadian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.12.1.6

English - Irish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.14.1.6

Estonian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.16.1.6

Finnish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.17.1.6

French (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.18.1.6

French - Belgian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.19.1.6

French - Canadian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.20.1.6

French - Swiss (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.21.1.6

German (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.7.1.6

German - Austrian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.8.1.6

German - Swiss (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.9.1.6

Greek (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.10.1.6

Hebrew (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.27.1.6

Hungarian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.23.1.6

Icelandic (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.24.1.6

Italian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.25.1.6

Italian - Swiss (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.26.1.6

Japanese (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.28.1.6

Korean (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.29.1.6

Latvian, Lettish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.31.1.6

Lithuanian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.30.1.6

Macedonian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.32.1.6

Norwegian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.35.1.6

Norwegian - Bokmul (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.36.1.6

Norwegian - Nynorsk (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.37.1.6

Polish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.38.1.6

Romanian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.39.1.6

Russian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.40.1.6

Serbian - Cyrillic (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.45.1.6

Serbian - Latin (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.41.1.6

Slovak (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.42.1.6

Slovenian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.43.1.6

Spanish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.15.1.6

Swedish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.46.1.6

Turkish (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.47.1.6

Ukrainian (Case Insensitive Substring Match)

2.16.840.1.113730.3.3.2.48.1.6

The inchainMatch matching rule is an extensible match for a search filter that finds membership of an LDAP entry in nested groups. Directory Server supports both object identifier (OID) 1.2.840.113556.1.4.1941 and the human-readable name inchainMatch.

The use of the matching rule is limited to attributes with Distinguished Name (DN) syntax. You can perform the following searches by using the inchainMatch matching rule:

  • The search filter (member:1.2.840.113556.1.4.1941:=uid=jdoe,ou=people,dc=example,dc=com) finds all direct or indirect groups of which the user jdoe is a member.
  • The search filter (manager:1.2.840.113556.1.4.1941:=uid=jsmith,ou=people,dc=example,dc=com) finds all direct or indirect users whose manager is the jsmith.
  • The search filter (parentOrganization:1.2.840.113556.1.4.1941:=ou=ExampleCom,ou=europe,dc=example,dc=com) finds all direct or indirect organizations that ExampleCom belongs to.
  • The search filter (memberof:1.2.840.113556.1.4.1941:=cn=Marketing,ou=groups,dc=example,dc=com) finds all direct or indirect members of the Marketing group.

Note that for performance reasons you must index member, manager, parentOrganization, memberof attributes that inchainMatch uses.

Directory Server enables the inchainMatch matching rule by default via the In Chain plug-in. However, inchainMatch is expensive to compute, and only the Directory Manager has permissions to use inchainMatch by default. To grant permissions to other users, modify the access control instruction (ACI) in the oid=1.2.840.113556.1.4.1941,cn=features,cn=config entry. For more details, see Enabling the inchainMatch matching rule for a user entry.

Only the Directory Manager has permissions to use the inchainMatch matching rule by default because inchainMatch is expensive to process. To grant permissions to another user, modify the access control instruction (ACI) in the oid=1.2.840.113556.1.4.1941,cn=features,cn=config entry. The following procedure grants read and search permission to the admin user.

Prerequisites

  • The uid=admin,ou=people,dc=example,dc=com user entry exists.
  • The uid=jdoe,ou=people,dc=example,dc=com user entry exists and belong to the cn=Marketing_Germany,ou=groups,dc=example,dc=com group.
  • The cn=Marketing_Germany,ou=groups,dc=example,dc=com group is the nested group of the cn=Marketing_EU,ou=groups,dc=example,dc=com group.

Procedure

  • Grand read and search permissions to uid=admin,ou=people,dc=example,dc=com by replacing the default ACI in the oid=1.2.840.113556.1.4.1941,cn=features,cn=config entry: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: oid=1.2.840.113556.1.4.1941,cn=features,cn=config
changetype: modify
replace: aci
aci: (targetattr != "aci")(version 3.0; acl "InChain Matching Rule"; allow( read, search ) userdn = "ldap:///uid=admin,ou=people,dc=example,dc=com";)
    Copy to Clipboard Toggle word wrap
    Note

    To grand permission to several users, add these users to a group and set the groupdn as keyword in the bind rule of the ACI. For more details, see Defining group-based access.

Verification

  • Search for the groups that the user uid=jdoe,ou=people,dc=example,dc=com belongs to under the admin user: 

    $ ldapsearch -D "uid=admin,ou=people,dc=example,dc=com" ldap://server.example.com -W -xLL -b "dc=example,dc=com" "(member:1.2.840.113556.1.4.1941:=uid=jdoe,ou=people,dc=example,dc=com)" dn

   dn: cn=Marketing_EU,ou=groups,dc=example,dc=com
   dn: cn=Marketing_Germany,ou=groups,dc=example,dc=com
    Copy to Clipboard Toggle word wrap

3.4.5.2. Disabling the inchainMatch matching rule
Copy link

To implement the inchainMatch matching rule, Directory Server uses the In Chain plug-in that is enabled by default. If you want to disable inchainMatch, disable the In Chain plug-in by using the dsconf utility.

Procedure

  1. Check if the In Chain plug-in is enabled: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin show 'In Chain'
dn: cn=In Chain,cn=plugins,cn=config
cn: In Chain
nsslapd-pluginDescription: inchain matching rule plugin
nsslapd-pluginEnabled: on
...
    Copy to Clipboard Toggle word wrap

  2. Disable the In Chain plug-in: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin set --enabled off 'In Chain'

Successfully changed the cn=In Chain,cn=plugins,cn=config
    Copy to Clipboard Toggle word wrap

    The command disables the inchainMatch matching rule for all users.

Verification

  • Check if Directory Server disabled the In Chain plug-in: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin show 'In Chain'
dn: cn=In Chain,cn=plugins,cn=config
cn: In Chain
nsslapd-pluginDescription: inchain matching rule plugin
nsslapd-pluginEnabled: off
...
    Copy to Clipboard Toggle word wrap
Back to top
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

© 2025 Red Hat