Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)

[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 tools.

--4178219828-444410844-1387368134=:27797
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

Hi,

On Wed, 18 Dec 2013, Clément OUDOT wrote:
<snipp/>
> Well, I checked that the pwdLockoutDuration was correctly 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 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 and
> 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 ?

Greetings
Christian

-- 
Christian Kratzer                      CK Software GmbH
Email:   ck@cksoft.de                  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0          D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9          HRB 245288, Amtsgericht Stuttgart
Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian Kratzer
--4178219828-444410844-1387368134=:27797--