33

I have very limited knowledge in AD and LDAP queries so I have a simple question on how to use wildcards.

Supposed there is object with a displayName of "ITSM - Problem Management"

My current implementation of the filter with a wildcard is as such:

(displayName=SEARCHKEYWORD*)

If a user would enter a keyword of "Problem", he wouldn't be able to find the object since it needs the first part of the name, that is "ITSM - "

I would like to implement the wildcard on both ends like below:

(displayName=*SEARCHKEYWORD*)

Ideally, this would allow the entry of "Problem" and have it search for "ITSM - Problem Management". But the wildcard doesn't seem to work when you put it at the start. When I tried it, it just seems to hang-up and not return any results.

Any ideas or thoughts on how I can resolve this? Any input would be highly appreciated. Thanks!

AnimaSola
  • 7,146
  • 14
  • 43
  • 62
  • 1
    you should inform the directory administrators of your intention to use substring filters to ensure that the directory server is appropriately configured. See also [LDAP: Programming Practices](http://ff1959.wordpress.com/2011/10/27/ldap-programming-best-practices/). – Terry Gardner Mar 05 '12 at 15:51
  • Just out of curiosity, what does "ITSM" stand for? I know of one particular ITSM, but I doubt it is the same as yours... – ErikE Oct 22 '12 at 21:29
  • @ErikE Apologies for the delay in my reply, ITSM = IT Service Management. Governing policies and processes for IT operations :) – AnimaSola Nov 22 '12 at 00:17

4 Answers4

39

A filter argument with a trailing * can be evaluated almost instantaneously via an index lookup. A leading * implies a sequential search through the index, so it is O(N). It will take ages.

I suggest you reconsider the requirement.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Looks like you were right with the leading wildcard taking ages, I searched for one specific object by it's whole name and it still hasn't resolved the search, I don't think it ever will. Thank You! – AnimaSola Mar 06 '12 at 02:26
  • I use this kind of search the whole time and is ok, just have to filter by ObjectClass like this: `(&(ObjectClass=Person)(cn=*KEYWORD*))` – MGP Feb 28 '14 at 15:05
  • 1
    @ManuelGutierrez Time is still *O(N),* but because of the additional `objectClass` filter you're now dealing with a smaller *N.* – user207421 Apr 24 '14 at 07:07
7

Your best bet would be to anticipate prefixes, so:

"(|(displayName=SEARCHKEY*)(displayName=ITSM - SEARCHKEY*)(displayName=alt prefix - SEARCHKEY*))"

Clunky, but I'm doing a similar thing within my organization.

Rich
  • 380
  • 4
  • 11
1

The @user207421's answer is partially correct: by default, median search of the displayName attribute will cause full directory scan and thus will be slow and resource-intensive.

However, the AD Schema Admins can change that by implementing tuple index - specifically designed to improve performance of searches with the leading *. They need to modify the searchFlags attribute of the schema object - ref. https://learn.microsoft.com/en-us/windows/win32/adschema/a-searchflags

Svyatoslav Pidgorny
  • 573
  • 3
  • 11
1

This should work, at least according to the Search Filter Syntax article on MSDN network.

The "hang-up" you have noticed is probably just a delay. Try running the same query with narrower scope (for example the specific OU where the test object is located), as it may take very long time for processing if you run it against all AD objects.

You may also try separating the filter into two parts:

(|(displayName=*searchstring)(displayName=searchstring*))
ShaMan-H_Fel
  • 2,139
  • 17
  • 24
  • I tried the filter above to search for one specific object, as I entered the whole name, and the search takes ages. I don't think it will ever resolve. EJP's comment that a leading wildcard may take ages could be right. Appreciate the reply though, thank you! :) – AnimaSola Mar 06 '12 at 02:23