Re: SyncRepl Chaining

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Friday, September 06, 2013 12:21 PM -0500 espeake@oreillyauto.com 
wrote:


> add: olcAccess
> olcAccess: {0}to *
>     by dn.base="uid=syncrepl,ou=System,dc=oreillyauto,dc=com" read
>     by dn.base="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" read
>     by dn.base="uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com" write
>     by dn.base="uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com" write
>     by dn.base="uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com" write
>     break

This should be "by * break" not "break"

> I confirmed the changes by looking at the LDIF that the changes were made.
> Even though it's not supposed to be needed, I restarted the slapd service.
> TO me it looks like it is reading the break and moving to rule {2} but
> still no love or authentication.


> Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: => acl_mask: access to entry
> "uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com", attr "userPassword"
> requested
> Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: => acl_mask: to value by "",
> (=0)
> Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: <= acl_mask: no more <who>
> clauses, returning =0 (stop)

As noted in the SLAPD.ACCESS(5) man page:

      The search operation, requires search  (=s)  privileges	on  the 
entry
      pseudo-attribute  of  the  searchBase  (NOTE:  this was introduced 
with
      OpenLDAP 2.4).  Then, for each entry, it requires  search  (=s) 
	privi-
      leges  on the attributes that are defined in the filter.  The 
resulting
      entries are finally tested for read  (=r)  privileges  on  the 
pseudo-
      attribute entry (for read access to the entry itself) and for read 
(=r)
      access on each value of each attribute that is  requested.   Also, 
for
      each  referral  object  used in generating continuation references, 
the
      operation requires read (=r) access on the pseudo-attribute entry 
(for
      read access to the referral object itself), as well as read (=r) 
access
      to the attribute holding the referral information  (generally  the 
ref
      attribute).

You have no ACL granting access to the pseudo-attribute "entry".

I personally have as my last ACL:

olcAccess: {10}to attrs=entry  by dn.children="cn=admins,cn=zimbra" write 
by *
 read

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration