Case insensitive substring LDAP search on OpenLDAP 2.4.33

Question

The current question is not the same as this one.

I have an LDAP entry which the content "This is a SimpleTest indeed" in the "supName" field.

I need to write a filter so that when the user of my software introduces any substring of this content in any case (upper, lower or mixed case), it finds the entry. It must work even if the user does not input a complete word ("impletes", for example).

The supName field follows DirectoryString syntax. This means that the default matching rule is exact and case sensitive ("caseExactMatch"). But this syntax in theory, should allow also "caseIgnoreMatch" and "caseIgnoreSubstringsMatch" matching rules. I though I just needed to force to use the last one ("caseIgnoreSubstringsMatch"), so I tried this filter:

(supName:caseIgnoreSubstringsMatch:=*impletes*)

But this does not work. I make my tests using Apache Directory Studio, and that tool refuses to accept the above filter. It complains on the asterisks, and I don't understand why, since I am using a Substring match (and thus asterisks should be allowed). If I run the filter from command line (using ldapsearch), I get this error message:

ldap_search_ext: Bad search filter (-7)

Therefore this is not an issue with Apache Directory Studio.

So my question is: What is the correct way of defining a case-insensitive substring filter on a field that is case-sensitive by default?

Futher tests:

What follows are some other filters I have tested, and the reasons they do not suit me.

Test #1 filters:

(supName=*impleTes*)

This operator (=) returns my test entry, but it's not case-insensitive. If I replace "impleTes" for "impletes" it does not return anything.

Test #2 filter:

(supName~=simpletest)

This operator (~=) works, but:

• It needs a complete word. If I replace "simpletest" for "impletes" it does not return anything.
• As it is an "approximate" search operator, it may return unwanted results. For example, the filter above returns also a second entry: "This is a SimpleTast indeed" (notice the "a" instead of "e" in "SimpleTast"). I don't want approximate results.

Test #3 filter:

(supName:caseIgnoreMatch:=this is a simpletest indeed)

This returns the entry I was expecting, and only that entry. It is also case-insensitive. But it forces the user to write the whole content of the field: it is not a substring search, but a case-insensitive exact-match search.

Test #4 filter:

(supName:caseIgnoreMatch:=*impletes*)

This returns a "Bad search filter (-7)" error, with is expected since I am not allowed to use substring syntax in an exact matching rule.

And finally, the Test #5 filter:

(supName:caseIgnoreSubstringsMatch:=*impletes*)

Which I expected to work, but returns a "Bad search filter (-7)" error.

Additional info - Opposite example

I have found here (see the "Extensible Matching" section at the end) examples of the opposite case. In the example, the field "sn" uses the "caseIgnoreMatch" matching rule by default (making it case-insensitive). So what they want in the example is to do a case-sensitive substring search. This is the filter they use:

(sn:caseExactSubstringMatch:=*S*)

But I doubt if this example is correct, because if I try exactly the same filter on my side:

(supName:caseExactSubstringMatch:=*S*)

I get a "Bad search filter (-7)" error.

So maybe my issue is due to limitation on OpenLDAP 2.4.33 but would work with other LDAP servers, although the example comes from a guide that is supposed to cover OpenLDAP 2.x ... (?)

Answer 1

Other option is (Attribute~=value)

-- http://publib.boulder.ibm.com/tividd/td/IBMDS/IDSprogref52/en_US/HTML/progref.htm#HDRLDAPSRCH

Answer 2

If I'm reading RFC 4515§3 correctly, an extensible match can only be done with an assertion value (read: a fixed string) and not with a substring filter. If that were permitted, I would expect your original example (supName:caseIgnoreSubstringsMatch:=*impletes*) to work.