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#DIT when performing LDAP Searches.
The following LDAP Query Examples illustrate the use of ExtensibleMatch.
- (cn:126.96.36.199.5:=Fred Flintstone)
- (sn:dn:188.8.131.52.10:=Barney Rubble)
- (o:dn:=Ace Industry)
- (member:1.2.840.1135184.108.40.2061:=(CN=John Smith,DC=MyDomain,DC=NET)) - Uses the 1.2.840.1135220.127.116.111 matching rule.
The second example illustrates the use of the ":dn" notation to indicate that matching rule "18.104.22.168.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#Suppose you want results form ONLY two of more-than-two containers in a LDAP tree.
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:
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:
- Active Directory Group Related Searches
- Active Directory User Related Searches
- Edirectory Extensible Match Rules
- Filtering for Bit Fields
- LDAP Filter Choices
- LDAP Indexes
- LDAP Query Advanced Examples
- LDAP Schema Element Type
- LDAP Searches
- LDAP Three-valued logic
- Microsoft Active Directory Extensible Match Rules
- Retrieving Constructed Attributes
- Search Filters Limitations