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.