13.4 Extensible Match Search Filter

The LDAP 3 core protocol specification defined in RFC 2251 requires LDAP servers to recognize a search element called an extensible match filter. An extensible match allows an LDAP client to specify the following items in a search filter:

  • An optional attribute name

  • An optional matching rule

  • A flag to indicate if the DN attributes should be considered a part of the entry

  • The value to be used for the match

The following is the string representation of the extensible match search filter:

extensible = attr [":dn"] [":" matchingrule] ":=" value /
             [:dn"] ":" matchingrule ":=" value

The following table lists the Extensible Match search filter parameters:

Parameter

Description

attr

Specifies the attribute to match on.

[":dn"]

Indicates that the matching rule should be included in the comparison match.

[":" matchingrule]

Designates the matching rule to be used.

":="

Without a matching rule results in an equality match.

value

Comparison value

The extensibleMatch is a new filter provided in LDAP 3. If the matchingRule field is absent, the attribute field MUST be present, and the equality match is performed for that attribute. If the attribute field is absent and matchingRule is present, the matchValue is compared against all attributes in an entry that supports that matchingRule, and the matchingRule determines the syntax for the assertion value.

The filter item evaluates as

  • TRUE if it matches with at least one attribute in the entry.

  • FALSE if it does not match any attribute in the entry.

  • Undefined if the matchingRule is not recognized or the assertionValue cannot be parsed.

If the type field along with the matchingRule is present, the matchingRule must be one permitted for use with that type, otherwise the filter item is undefined. If the :dn is specified in the search filter, the match is applied against all the attributes in an entry’s distinguished name as well, and also evaluates to TRUE if there is at least one attribute in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present so that there does not need to be multiple versions of generic matching rules such as for word matching, one to apply to entries and another to apply to entries and DN attributes as well.

Essentially, an extensible match filter allows an LDAP client to achieve two objectives:

  • Support multiple matching rules for same type of data

  • Include DN elements in the search criteria

    The DN specification allows matching on specific elements of the DN.

eDirectory 8.7.3 and later versions support the extensible match filter for matching on the DN attributes. The other elements of the extensible match search filter, namely the matching rule, are treated as undefined and ignored. The DN matching allows an LDAP client to drastically reduce the searches required to locate an object in an eDirectory tree. For example, a complex LDAP search filter such as

(&(ou:dn:=sales)(objectclass=user))

would let you have a listing of all the User objects in the sales function (that is, anywhere under the sales containers).

Usage Examples

The following are examples of the string representations of extensible match search filter that are supported in eDirectory 8.7.3 and later versions.

(o:dn:=Ace Industry)

This example illustrates the use of the :dn notation. The attributes of an entry’s distinguished name should be considered part of the entry when evaluating the match. It denotes an equality match.

(:dn:2.4.8.10:=Dino)

This example is a filter that should be applied to any attribute of an entry. Attributes contained in the DN with the matching rule 2.4.8.10 should also be considered.

The following are some examples of the string representation of extensible match search filter that are not supported in eDirectory 8.7.3 and later versions:

(cn:1.2.3.4.5:=John Smith)

This example illustrates a filter that specifies the attributes type cn and value John Smith. It mandates that the match should be performed by the directory server according to the matching rule identified by the oid 1.2.3.4.5.

(sn:dn:2.4.6.8.10:=Barbara Jones)

This example illustrates the use of the :dn notation to indicate that matching rule 2.4.6.8.10 should be used when making comparisons, and that the attributes of an entry’s distinguished name should be considered part of the entry when evaluating the match.