When editing a user, groups and roles tabs shows membership to groups stored outside the configured groups DN

Description

Our client LDAP has an OU that contains groupOfNames and groupOfUrls objects that are used/managed by Alfresco. The client is not interested to manage or view these memberships with FD.

Distribution Name and Version

FusionDirectory Version

1.1

PHP version used

Origin of php packages

Steps to Reproduce

1. we have configured FD to look for groups elsewhere. Note that FD won't see these groups even if configured to look at the right place as they're missing the "gosaGroupOfNames" class.
2. When editing a user, groups and roles tabs shows memberships to groups stored outside the configured groups DN.
3. If we try to remove or add new membership, we got an error : "The supplied base is not valid and has been reset to the previous value!".

It look strange for our customer to see these groups in the user tab while in groups and roles, these groups are not shown.

Expected behavior:

They should not show up in current and proposed list of membership, needless to say not be lost when adding/removing regular FD groups memberships.

Actual behavior:

Reproduces how often:

Additional Information

changed the description

By bmortier on 2017-10-16T13:52:07 (imported from GitLab)

added technical discussion label

By bmortier on 2017-10-16T13:52:58 (imported from GitLab)

changed the description

By bmortier on 2017-10-16T14:00:32 (imported from GitLab)

Hello,

i transfered your bug report into the new bug report template, can you fill the blank and add some more detailed info, ldif etc so we can see how to fix this

Cheers

By bmortier on 2017-10-16T16:07:43 (imported from GitLab)

The filter for group object type is objectClass=groupOfNames. This is because if a user has groups created outside of FD this allows him to see them in FD and edit them. FD will add the gosaGroupOfNames upon save. This goes in the same effort than using only standard objectClasses for users, sadly we could not get rid of gosaGroupOfNames but we removed it from the filter.

In FD an object type is usually defined by its filter, and sometimes by its branch. This is the problem here, group membership uses objects::ls which does not check branch. I found that management classes, even in subtree mode, does check the branch, but in not in a perfect way. This code uses dn filters, so for groups it will search with ou:dn:=groups in the filter. This can return false positive, as an entry in ou=something,ou=groups,dc=base will be returned as well. So I guess management searches and object::ls searches should use the same system for consistency. I will look into refactoring this, but for now we will still have the false positive risk as I do not see obvious solution for this (other than testing all found dn, which may be slow)

By Côme Chilliet on 2017-10-16T15:01:35 (imported from GitLab)

created branch 5583-when-editing-a-user-groups-and-roles-tabs-shows-membership-to-groups-stored-outside-the-configured-groups-dn

By Côme Chilliet on 2017-10-16T15:36:27 (imported from GitLab)

mentioned in merge request !44

By Côme Chilliet on 2017-10-16T15:36:29 (imported from GitLab)

mentioned in commit 5ed58458

By Côme Chilliet on 2017-10-16T15:40:42 (imported from GitLab)

added 1h of time spent

By Côme Chilliet on 2017-10-16T15:41:26 (imported from GitLab)

added To Be Tested label

By Côme Chilliet on 2017-10-17T10:04:15 (imported from GitLab)

added Changed label

By bmortier on 2017-12-11T14:23:27 (imported from GitLab)

removed technical discussion label

By bmortier on 2018-02-06T08:48:59 (imported from GitLab)

added PJ1802-0188 label

By Jonathan Swaelens on 2018-03-13T13:35:42 (imported from GitLab)

I just tested it on demo-dev. I confirm that now the groups and roles tab on an user show only the groups that are in FusionDirectory group RDN.

By Jonathan Swaelens on 2018-03-14T15:43:22 (imported from GitLab)

closed

By Jonathan Swaelens on 2018-03-14T15:43:22 (imported from GitLab)

added 30m of time spent at 2018-03-14

By Jonathan Swaelens on 2018-03-14T15:43:23 (imported from GitLab)

removed To Be Tested label

By Jonathan Swaelens on 2018-03-14T15:43:24 (imported from GitLab)

removed Bugs label

By bmortier on 2018-04-05T11:39:14 (imported from GitLab)