ldap.searchFilter not updating after initial install

Good Evening and thanks for reading.

I have a new install of Openfire on a Windows 2008R2 Server running IIS7, PHP, and MySQL. The initial install went flawlessly including the AD portion of the installation. Openfire recognized my groups specified in the ldap.groupSearchFilter and populated the list with pretty much every user in the domain. Which I understood is working as intended. However, when I go to modify the ldap.searchFilter settings it doesn’t pair down the number of users to match the filter. All the users from the initial install are still listed in the users section.

Here is what I am using for the ldap.searchFilter:

(objectCategory=organizationalPerson)(memberOf=CN=AParticularGroup,OU=GROUPS,DC= MYDOMAIN,DC=local)

I also tried:

(&(objectClass=organizationalPerson)(|(memberOf=CN=AParticularGroupA,OU=GROUPS,D C=MYDOMAIN,DC=local)(memberOf=CN=AParticularGroupB,OU=GROUPS,DC=MYDOMAIN,DC=loca l)))

Neither filter updated the users list accordingly.

Thanks for reading. Hopefully this is something simple to remedy.

the filters work for me as they should. Have you tried using LDP,EXE to test your filters to make sure you have them correct and they return the expected results?

Here is how I handle mine.

How to Setup Authentication Groups with LDAP/AD

hopefully it will help point you in the right direction.

I simplified it even further:


This produced the desired result using LDP.EXE but I still show every user in MYDOMAIN when I view the Users tab in OpenFire.

Hi gmrstudios,

If I recall correctly, Windows LDAP isn’t a normal LDAP server in fact and ldap filters must be decorated by CDATA and you have to use sAMAccountName, that’s obligatory. Anyway usually “memberOf” filtering options using in addition to direct User object filtering option (something like “objectClass=Person” etc., but in case of Win LDAP you have to use sAMAccountName). Search Filter you provided both times looks pretty strange, I’m in doubts “(objectCategory=organizationalPerson)(memberOf=CN=AParticularGroup,OU=GROUPS,DC= MYDOMAIN,DC=local)” will work. AFAIK if you need search filter like “give me object of objectCategory=organizationalPerson and it will be a member of …”, you will rather use “(&(objectCategory=organizationalPerson)(memberOf=CN=AParticularGroup,OU=GROUPS,DC= MYDOMAIN,DC=local))”. Please compare both examples and see the difference.

Also I’d like I’m sorry that it looks like you’re new to LDAP and have almost no idea on how to use it - I recommend you:

  1. Read and follow Official Openfire documentation - there is a special part “Custome Search Filter”. It contains 100% working search filter

  2. Use LDAP Browser like Softerra LDAP Browser. That’s absolutely free and has cool LDAP Search Filter Builder option. Very easy to use and you it will be possible to you to create really complicated filters.

  3. Read more about LDAP - in other case you’re at risk of waisting a lot of time trying to setup LDAP filtering. That’s not a rocket science and will not take a lot of your time.

speedy: example you given seems to be non-working in case of “(objectClass=group)(cn=_IM*)”. That will be (&(objectClass=group)(cn=_IM*)), isn’t it? Also from my experience I’d like to recommend to enclose “_M” in quotes.

I think you’re right…but I just checked my install and tested (objectClass=group)(cn=_IM*) with a fresh install and it yielded the desired results. I also tested (&(objectClass=group)(cn=_IM*)) and it too yielded the expected results. I also tested just (cn=_IM*), and got the desired results…hmmm.


I am not new to LDAP and the tools you mention are well known to me. If you notice I did use “objectCategory=organizationalPerson” in my first example. I have setup filters on numerous occasions in other programs successfully. That is not say that I am missing something obvious in this case. Non the less thank you for your suggestions and will take a peak at your article.

When the filter is applied should it update the “user” section immediately?

figured it out… it looks like openfire is adding the operator. which is why its working both ways.

with my example its sending (&(&(cn=)(objectClass=group))(cn=_IM))

and with yours its sending (&(cn=)(&(objectClass=group)(cn=_IM)))


I didn’t want to hurt anybody, I don’t know you and your expertise as well. Just shared my experience: I don’t use construction like “(cn=…)(objectClass=…)” as I never seen something like that before in any applications I’m using or been using. From perspective of query logic example from speedy will work as any of the expression will work which means its equal to “OR” logic. To avoid such logic inaccuracy I prefer to use strict rules like “(&(objectClass=group)(cn=_IM*))”, they work always and I might be sure that I’ll get predictable results.


Regarding how fast searchfilter will be applied - as I got from my Openfire experience, it will be not applied just after you press “Save” for searchfilter. Openfire uses that filter every time user try to login (thru XMPP Client or Admin Console) or admin click on “Users”. There is nothing like User Cache (as for other applications) so there is nothing like recurrent cron sync process or something like that. To test your filter you have to click on Users in Admin Console.

Also I’d like to say that although we have LDAP standards and LDAP standard names, LDAP name mapping might be different in some cases. For instance, mine LDAP has no “organizationalPerson” but there is “orgPerson” instead. Any attempt to get user by “organizationalPerson” for me gives me nothing as there is nothing to give. Good option will be to check again name mapping between LDAP and used Directory (as internal representation of same attributes/properties will be different with high probability).

Rule “(&(objectClass=organizationalPerson)(|(memberOf=CN=AParticularGroupA,OU=GROUPS,D C=MYDOMAIN,DC=local)(memberOf=CN=AParticularGroupB,OU=GROUPS,DC=MYDOMAIN,DC=loc al)))” looks correct, but the first one looks pretty confusing for me. What is the exact problem you have with this rule, you have no results or you have not result you are expecting? Have you tried to check ldap trace for this query or not?


Last example might give you different results if you will not be using “cn=". Both strings might be simplified to "(&(cn=_IM)(ojectClass=group))” if you want to get a list of objects with names starting with _IM and class of “Group”.

Usually I don’t recommend to use expressions like “=" as it’s killing any logic You may use real complex logic before "=” but if you add it - it kills anything as “OR” and “AND” conditions will give absolutely the same result as “*” means “any, every one”. This makes further analysis very hard.

yeah…im not adding the cn=* wildcard. Openfire is doing it for me, so it appears to be hardcoded.

I don’t think so - at least in my case I see nothing like that (I mean “adding hardcoded cn=*”). Please check LDAP trace for my authentication attempt:

filter: "(&(uid=ivan)(&(|(objectClass=Person)(objectClass=inetOrgPerson)(objectClass=Or gPerson))(!(objectClass=mSDSComputer))(&(!(objectClass=mSDSComputer))(!(ou:dn:=O ESSystemObjects))(!(cn:dn:=Users))))


I’m using filter (&(|(objectClass=Person)(objectClass=inetOrgPerson)(objectClass=OrgPerson))(!(o bjectClass=mSDSComputer))(&(!(objectClass=mSDSComputer))(!(ou:dn:=OESSystemObjec ts))(!(cn:dn:=Users))))

As you can see, nothing like “cn=" is here so I’m in doubts about something like that will be hardcoded. As I said before, anything like "=” killing any logic.

I’m seeing it in the group search filter and captured it using wireshark.

I’ve checked trace for case of groups as well - no “cn=" as well. Trace looks not good for me as I’m getting some info about groups but nothing useful - but it’s a question of ldapSearchFilter for groups filtering (I have another topic on this forum for this case), but no "cn=” at all. Probably you seen traffic from another application which also using LDAP connection? As I said before - I’m in doubts regarding something like “cn=*” hardcoded in Openfire and its ability to add anything to searchfilter.

hmm…odd…anyway maybe I’ll look into it more when I have time!