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 <admin@dmarkey.com> 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: dmarkey@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.