The last patch I sent you was not addressing this issue. In this case, I believe the software is behaving as expected, according to the discussion in <http://www.openldap.org/lists/openldap-devel/200701/msg00056.html>. What the patch should give you, is the capability to compare the "member" of the dynlist, assuming the identity you use has "compare" privs on the attributes in the URL's filter. Would this be of help? In any case, could you try it?
--On January 16, 2007 6:34:39 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote:
Quanah Gibson-Mount wrote:
This patch also does not work, continuing to use the credentials of the bound user.
What operation are you performing when it gets to evaluate that filter? Can you describe it a little bit further?
ldapsearch -LLL -Q -h ldap-dev1 -b "cn=groups,cn=applications,dc=stanford,dc=edu" cn=registry-consult
Output is:
dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu
objectClass: groupOfURLs
cn: registry-consult
memberURL: ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=registr
y:consult)
(but no members). Searching with my admin credentials, I get a full user list.
access to dn.exact="cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu"
by dn.base="uid=cadabra,cn=accounts,dc=stanford,dc=edu" sasl_ssf=56 read
by * none
is the ACL in place (admin group comes before this acl with full read to everything in the tree).
p.