freeipa

#9033 Group membership for roles is only inherited three levels deep
Closed: wontfix by rcritten. Opened by eiclu.

Closed: wontfix
Reopen Issue

Issue

In IPA you can assign roles to groups of users.

This means, that all users, which are members of a group (direct membership), or members of a group, which is itself a member of the group (indirect membership), become members of this role.

But in testing I discovered this only works three levels deep. If you go down a fourth level in the group hierarchy, suddenly the user does not get the permissions assigned to the role any more, even though they should have it by indirect membership.

Steps to Reproduce

  1. Create a permission "Test - Employeetype" giving read access to the user field "employeeType"
  2. Create a privilege "Test - Employeetype" containing the permission "Test - Employeetype"
  3. Create a role "Test - Employeetype" containing the privilege "Test - Employeetype"
  4. Give the role "Test - Employeetype" the group "test-parent" as an user group member
  5. Give the group "test-parent" the group "test-child-1" as an user group member
  6. Give the group "test-child-1" the group "test-child-2" as an user group member
  7. Give the group "test-child-2" the group "test-child-3" as an user group member
  8. Add the test user to group "test-child-2" (first test)
  9. Check if the attribute "employeeType" is visible -> true
  10. Remove user from group "test-child-2", then add them to group "test-child-3" (second test)
  11. Check if the attribute "employeeType" is visible -> false

Expected behavior

User is always permitted to see the "employeeType" field

Actual behavior

User is prohibited from viewing the "employeeType" field when a member of group "test-child-3", even though they should inherit the permission to view this field

This is the result of ldapsearch on the user used to test this:

# When assigning the user to the group "test-child-2":
memberOf: cn=test-child-2,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=test-child-1,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=test-parent,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=roles,cn=accounts,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=privileges,cn=pbac,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=permissions,cn=pbac,dc=test,dc=org
...
employeeType: test
# When assigning the user to the group "test-child-3":
memberOf: cn=test-child-3,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=test-child-2,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=test-child-1,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=test-parent,cn=groups,cn=accounts,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=roles,cn=accounts,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=privileges,cn=pbac,dc=test,dc=org
memberOf: cn=Test - Employeetype,cn=permissions,cn=pbac,dc=test,dc=org
...
# no employeeType field returned, even though the user is memberOf the permission according to ldap

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.9.2-4.module+el8.4.0+589+9650b94f.x86_64
ipa-client-4.9.2-4.module+el8.4.0+589+9650b94f.x86_64
389-ds-base-1.4.3.16-16.module+el8.4.0+596+159889e5.x86_64
pki-ca-10.10.5-3.module+el8.4.0+554+92b527a1.noarch
krb5-server-1.18.2-8.el8.x86_64

sssd has a setting for the max depth of nested group resolution (see man sssd-ldap(5)):

      ldap_group_nesting_level (integer)
           If ldap_schema is set to a schema format that supports nested groups (e.g. RFC2307bis), then this option controls how many levels of nesting SSSD will
           follow. This option has no effect on the RFC2307 schema.
           Note: This option specifies the guaranteed level of nested groups to be processed for any lookup. However, nested groups beyond this limit may be
           returned if previous lookups already resolved the deeper nesting levels. Also, subsequent lookups for other groups may enlarge the result set for
           original lookup if re-queried.
           If ldap_group_nesting_level is set to 0 then no nested groups are processed at all. However, when connected to Active-Directory Server 2008 and later
           using “id_provider=ad” it is furthermore required to disable usage of Token-Groups by setting ldap_use_tokengroups to false in order to restrict group
           nesting.
           Default: 2

Can you try to modify this value and chek if it affects the beahvior?

I think the original report is not about sssd treatment of the nested groups but rather evaluation of the membership within 389-ds LDAP server itself so that permissions granted through roles would allow to write to certain attributes or read them.

sssd has a setting for the max depth of nested group resolution (see man sssd-ldap(5)):
Can you try to modify this value and chek if it affects the beahvior?

I tried to add it to my /etc/sssd/sssd.conf, but it didn't change the behaviour

I think the original report is not about sssd treatment of the nested groups but rather evaluation of the membership within 389-ds LDAP server itself so that permissions granted through roles would allow to write to certain attributes or read them.

Yes. The permission problem I encounter happens when querying LDAP

@mreynolds @tbordaz is there a nesting limit in memberof in 389-ds? Is it configurable?

There is a maximum nesting level set by the backend and by default it is set to 5. I don't see anything that would allow to redefine it at runtime.

The only limit I found in member of is to https://directory.fedoraproject.org/docs/389ds/design/memberof-skip-nested.html, that is off by default.
I just think there is a safety mechanism to prevent loops.

@abbra what is the limitation on the backend side ? I missed it

The backend code sets a maximum nesting level which is then used by the ACL plugin to stop where ACL plugin unrolls the nested group membership. See SLAPI_BE_MAXNESTLEVEL handling.

The backend code sets a maximum nesting level which is then used by the ACL plugin to stop where ACL plugin unrolls the nested group membership. See SLAPI_BE_MAXNESTLEVEL handling.

Is this editable by me or does this need a new version of FreeIPA to change? @abbra

This is not configurable. However, I'm not sure that it is what affects you since the default is 5 levels deep and you have four.
This is not a FreeIPA issue but rather 389-ds.
Edited by abbra

I'm going to close this as it doesn't seem to be anything we can do on the IPA side.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.