We're updating the issue view to help you get more done. 

LDAP shared groups disappear after some time

Description

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.

Environment

AD LDAP, OpenLDAP

Acceptance Test - Entry

None

Activity

Show:
Tom Evans
October 31, 2014, 1:29 PM
Edited

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.

Steve Ballantyne
November 3, 2014, 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
November 3, 2014, 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, 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?

Steve Ballantyne
November 8, 2014, 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.

Assignee

Tom Evans

Reporter

wroot

Labels

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Affects versions

Priority

Major
Configure