Re: Strange behavior with relay backend and ACLS

[David <admin@dmarkey.com>]

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.