I'm not sure I understand the issue you describe. In fact, groups appear to be cached on a per-operation basis, and user membership is evaluated using the authorized identity (B in your case), so the behavior should be correct. I've made a simple check using re23 and things appear to work as expected: I log in as a user (A) that is not in a group and authorize as a user (B) that is in that group. I previously configured slapd so that only members of that group are allowed to read an attribute in the whole db (say "cn"). Things work as expected: if I login as user A I can't see "cn", but if I either log in as user B, or login as user A and proxyAuthz as B I can read the "cn". Can you provide a simple example (slapd.conf, db.ldif and sequence of operations, e.g. in a shell script) that causes the issue you see?

I think the point is that the group must be evaluated already in the search for the AuthzTo attribute.

So my User A has the AuthzTo attribute set to User B and I have the following access control:

access to * by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" write by * break

...

access to * attrs=authzTo by self read by * break

...

User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when I log in as user A and proxyAuth to Openldap will evaluate the group membership for A and cache it, during the search for the ACL to authzTo. A is not member.

Now when the actual search operation takes places, openldap will used the cached result (which was "is not member"), which is wrong because the user has changed since the group membership was cached.

I hope this makes the problem more clear (I have a test environment here, but it is very complex and easy transferable)

Gerald

** Virus checked by BB-5000 Mailfilter **