I see what the problem is. for the ACL to be effective the client needs to request the memberof attribute:
Robinson:/opt/openldap/etc/openldap # ldapsearch -x -b dc=thunderbird uid=dmarkey # extended LDIF # # LDAPv3 # base <dc=thunderbird> with scope subtree # filter: uid=dmarkey # requesting: ALL # # dmarkey, user, thunderbird dn: uid=dmarkey,ou=user,dc=thunderbird objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: krb5Principal objectClass: krb5KDCEntry objectClass: sambaSamAccount sn: Markey givenName: David uid: dmarkey mail: dmarkey@<snip> cn: David Markey Staff # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Robinson:/opt/openldap/etc/openldap # ldapsearch -x -b dc=thunderbird uid=dmarkey uid # extended LDIF # # LDAPv3 # base <dc=thunderbird> with scope subtree # filter: uid=dmarkey # requesting: uid # # search result search: 2 result: 0 Success # numResponses: 1 Robinson:/opt/openldap/etc/openldap # ldapsearch -x -b dc=thunderbird uid=dmarkey uid memberof # extended LDIF # # LDAPv3 # base <dc=thunderbird> with scope subtree # filter: uid=dmarkey # requesting: uid memberof # # dmarkey, user, thunderbird dn: uid=dmarkey,ou=user,dc=thunderbird uid: dmarkey memberOf: cn=tech,ou=groupofnames,dc=thunderbird memberOf: cn=staff,ou=groupofnames,dc=thunderbird memberOf: cn=testing,ou=groupofnames,dc=thunderbird # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But the problem is, the client(in this case thunderbird) doesnt request memberof, so the ACL blocks all the entries. Anyone know how i could get around this? Any help appreciated. Thanks. On Sun, Mar 15, 2009 at 8:15 PM, David <[email protected]> wrote: > With a relay backend, when i enable an ACL then i can only get back full > entries, but not specific attributes: > > > > 1. # extended LDIF > 2. # > 3. # LDAPv3 > 4. # base <dc=thunderbird> with scope subtree > 5. # filter: uid=dmarkey > 6. # requesting: ALL > 7. # > 8. > 9. # dmarkey, user, thunderbird > 10. dn: uid=dmarkey,ou=user,dc=thunderbird > 11. objectClass: top > 12. objectClass: person > 13. objectClass: organizationalPerson > 14. objectClass: inetOrgPerson > 15. objectClass: posixAccount > 16. objectClass: shadowAccount > 17. objectClass: krb5Principal > 18. objectClass: krb5KDCEntry > 19. objectClass: sambaSamAccount > 20. sn: Markey > 21. givenName: David > 22. uid: dmarkey > 23. mail: dmar...@xxxx > 24. cn: David Markey Staff > 25. > 26. # search result > 27. search: 2 > 28. result: 0 Success > 29. > 30. # numResponses: 2 > 31. # numEntries: 1 > > Thats normal, Now we'll try to just get the mail attribute: > > > 1. Robinson:/opt/openldap/etc/openldap # ldapsearch -b dc=thunderbird > -x uid=dmarkey mail > 2. # extended LDIF > 3. # > 4. # LDAPv3 > 5. # base <dc=thunderbird> with scope subtree > 6. # filter: uid=dmarkey > 7. # requesting: mail > 8. # > 9. > 10. # search result > 11. search: 2 > 12. result: 0 Success > 13. > 14. # numResponses: 1 > > Nothing is returned. > > Here is the relay database definition > > > database relay > suffix "dc=thunderbird" > relay "dc=example,dc=ie" > overlay rwm > overlay memberof > rwm-rewriteEngine on > rwm-suffixmassage "dc=example,dc=ie" > > map attribute cn gecos > map attribute mail * > map attribute uid * > map attribute sn * > map attribute givenname * > map attribute memberof * > map attribute * > > > > > access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" > by * read > > > > > Anyone see what im doing wrong here? > > > Thanks. > > >
