--089e0160b79ae9bb0c04edcfeff1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/12/18 ck@cksoft.de
This message is in MIME format. The first part should be readable text=
,
while the remaining parts are likely unreadable without MIME-aware tool=
s.
--4178219828-444410844-1387368134=3D:27797 Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed Content-Transfer-Encoding: 8BIT
Hi,
On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:
<snipp/> > Well, I checked that the pwdLockoutDuration was correctly set (The valu=
e
in my case is 1200, so 20 minutes, much more than my tests). Other proof, the values of pwdFailureTime are not erased, but replaced by those of the master.
It is of course also quite possible that you have hit a special corner case that nobody else has yet found.
I think so. I have to say that I use standard syncrepl, not
delta-syncrepl.
The best thing you could do would be to setup a small self contained test case to illustrate the problem.
I will try to, but seems really easy to reproduce : configure master an=
d
slave with ppolicy, lock an account in slave, update same account on master (change description) a first time and a second time.
are you sure the account lock actually arrives on the master ?
Are you using olcPPolicyForwardUpdates to actually get the account locked on the master and not only on the slaves ?
If you do not have all the lock attributes on the master and you modify the entry it will get replaced on the slaves.
Can you post your master and slave configs somewhere ?
I sent it by mail but I think it is too big and queued. So here is all configuration and test result:
Cl=E9ment.
--089e0160b79ae9bb0c04edcfeff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/18 <span dir=3D"ltr"><<a href=3D"mailto:ck@cksoft.de" t= arget=3D"_blank">ck@cksoft.de</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> =A0 This message is in MIME format. =A0The first part should be readable te= xt,<br> =A0 while the remaining parts are likely unreadable without MIME-aware tool= s.<br> <br> --4178219828-444410844-1387368134=3D:27797<br> Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed<br> Content-Transfer-Encoding: 8BIT<br> <br> Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> <div class=3D"im">> Well, I checked that the pwdLockoutDuration was corr= ectly set (The value<br> > in my case is 1200, so 20 minutes, much more than my tests). Other<br> > proof, the values of pwdFailureTime are not erased, but replaced by<br=
> those of the master.<br> ><br> ><br> >> It is of course also quite possible that you have hit a special co= rner<br> >> case that nobody else has yet found.<br> ><br> ><br> > I think so. I have to say that I use standard syncrepl, not delta-sync= repl.<br> ><br> ><br> >><br> >> The best thing you could do would be to setup a small self contain= ed<br> >> test case to illustrate the problem.<br> >><br> ><br> > I will try to, but seems really easy to reproduce : configure master a= nd<br> > slave with ppolicy, lock an account in slave, update same account on<b= r> > master (change description) a first time and a second time.<br> <br> </div>are you sure the account lock actually arrives on the master ?<br> <br> Are you using olcPPolicyForwardUpdates to actually get the account<br> locked on the master and not only on the slaves ?<br> <br> If you do not have all the lock attributes on the master and you modify<br> the entry it will get replaced on the slaves.<br> <br> Can you post your master and slave configs somewhere ?<br> <div class=3D"im"><br></div></blockquote><div><br><br></div><div>I sent it = by mail but I think it is too big and queued. So here is all configuration = and test result:<br><br><a href=3D"http://pastebin.com/earKiHnH%22%3Ehttp://pas= tebin.com/earKiHnH</a><br> <br></div><div>Cl=E9ment.<br></div></div></div></div>
--089e0160b79ae9bb0c04edcfeff1--