From clem.oudot@gmail.com Wed Dec 18 14:34:31 2013 From: clem.oudot@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy) Date: Wed, 18 Dec 2013 14:34:31 +0000 Message-ID: <201312181434.rBIEYVVa029965@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7234284967910649656==" --===============7234284967910649656== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --089e0160b79ae9bb0c04edcfeff1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/18 > 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: > > > 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: http://pastebin.com/earKiHnH Cl=E9ment. --089e0160b79ae9bb0c04edcfeff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/12/18 <ck(a)cksoft.de>
=A0 This message is in MIME format. =A0The first part should be readable te= xt,
=A0 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 corr= ectly set (The value
> 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 co= rner
>> case that nobody else has yet found.
>
>
> I think so. I have to say that I use standard syncrepl, not delta-sync= repl.
>
>
>>
>> The best thing you could do would be to setup a small self contain= ed
>> test case to illustrate the problem.
>>
>
> I will try to, but seems really easy to reproduce : configure master a= nd
> 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:

http://pas= tebin.com/earKiHnH

Cl=E9ment.
--089e0160b79ae9bb0c04edcfeff1-- --===============7234284967910649656==--