Open 389-ds-bot opened 4 years ago
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2017-11-03 01:22:33
This is a very odd behaviour. @tbordaz do you know much about this part of the aci code? Perhaps we have something in the aci cache being left over causing this?
389-ds-bot
commented
4 years ago Comment from firstyear (@Firstyear) at 2017-11-03 01:22:33
Metadata Update from @Firstyear:
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2018-04-05 17:48:04
Metadata Update from @mreynolds389:
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2019-08-23 19:54:26
Metadata Update from @mreynolds389:
389-ds-bot
commented
4 years ago Comment from mreynolds (@mreynolds389) at 2020-02-13 17:40:11
Metadata Update from @mreynolds389:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49438
Issue Description
ACIs that are based on memberof#GROUPDN, e.g. something like userattr = "ldap:///ou=groups,dc=feature,dc=root?memberof#GROUPDN"; may fail to retrieve entries, even though the ACIs say they are visible to the bind user
Package Version and Platform
Red Hat Enterprise Linux Server release 7.4 (Maipo) 389-ds-base-1.3.6.1-19.el7_4.x86_64
Steps to reproduce
Hide users within a given branch from anonymous access and generally any non ACI-based visibility.
Grant access to a bind-user or functional account user to search and see some of those users, based on them being member of a group. Base the access on an ACI using memberof#GROUPDN e.g. aci: (targetattr != "aci || userPassword") (targetfilter="objectclass=inetOrgPerson") (version 3.0;acl "Grant generalized access";allow (read,compare,search) userdn="ldap:///cn=*,ou=functional,dc=feature,dc=root" and userattr = "ldap:///ou=groups,dc=feature,dc=root?memberof#GROUPDN";)
Within one same connection (important!), do a couple searches, for example based on UID: (uid=user_i_can_see) (uid=user_that_does_not_exist) (uid=user_i_can_see) (uid=user_that_exists_but_that_i_can_not_see) (uid=user_i_can_see)
Actual results
(uid=user_i_can_see) Found 1 entry
(uid=user_that_does_not_exist) Found 0 entries
(uid=user_i_can_see) Found 1 entry
(uid=user_that_exists_but_that_i_can_not_see) Found 0 entries
(uid=user_i_can_see) Found 0 entries (<- broken)
Expected results
The final "(uid=user_i_can_see)" should return the same "Found 1 entry"... however, once you searched for a user that exists but that you can't see, within one same connection, you will not find anything anymore.
As a workaround, you can
either grant individual access to all of your bind-users: aci: (targetattr != "aci || userPassword") (targetfilter="(&(objectClass=inetOrgPerson)(memberOf=cn=group one,ou=groups,dc=feature,dc=root))") (version 3.0; acl "Grant one"; allow (read,search,compare) (userdn = "ldap:///cn=functional one,ou=functional,dc=feature,dc=root") ;) Which, while working, does not really scale beyond 2 bind-users;
or include the group membership in the query, i.e. (&(memberof=cn=group one,ou=groups,dc=feature,dc=root)(uid=...)) The order matters here, memberof= must come before uid= Which, while working, does not really scale, and can not, as a general rule, be reinforced, as some applications may not even allow that level of customization.