Extensible Match Search Filter#

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#

• Microsoft Active Directory Extensible Match Rules
• Edirectory Extensible Match Rules

Example using ExtensibleMatch#

The following LDAP Query Examples illustrate the use of ExtensibleMatch.

• (cn:1.2.3.4.5:=Fred Flintstone)
• (sn:dn:2.4.6.8.10:=Barney Rubble)
• (o:dn:=Ace Industry)
• (:dn:2.4.6.8.10:=Dino)
• (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 "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.

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#

The tree looks like:

dc=com
    dc=willeke
        ou=Administration
            cn=OneInetOrgPerson
            ....
        ou=People
            cn=TwoInetOrgPerson
            ....
            ou=butler
               cn=moreInetOrgPerson
               ....
        ou=Groups
            cn=ThreeInetOrgPerson
            ....
        ou=IDM
            cn=FourInetOrgPerson
            ....
        ou=Sales
            cn=FiveInetOrgPerson
            ....

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:

(&(objectclass=inetorgperson)(sn=willeke))

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

(&(|(ou:dn:=People)(ou:dn:=Administration))(objectclass=inetorgperson)(sn=willeke))

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#

• Active Directory Group Related Searches
• Active Directory User Related Searches
• DefinitionExtensibleMatchSearchFilter
• Edirectory Extensible Match Rules
• ExtensibleMatchIndex
• Filtering for Bit Fields
• LDAP Filter Choices
• LDAP Indexes
• LDAP Query Advanced Examples
• LDAP Schema Element Type
• LDAP Searches
• LDAP Three-valued logic
• LDAP_MATCHING_RULE_BIT_AND
• LDAP_MATCHING_RULE_BIT_OR
• LDAP_MATCHING_RULE_DN_WITH_DATA
• LDAP_MATCHING_RULE_IN_CHAIN
• MatchingRule
• MatchingRuleUse
• Microsoft Active Directory Extensible Match Rules
• Retrieving Constructed Attributes
• Search Filters Limitations
• SubschemaSubentry

• [#1] - Extensible Match Search Filter - based on information obtained 2017-10-18
• [#2] - Ldap Filters - based on information obtained 2017-10-18