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)
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.
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
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.
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.
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.
This is great. Worked perfectly for me. Thanks for providing the patched jar… really didn’t feel like downloading source, compiling and crossing fingers…