On 2022-02-17 17:26, Rob Crittenden via FreeIPA-users wrote:
Sigbjorn Lie via FreeIPA-users wrote:
> On 2022-02-17 13:52, Alexander Bokovoy via FreeIPA-users wrote:
>> On to, 17 helmi 2022, Sigbjorn Lie-Soland via FreeIPA-users wrote:
>>> Hi list,
>>>
>>> We recenlty upgraded our IPA environment from EL7.9 to EL8.5. And
>>> now
>>> we are testing out the new Member Manager feature.
>>>
>>> Adding a usergroup (example: "role-groupmanager") as a
MemberManager
>>> for another group (example: "role-usergroup-A") yields an error
>>> message
>>> when the user member of the "role-groupmanager” group (example:
>>> “thorleif”) attempts to add/remove users from the group
>>> "role-usergroup-A”:
>>>
>>> "Insufficient access: Insufficient 'write' privilege to the
'member'
>>> attribute of entry"
>>>
>>> If I add the user “thorleif” directly as a MemberManager of the
>>> group
>>> "role-usergroup-A”, allows him to successfully add and remove users
>>> from the group "role-usergroup-A”.
>>>
>>> I presume this is a bug? Is there a known BZ for this or do you need
>>> me
>>> to open one?
>>
>> According to the design document,
>>
>> -------------------------------------------------------------------
>> Member managers are stored in a new LDAP attribute ``memberManager``
>> with OID 2.16.840.1.113730.3.8.23.1. It is multi-valued and contains
>> DNs of users and groups which can manage members of the group. The
>> attribute can be added to entries with object class ``ipaUserGroup``
>> or ``ipaHostGroup``. The attribute is indexed and its membership
>> controlled by referential integrity postoperation plugin.
>> New userattr ACIs grant principals with user DN or group DN in
>> ``memberManager`` write permission to the ``member`` attribute of the
>> group.
>>
>> The ``memberManager`` attribute is protected by the generic read and
>> modify permissions for each type of group. It is readable by
>> everybody
>> with ``System: Read Groups`` / ``System: Read Hostgroups`` permission
>> and writable by everybody with ``System: Modify Groups`` /
>> ``System: Modify Hostgroups`` permission.
>> -------------------------------------------------------------------
>>
>> So there are two parts here: ACI and a proper object class
>> 'ipaUserGroup' for the group to manage (or 'ipaHostGroup' for
host
>> group to manage).
>>
>> Can you check that 'aci' attribute on cn=groups,cn=accounts,$SUFFIX
>> and
>> on cn=hostgroups,cn=accounts,$SUFFIX contains the following ACIs:
>>
>> # Allow member managers to modify members of user groups
>> dn: cn=groups,cn=accounts,$SUFFIX
>> aci: (targetattr = "member")(targetfilter =
>> "(objectclass=ipaUserGroup)")(version 3.0; acl "Allow member
managers
>> to modify members of user groups"; allow (write) userattr =
>> "memberManager#USERDN" or userattr =
"memberManager#GROUPDN";)
>>
>> # Allow member managers to modify members of a host group
>> dn: cn=hostgroups,cn=accounts,$SUFFIX
>> aci: (targetattr = "member")(targetfilter =
>> "(objectclass=ipaHostGroup)")(version 3.0; acl "Allow member
managers
>> to modify members of host groups"; allow (write) userattr =
>> "memberManager#USERDN" or userattr =
"memberManager#GROUPDN";)
>
>
> Thank you for the prompt reply!
>
> I see the following ACI on dn: cn=groups,cn=accounts,$SUFFIX
> aci: (targetattr = "member")(targetfilter =
> "(objectclass=ipaUserGroup)")(version 3.0; acl "Allow member managers
> to
> modify members of user groups"; allow (write) userattr =
> "memberManager#USERDN";)
>
> This differs from your example which includes both USERDN and GROUPDN
> in
> the ACI, while our ACI includes only USERDN.
>
> Looking at the ACI for dn: cn=hostgroups,cn=accounts,$SUFFIX results
> in
> the same issue.
> aci: (targetattr = "member")(targetfilter =
> "(objectclass=ipaHostGroup)")(version 3.0; acl "Allow member managers
> to
> modify members of host groups"; allow (write) userattr =
> "memberManager#USERDN";)
>
>
> Is there an existing BZ for this? As we recently upgraded we have just
> about all the recent EL8 patches installed.
I couldn't find one.
The problem is that the ACIs are defined in two places:
install/share/default-aci.ldif
install/updates/20-aci.update
default-aci.ldif has the ACI including GROUPDN but this isn't applied
on
upgrades.
20-aci.update has what you are seeing, USERDN only.
This will require two fixes: one to add the GROUPDN when the ACI is
missing and one to repair existing installs.
rob
_______________________________________________
Ok. I have opened the following BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=2056009
I will open a RH support case to back this request as well.
Thanks for helping in discovering the root cause quickly. :)