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:[email protected]] Sent: Thursday, January 30, 2014 4:12 PM To: Borresen, John - 0442 - MITLL; [email protected] Subject: RE: Syncrepl and mmr --On Thursday, January 30, 2014 3:28 PM -0500 "Borresen, John - 0442 - MITLL" <[email protected]> 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
