LDAP group bug?

We have an issue where some user do not appear in the roster driven by LDAP groups with
Active Directory. It seems that if there is a user who has the same “cn=” portion of the
distinguishedName as a computer or other AD object that sometimes the code below in
LdapGroupProvider.java find the computer or other AD object instead of the user:

338 else {
339 // Create an LDAP name with the full DN.
340 LdapName ldapName = new LdapName(username);
341 // Turn the LDAP name into something we can use in a
342 // search by stripping off the comma.
343 String userDNPart = ldapName.get(ldapName.size() - 1);
344 NamingEnumeration usrAnswer = ctx.search("",
345 userDNPart, searchControls);
346 if (usrAnswer != null && usrAnswer.hasMoreElements()) {
347 Attribute usernameAttr = ((SearchResult)usrAnswer.next()).getAttributes().get(manager.getUsernameField() );
348 if (usernameAttr != null) {
349 username = (String)usernameAttr.get();
350 }
351 }
352 // Close the enumeration.
353 usrAnswer.close();

It appears that taking the cn= part of the distinguished name (see line 343) and doing a search
on just that (line 344) can return multiple objects. If we have a user 'cn=abcd,ou=staff,dc=domain,dc=edu’
and a computer ‘cn=abcd,ou=computers,dc=domain,dc=edu’ the search will return both. Depending on
which one is returned first, the usename attribute being looked for here could be wrong (the computer would
have the samaccountname of ‘abcd$’). Shouldn’t the search include our LDAP user filter?

The error logs seem to bear this out for the users we have trouble with:

2008.08.19 19:09:01 [org.jivesoftware.openfire.roster.Roster.(Roster.java:177)] Groups ([DeptTest]) include non-existent username (abcd$)

Am I reading this correctly and does this explain our missing roster users?

Not being a java programmer, I was hesitant to try anything with this but having folks repeatedly asking me why members of groups were missing (we were up to 11 missing users) got me moving. I hacked at the above section of code and was able to resolve this bug for our organization. I am including a patch in case it’s helpful to others. Sorry if I had reported the bug in the wrong place, please feel free to point me to the correct spot.
LdapGroupProvider.patch (1692 Bytes)

Hi Roba,

Could you compare your issue to this one?

http://www.igniterealtime.org/issues/browse/JM-851

daryl

Could you tell me how to apply this patch? I would def like to try this out.

TIA

Daryl, I do not think these bugs are related. Our issue was strictly with users for which an unfiltered query on the CN= portion of their DN would return more than one result; like in the case of a computer and user with the same name (eg; cn=rob,ou=users,dc=company,dc=com and cn=rob,ou=computers,dc=company,dc=com).

You’ll first want to make sure you can build openfire from source. There are instructions in the source tree. Once you can build from source, apply the patch against the LdapGroupProvider.java file and replace the openfire.jar file in your system with the one produced by applying the patch and rebuilding. Restart openfire. Keep a copy of the original openfire.jar file!

This probably will only help you if you see this sort of message in your error log:

2008.08.19 19:09:01 [org.jivesoftware.openfire.roster.Roster.(Roster.java:177)] Groups ([DeptTest]) include non-existent username (abcd$)

I’ve only done this the one time - it is not something I normally do, so if anyone has suggestions for the ‘recommended’ way to apply patches to openfire, please chime in.

Aghhh - haha - thanks

How long does it usually for the developers to look at bugs reported here?

Thank you roba. You solved my problem. I was still using wildfire 3.0.1 due to this issue

Hi Roba,

Do you know if the patch has been filed in Jira? If not, I’ll place it there…

daryl

I don’t think so. There doesn’t seem to be a bug listed there for the problem. My patch should probably be reviewed/tested by an actual java programmer before submitting

Hi,

I filed it here:

http://www.igniterealtime.org/issues/browse/JM-1517

I am not familiar at all with this part of openfire, so not sure what to say

daryl

Confirmed this is a definite bug with openfire 3.6.3 and 3.6.2. I found this thread after trying to figure out why our admin accounts were showing up instead of our regular group accounts, and sure enough it was the CN issue.

I built Openfire 3.6.3 from source after applying the patch and moved the new openfire.jar over to my RPM install, restarted openfire, and the issue is resolved.

I’m posting the updated jar file here for those of you who don’t compile from source (it was my first time, not horrible but definitely not fun) - I can’t make any promises that it will work but it’s working for me and that’s all I care about.

Here’s a vote for inclusion of this in 3.6.4!
openfire.jar (6414748 Bytes)

I applied the new openfire.jar file and still no luck. Looking at one particular group in AD, I see 14 users but Openfire only finds 6 users in this group. I did a re-start on Openfire. Did I need to do a machine restart? Any help here is appreciated. I’d love to get this up and going.

Running AD in 2003 Server Std.

Thanks!

Yeah, I dropped the new jar file in a vanilla RPM install of 3.6.3, stopped and started openfire, and ran through the setup again. It fixed my issue with the dupclicate CN’s.

Maybe the bug is bigger or you’re dealing with a slightly different issue. The patch applied was only to fix an issue with group lookups finding the wrong users due to having multiple CN’s in the directory. In our example, if we had a user john.doe and admin.jdoe (admin accounts are privileged on the domain, the regular accounts are not), and both had John Doe in the CN field, openfire was matching on whatever it found first…so in our case we had our admin accounts showing up in the roster when it should have been our user accounts.

Hope this helps.

EDIT: rich, are the missing users showing up in the Openfire USER roster? check that, if they’re not showing in the user roster, they won’t show in the group roster.

Strange things afoot…

  1. Some users are showing up in Openfire groups that they are not members of in AD

  2. Some users are not showing up at all

  3. Some groups are missing members in Openfire but the users themselves are listed.

Any ideas?

Thanks

Updated Openfire.jar for 3.6.4 - installed this morning and working great!
openfire.jar (6415166 Bytes)

1 Like

Hi ,

Whether this issue has been fixed in OpenFire 3.6.4, as i am facing same problem in fedora Linux openfire 3.6.4 version.

Please help me here.

My problem is that if same CN= name person are there in any AD group (Distributaion list in AD/LDAP) only one is appearing always even though i have not added that person in AD group.

Thanks

Prashant

This is great. Worked perfectly for me. Thanks for providing the patched jar… really didn’t feel like downloading source, compiling and crossing fingers…

Hello,

Please consider using the 3.7.0 beta release. It contains this fix and a bunch more. The beta is very stable and should become the final release soon.

daryl