[{TableOfContents}] !!! Extensible Match Search Filter Defined in [RFC 2251] an [{$pagename}] 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|DN] 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 [{$pagename}] 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 [{$pagename}]. * (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 Suppose you want results form ONLY two of more-than-two containers in a LDAP tree. %%information [Microsoft Active Directory] does __NOT__ support this functionality and only supports: [Microsoft Active Directory Extensible Match Rules] %% The tree looks like: %%prettify {{{ 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: %%prettify {{{ (&(objectclass=inetorgperson)(sn=willeke)) }}} /% Or with [Extensible Match||Definition -- Extensible Match Search Filter] we could do it like: With Extensible Match, you could use do it like: %%prettify {{{ (&(|(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: %%prettify {{{ # 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|http://www.novell.com/documentation/edir87/index.html?page=/documentation/edir87/edir87/data/agazepd.html] 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: [{ReferringPagesPlugin before='*' after='\n' }] ---- * [#1] - [Extensible Match Search Filter|https://www.netiq.com/documentation/edir88/edir88/data/agazepd.html|target='_blank'] - based on information obtained 2017-10-18 * [#2] - [Ldap Filters|https://ldap.com/ldap-filters/|target='_blank'] - based on information obtained 2017-10-18