Ldap.searchfilter - Openfire 3.9.3/freeIPA 3.3.3-28/CentOS 7

Openfire Openfire Support
1

I’ve searched an exhausting amount on this topic and have found no solutions or anything relevant enough to lead me to one. Apologies in advance if this has already been correctly answered.

We’re undergoing an effort to integrate LDAP authentication with freeIPA on all our applications and Openfire is the only one giving me trouble with filtering users based on group membership. Most questions/answers I have seen refer to AD and I’m not sure if there’s some syntactical difference that I’m missing here that makes all the difference.

Down to details…

I’ve tried modifying the searchfilter value both directly in the database (required after you mess up because authentication will reject even your admin user), and through the admin UI.

Test 1 - Simply setting the filter to “(objectClass=inetorgperson)” authentication still works. All users in the directory can be returned with this very same search filter.

Test 2 - Changed filter to “(&(objectClass=inetorgperson)(memberOf=cn=openfire-users,cn=groups,cn=accounts ,dc=REDACTED,dc=com))” all authentication attempts now fail. Testing with ldapsearch on any of my freeIPA nodes returns users that are specifically in the openfire-users group as expected. Openfire and freeIPA logs do not verbosely report the reason for failure.

Test 3 - I guessed maybe using the “&” operator wasn’t being handled correctly because it’s already joining the filter with the default. Changed filter to “(memberOf=cn=openfire-users,cn=groups,cn=accounts,dc=REDACTED,dc=com)” same results as test 2. Again, this filter is valid with ldapsearch and I use the exact same thing in other applications to limit authentication to users in a specific group.

I have a feeling there’s something small I’m missing here…

2

try organizationalPerson instead of inetorgperson, and see if that works.

3

The objectClass shouldn’t matter since in Test 3 above I’m filtering solely on memberOf. For completeness sake I tested it anyway, but same results as expected. Users in my directory all have the following objectClass attributes, so it doesn’t really matter which one I use:

objectClass: top

objectClass: person

objectClass: organizationalperson

objectClass: inetorgperson

objectClass: inetuser

objectClass: posixaccount

objectClass: krbprincipalaux

objectClass: krbticketpolicyaux

objectClass: ipaobject

objectClass: ipasshuser

objectClass: ipaSshGroupOfPubKeys

objectClass: mepOriginEntry

I changed the filter as suggested with the following:

update ofproperty

set propvalue = ‘(&(objectClass=organizationalperson)(memberOf=cn=openfire-users,cn=groups,cn=a ccounts,dc=REDACTED,dc=com))’

where name = ‘ldap.searchFilter’;

Authentication attempts all fail as I described above with no verbose log output (just a simple authentication failure for admin user).

Using ldapsearch with the proposed filter works as expected, but again this is the same as all my tests. It’s only Openfire that doesn’t work with the filter.

ldapsearch -Y GSSAPI -b ‘cn=users,cn=accounts,dc=REDACTED,dc=com’ ‘(&(objectClass=organizationalperson)(memberOf=cn=openfire-users,cn=groups,cn=a ccounts,dc=REDACTED,dc=com))’

search result

search: 4

result: 0 Success

numResponses: 7

numEntries: 6

Returns all 6 users that are in the openfire-users group.

4

try making using your base dn the root of your domain. also make sure your admin account is included in the openfire-users group.

5

Changing my base to the root of my domain should not effect results using a search filter based on an object’s attribute. The admin account is most definitely in the openfire-users group (verified this many times while i was testing this on my own and before replying here again). I really don’t think this has anything to do with the attributes I’m using or how the filter is formed since it works perfectly when used with ldapsearch and when used to filter other application’s searches. I think I need some way to make the debug logging verbose enough to see the search filter that’s actually being passed to my ldap. I’m not confident that openfire is forming the query correctly since the same filter works everywhere else.

6

I’m not familiar with freeIPA, but I’m basically do what you are trying to accomplish with AD/LDAP without any issue. Here is a doc I wrote up on AD/LDAP. How to Setup Dynamic Groups and Shared Rosters with LDAP/AD Maybe it will help, maybe not. Sorry I can’t be more helpful.

7

Thanks, but I’ve already followed that document. I found the ldap debug options and set both of them to true (not sure why there’s 2… ldap.ldapDebugEnabled and ldap.debugEnabled). I can now see the request sent to and received from in the nohup.log (/opt/openfire/logs). It seems like as soon as I use any memberOf filter Openfire just stops the normal communication chain with LDAP.

In my slapd access logs for my main freeIPA node I see a successful bind and search for my admin user and then it immediately unbinds. If I change the filter to anything not containing memberOf, authentication works and it runs 3 or 4 searches before unbinding.

8

Issue resolved by setting an administrator dn and and password. I guess the memberOf attribute was protected and didn’t return without a user to bind on prior to searching.

Long story short: Do not attempt anonymous authentication if you want to filter users on memberOf.