powered by Jive Software

LDAP derived group list missing members

I am using OpenFire 3.3.2 installed via RPM on RedHat AS 3 with LDAP authentication configured for Active Directory. We have created a shared contact list (roster) using an existing LDAP group (let’'s call it DeptIT). The DeptIT LDAP group contains 46 users, but some of them show up differently in the group members list in the OpenFire administrative interface and do not appear at all in the client.

Using tcpdump watching the communications between my OpenFire server and my AD, I can see what appears to be communications populating this group. First, there is a search for the members of the group DeptIT, which returns the DNs of all 46 group members. Next, there are 46 individual queries - one for each member of the group. This search is looking for the sAMAccountName attribute of the user, with a simple CN (ie; CN=bob) filter and our base DN. The query uses no other filters (even though we have a searchFilter specified in the config). Usually, the query produces only one response per person, but for a few people (the ones missing from the roster!) LDAP produces 2 responses. In the case of the missing people, the first response received is a computer registered with the domain that has the same starting CN as the user (ie; CN=bob,CN=computer,DC=xxx,DC=yyy and CN=bob,OU=staff,OU=accounts,DC=xxx,DC=yyy). If the response comes back with the person listed first, they show up in the roster.

I can see two possible fixes, but do not know how to implement either; 1) have OpenFire use the complete DN of the user when it’'s performing the second search or 2) have OpenFire use the “searchFilter” from the config so that only users (and no computers) come back in the response. Any ideas??

First things first: set ldapDebugEnabled to true in your config, and then enable Debugging in the Logs page of the admin console. Openfire will then log all of the LDAP traffic for you so you don’'t have to rely on tcpdump.

If you have a searchFilter defined in your config, check the error logs to make sure it’‘s not throwing it out due to the fact that the query is invalid (ie. improper formatting, and such). For what it’'s worth, my searchFilter looks like this:

(&(objectCategory=Person)(memberOf=CN=JabberAccess,OU=Security Groups,OU=Groups,DC=example,DC=com))

Note that the ampersand must be escaped in the XML as &. And just for fun, here’'s my groupSearchFilter:

(&(objectClass=group)(memberOf=CN=JabberAccess,OU=Security Groups,OU=Groups,DC=example,DC=com))

The debug log shows my searchFilter as:

searchFilter: (&(objectClass=organizationalPerson)(!(objectClass=computer)))

and is not complaining about it. The debug log shows an error for the missing users (I assume this is during roster population):

2007.07.19 14:41:34 Trying to find a user’'s DN based on their username. sAMAccountName: baduser$, Base DN: dc=xxx,dc=yyy…

2007.07.19 14:41:34 Creating a DirContext in LdapManager.getContext()…

2007.07.19 14:41:34 Created hashtable with context values, attempting to create context…

2007.07.19 14:41:34 … context created successfully, returning.

2007.07.19 14:41:34 Starting LDAP search…

2007.07.19 14:41:34 … search finished

2007.07.19 14:41:34 User DN based on username ‘‘baduser$’’ not found.

2007.07.19 14:41:34 Exception thrown when searching for userDN based on username ‘‘baduser$’’

org.jivesoftware.openfire.user.UserNotFoundException: Username baduser$ not found

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:626)

A good user looks like this:

2007.07.19 14:41:34 Trying to find a user’'s DN based on their username. sAMAccountName: gooduser, Base DN: dc=xxx,dc=yyy…

2007.07.19 14:41:34 Creating a DirContext in LdapManager.getContext()…

2007.07.19 14:41:34 Created hashtable with context values, attempting to create context…

2007.07.19 14:41:34 … context created successfully, returning.

2007.07.19 14:41:34 Starting LDAP search…

2007.07.19 14:41:34 … search finished

2007.07.19 14:41:34 Creating a DirContext in LdapManager.getContext()…

2007.07.19 14:41:34 Created hashtable with context values, attempting to create context…

2007.07.19 14:41:34 … context created successfully, returning.

The debug log is not showing the search that led it to query for these users, nor is it showing enough detail of the exact search, but again using tcpdump, I can see that the searchFilter is not applied for some user searches. If I search for one of my users in admin console on the user search screen I can see the searchFilter applied and the user is shown on the screen (including correct group membership). It’‘s just when the roster is populated it’'s not using the searchFilter.

Maybe I’'m running into this: http://www.igniterealtime.org/issues/browse/JM-1048 ?