Repository navigation
LDAP - user in multiple groups not working #13426
Description
Steps to reproduce
Users are member of multiple groups
Expected behaviour
In user backend the groups per member should be ticked for all valid groups
Actual behaviour
If a user is member of multiple groups the backend lists random memberships: valid groups but not all. There are side effects in different apps (e.g. calendar via caldav not synchronizing for shared calendars)
Causes
I have located the bug in file group_ldap.php
private function getGroupsByMember($dn, &$seen = null) {
...
$groups = $this->access->fetchListOfGroups($filter,
array($this->access->connection->ldapGroupDisplayName, 'dn'));
}function fetchListOfGroups in lib/access.php expects as 3rd parameter a $limit (set to null by default)
Workaround (Bugfix?)
I have set that parameter to 500 and the user list and the group memberships are populated as expected.
$groups = $this->access->fetchListOfGroups($filter,
array($this->access->connection->ldapGroupDisplayName, 'dn'), 500);There might be more $limit parameters not set to valid values or left as null.
Activity
karlitschek commentedon Jan 16, 2015
@blizzz
blizzz commentedon Jan 16, 2015
@PeteSSS does this fix it for you? #13280
PeteSSS commentedon Jan 16, 2015
No. I had already applied that fix. It seems for me that the $limit parameter has values set in former calls.
PeteSSS commentedon Jan 17, 2015
Not to forget:
We have ~200 owncloud user and they have confirmed: calendars now synchronizing as they should do.
flattermann commentedon Jan 20, 2015
@PeteSSS
Thanks, the workaround works fine!
My users are now able to access their shared calendars again...
flattermann commentedon Jan 20, 2015
BTW: I also tried the patch from #13280, but that did not solve the problem for me.
fnerdwq commentedon Jan 26, 2015
@PeteSSS: Thanks to your fix, my problem solved as well - only one group membership was shown for a given user (actually the reverse listing users in group is correct anyway).
blizzz commentedon Mar 24, 2015
Does #14707 fix your issue?
PeteSSS commentedon Mar 24, 2015
Doesn't fix it.
Why is it so difficult to solve this problem?
blizzz commentedon Mar 24, 2015
The limit parameter is optional. Passing 500 indiciates that there is an issue when it is initiated with 0. That you get "random" groups, is somewhat bogus though.
To make sure: when tested it, the results where not taken from cache (by default LDAP results are cached for 10 minutes).
PeteSSS commentedon Mar 24, 2015
No, I have used a fresh installation of owncloud 7.
PeteSSS commentedon Mar 24, 2015
I have to apologize: The fix solves the problem. I had inserted the new code at the wrong place.
Thank you, blizzz.
blizzz commentedon Mar 24, 2015
@PeteSSS Glad it works! Thank you for testing!
lchigami commentedon Mar 29, 2016
This bug still persists in OwnCloud 9.0
Why was this ticket closed?
Every time I update my Owncloud through apt, I have to manually patch the code with the workaround...
blizzz commentedon Mar 29, 2016
@lchigami what exactly do you patch? #14707 was merged. You might want to open a new issue.
sirbeagle commentedon Jun 20, 2016
We ran across this bug in ownCloud v9.0.2 as well - users coming from Active Directory via LDAP were only a member of a single group. Implementing the fix from @PeteSSS seemed to do the trick - users now belong to multiple groups. We made the change to the
getGroupsByMemberfunction at line 570 in the file/apps/user_ldap/group_ldap.php.sirbeagle commentedon Jun 21, 2016
@blizzz We upgraded to 9.1 beta 2 and still have the same issue - we only see our LDAP users as a member of a single group each. We made the same change listed at the top of the issue and the group mapping then worked properly. For reference we changed line 576 in
/apps/user_ldap/lib/Group_LDAP.phpand added in an extra parameter of500and all seems to be good.worim commentedon Jul 20, 2016
Problem still exists. Set up a new ownCloud 9.0.2 and still needed to add the 500 to line 570. Please reopen and fix.
Update Group_LDAP.php
lock commentedon Aug 3, 2019
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.