LDAP shared groups disappear after some time
Description
Environment
Attachments
is related to
Activity
Steve Ballantyne November 8, 2014 at 12:42 PM
I may have curbed this issue by limiting the scope of my AD searches by Openfire. My AD was not designed well at all. I have a lot of first-level OU's for departments. Then second level OU's under each of those for users and groups. So if I want to search for users and groups, I really need to search the entire AD.
Per a helpful community post, I created a new OU and put two groups in it. One Domain Local group called "Spark Groups" contains all the groups I want to use. Another Domain Local group called "Spark Users" contains all of the users. This is a PITA because it's redundant, and you have to put all those users in to the Users group, even though they are also in the Groups group.
But then I was able to have Openfire use that single OU as it's base DN. Now, when I browse users/groups from the admin console, it's very fast. And I have not yet had any of these buggy problems since then.
My guess is that there was a single group causing the issue ... or there are just too many groups and users, and Openfire was timing out when trying to find them all.
Steve Ballantyne November 3, 2014 at 6:44 PM
Argh! Sorry Tom, since confirming that this is fixed - I have had two users come up with empty rosters who had to restart Spark to get their list back. Sorry about that. It seems that this is still not fixed.
I have been running a capture of XML on the server side, but the user that I was monitoring client-side has been out of the office. Would you want a one-sided XML capture?
Tom Evans November 3, 2014 at 5:57 PM
OK, thanks for the feedback. We will mark this as resolved for now, pending 3.10.0 release.
Steve Ballantyne November 3, 2014 at 3:31 PM
Hello Tom, I think that you have fixed it with this patch. I have queried a few users who have always had this issue - and none of them have had the problem since I applied the patched version.
Tom Evans October 31, 2014 at 1:29 PMEdited
That's great Steve, thanks.
Note that there is one additional setting that may help if further troubleshooting is needed. You can set the system property "ldap.debugEnabled" to "true", followed by an Openfire restart. This will enable more detailed logging and provide additional detail in the debug log regarding ongoing LDAP connections and queries.
Note that we also fixed another unrelated issue in this build () to retain the debug log enabled setting across server restarts.
Details
Details
Assignee
Reporter
Labels
Components
Fix versions
Affects versions
Priority
Major
At least 5 users report issues with LDAP after upgrading to 3.9.3.
3.9.2 seems to work correctly.
When using shared groups pulled from LDAP, after some time they disappear in the clients. Then a workaround is to uncheck sharing on a group, save it, check sharing again and save it. This will work some times, but with various degree of success.