Quanah Gibson-Mount wrote:
--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).
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?
p.