Extensible Match Search Filter#

Defined in RFC 2254 an ExtensibleMatch search filter is a type of searchRequest that can be used to identify matching entries using a specified matchingRule.

An extensible matching filter contains the following components:

  • The OID of the matching rule to use for the determination. This is an optional element, and if it isn't provided then the attribute type must be given and its default equality matching rule will be used.
  • The name of the AttributeType that will be targeted. If this is not provided, then all attributes contained in the entry will be examined.
  • A flag that indicates whether the matching should be performed against the attributes of the entry's Distinguished Names and the attributes contained in the entry .
  • An assertion Value that should be used as the target for the matching rule.

The string representation of an LDAP extensible match filter is comprised of the following components in order:

  • An opening parenthesis
  • The name of the attribute type, or an empty string if none was provided
  • The string ":dn" if the dnAttributes flag is set, or an empty string if not
  • If a matching rule ID is available, then a string comprised of a colon followed by that OID, or an empty string if there is no matching rule ID
  • The string ":="
  • The string representation of the assertion value
  • A closing parenthesis

Anomalies for LDAP Server Implementations#

Example using ExtensibleMatch#

Allows as an example, the ability to include or exclude entries within certain containers within the DIT when performing LDAP Searches.

The following LDAP Query Examples illustrate the use of ExtensibleMatch.

  • (cn: Flintstone)
  • (sn:dn: Rubble)
  • (o:dn:=Ace Industry)
  • (:dn:
  • (member:1.2.840.113556.1.4.1941:=(CN=John Smith,DC=MyDomain,DC=NET)) - Uses the 1.2.840.113556.1.4.1941 matching rule.

The second example illustrates the use of the ":dn" notation to indicate that matching rule "" 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.

The third example denotes an equality match, except that DN components should be considered part of the entry when doing the match.

The fourth example is a filter that should be applied to any attribute supporting the matching rule given (since the attr has been left off). Attributes supporting the matching rule contained in the DN should also be considered.

NOTE: Not all LDAP Server Implementations support all facets of Extensible Match.

Search within Two Containers#

Suppose you want results form ONLY two of more-than-two containers in a LDAP tree.
Microsoft Active Directory does NOT support this functionality and only supports: Microsoft Active Directory Extensible Match Rules

The tree looks like:


At first glance, you would need to perform a search on each of the desired containers and combine the results.

However, there are search filters called "Extensible Match" that can do the job.

As an example, let's assume we want to find user's (objectclass=inetorgperson) in the containers (ou:dn:=People)(ou:dn:=Administration) that have a surname (sn) of (sn=willeke).

So we could search each container with:


Or with Extensible Match we could do it like: With Extensible Match, you could use do it like:


Will find all the users in ou=People or ou=Administration but not the users in any of the other OUs.

Here is the output:

# ldapsearch -h ldap.willeke.com -b DC=willeke,DC=com -D cn=youradmin,ou=yourcontainer,dc=willeke,dc=com -W "(&(|(ou:dn:=People)(ou:dn:=Administration))(objectclass=inetorgperson)(sn=willeke))" sn cn
version: 1

# filter: (&(|(ou:dn:=People)(ou:dn:=Administration))(objectclass=inetorgperson)(sn=willeke))
# requesting: sn cn

# francesadmin,administration,willeke,com
dn: cn=francesadmin,ou=administration,dc=willeke,dc=com
cn: francesadmin
sn: willeke

# Willeke-Hall Alice,people,willeke,com
dn: cn=Willeke-Hall Alice,ou=people,dc=willeke,dc=com
cn: Willeke-Hall Alice
sn: Willecke
sn: Willeke
sn: Hall

# Willeke-Neuman Grace,people,willeke,com
dn: cn=Willeke-Neuman Grace,ou=people,dc=willeke,dc=com
cn: Willeke-Neuman Grace
sn: Nueman
sn: Willecke
sn: Willeke

# scott,butler,people,willeke,com
dn: cn=scott,ou=butler,ou=people,dc=willeke,dc=com
cn: scott
sn: Willeke

# molly,butler,people,willeke,com
dn: cn=molly,ou=butler,ou=people,dc=willeke,dc=com
cn: molly
cn: c14281
sn: Willeke

# jim,butler,people,willeke,com
dn: cn=jim,ou=butler,ou=people,dc=willeke,dc=com
cn: jim
sn: Willeke

Note however, that the search (ou:dn:=People) can NOT be substring. (At least with eDirectory) Novell documentation Extensible Match Search Filter shows a couple of small examples. Unfortunately, this is as well as Extensible Match Search Filters are described any where we could find.

The implementation of Extensible Match Search Filters is often different across LDAP server implementations.

More Information#

There might be more information for this subject on one of the following: