Re: Strange behavior with relay backend and ACLS

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. #
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
26. # search result
27. search: 2
28. result: 0 Success
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.