RE: Syncrepl and mmr

["Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>]

Thanks Quanah...

Question, about the "manage" Access Level when would that be used?

It is not talked about at all other than Table 5.4 in section 8.3.3.



-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] 
Sent: Thursday, January 30, 2014 4:12 PM
To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org
Subject: RE: Syncrepl and mmr

--On Thursday, January 30, 2014 3:28 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu> wrote:

> Thanks Quanah...
>
> Now, I'm going to ask this...
>
> My current ACL is:
>
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by 
> anonymous auth by * none olcAccess: {1}to * by * read
>
> Supposed this allows the user to modify their userPassword and (in so
> doing) modifying the shadowLastChange, allows anonymous to 
> authenticate against these entries and allows others to read these 
> entries
>
> Am I reading that correctly...or at least close?
>
> To give my syncrepl user (ldapadmin) access, my new ACL would another
> olcAccess:
>
> olcAccess:{2}to * by cn=ldapdmin manage
>
> Is that correct?

I would suggest you re-read the documentation on ACLs.  As noted in the ACL documentation, ACL processing STOPS on the first matching ACL by default. 
So NO ACL is evaluated for userPassword and ShadowLastChange if they do not match the self write, anonymous auth bits.  What you would want is something like:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by replicauser read by * none
olcAccess: {1}to * by * read

I.e, specifically grant read access to those 2 attrs to whatever the DN is for your replication user.

--Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration