Chapter 3. LDAP search filters
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: 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: 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 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: Lists matches against a partial value (substring search). For example, the "(sn=*erson)" search filter returns the following values: 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 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) 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: Search type Operator Description 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 You can combine multiple LDAP search filter components by using Boolean operators expressed in the prefix notation as follows: (<boolean-operator>(filter)(filter)(filter)...) You can use the following Boolean operators: Operator Symbol Description 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)))) 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*))) 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))) The following example filter returns all entries that do not represent a person: (!(objectClass=person)) 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)) 3.4. Using matching rules in LDAP search filters 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: 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 . Additional resources Matching rule types Using inchainMatch matching rule to find the ancestry of an LDAP entry LDAP search ( ldapsearch ) examples Commonly used matching rules 3.4.1. Matching rule types 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. Additional resources Maintaining the indexes of a specific database Managing the directory schema . Commonly used matching rules 3.4.2. Commonly used matching rules The following is the list of commonly used matching rules: Matching rule Description Object 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 Additional resources Language ordering matching rules Language substring matching rules LDAP search (ldapsearch) examples 3.4.3. Language ordering matching rules For international searches, you can use the following language ordering matching rules: Matching rule Object 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 Additional resources Searching an internationalized directory . International Search Examples 3.4.4. Language substring matching rules For international searches, you can use the following language substring matching rules: Matching rule Object 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 Additional resources Searching an internationalized directory International Search Examples 3.4.5. Using inchainMatch matching rule to find membership of an LDAP entry in nested groups 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 . 3.4.5.1. 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: 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: 3.4.5.2. Disabling the inchainMatch matching rule 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 Check if the In Chain plug-in is enabled: Disable the In Chain plug-in: The command disables the inchainMatch matching rule for all users. Verification Check if Directory Server disabled the In Chain plug-in:
(<attribute> <operator> <value>) (<attribute>: <matching_rule> :=<value>) cn: example cn;lang-fr: example sn: Derson sn: Anderson (employeeNumber>=500) (sn~=suret) (salary<=150000) (<boolean-operator>(filter)(filter)(filter)...) (<boolean-operator>(filter)((<boolean-operator>(filter)(filter)))) (&(ou=Marketing)(!(description=*X.500*))) (&(ou=Marketing)(!(description=*X.500*))(|(manager=cn=example,ou=Marketing,dc=example,dc=com)(manager=cn=demo,ou=Marketing,dc=example,dc=com))) (!(objectClass=person)) (&(!(objectClass=person))(cn~=printer3b)) (<attribute>: <matching_rule> :=<value>) 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";) 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 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 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 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