Univention Bugzilla – Bug 45052
user should not be removeable from its primary group
Last modified: 2020-06-22 18:26:29 CEST
A user 'userA' with primaryGroup 'GroupX' is _allways_ member of this group. In openLDAP 'userA' is also added to this group via 'memberUid' and 'uniqueMember'. When you remove 'userA' from 'groupX' the primaryGroup of 'userA' is not touched - he still has primaryGroup 'groupX' and due to that is effectively member of this group. It seems to doesn't make sense to be able to remove the mapping of an user from it's primaryGroup. At least in UMC the user should be grayed out and not removeable.
So basically you want that the following modification is not possible anymore: # udm users/user create --set username=foo --set lastname=foo --set password=univention --set primaryGroup="cn=Domain Users,cn=groups,$(ucr get ldap/base)" Object created: uid=foo,dc=school,dc=local # udm groups/group modify --dn "cn=Domain Users,cn=groups,$(ucr get ldap/base)" --remove users="uid=foo,$(ucr get ldap/base)" Object modified: cn=Domain Users,cn=groups,dc=school,dc=local
Can you describe what the effects are if such a user exists?
*** Bug 45053 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #1) > So basically you want that the following modification is not possible > anymore: > > # udm users/user create --set username=foo --set lastname=foo --set > password=univention --set primaryGroup="cn=Domain Users,cn=groups,$(ucr get > ldap/base)" > Object created: uid=foo,dc=school,dc=local > # udm groups/group modify --dn "cn=Domain Users,cn=groups,$(ucr get > ldap/base)" --remove users="uid=foo,$(ucr get ldap/base)" > Object modified: cn=Domain Users,cn=groups,dc=school,dc=local imho there is a difference between UMC and udm(-cli); UMC users probably not as advanced as udm users, therefor the possibility to perform the udm action should not be restricted due to there might be situations where it totally makes sense to remove a user entry from a group - even when the primaryGroup of the user is left untouched.
(In reply to Florian Best from comment #2) > Can you describe what the effects are if such a user exists? It's quite confusing when the user is no longer member in it's primaryGroup but (of course) still has all the privileges due to the gidNumber is still the same as before. Also the connector skips to add a user to the specific group when it already is the users primaryGroup. This seems not to be a consistent behavior (but it's MS/AD standard), at least it is confusing too. If I'm wrong please point me to the right direction.
I once added a test case for this. r76583 | Bug #27160: add test case for bug
*** Bug 27160 has been marked as a duplicate of this bug. ***
Move to 4.3-0-errata. If a UCS 4.2 backport is needed, please clone this issue.