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

[coudot@linagora.com]

On 16/12/2013 22:10, Christian Kratzer wrote:
> Hi,
>
> On Mon, 16 Dec 2013, coudot@linagora.com wrote:
>> Full_Name: Cl?ment OUDOT
>> Version: 2.4.38
>> OS: GNU/Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (88.173.78.196)
>>
>>
>> I have a simple setup with a master (overlay syncprov + overlay
>> ppolicy) and a
>> slave (syncrepl client, overlay ppolicy).
>>
>> 1. I lock my account in the slave
>> 2. I change the description attribute of my account a first time in
>> the master
>> 3. My account is still locked in the slave
>> 4. I change the description attribute of my account a second time in
>> the master
>> 5. My account is no more locked in the slave: the password policy
>> operational
>> attributes pwdFailureTime and pwdAccountUnlockTime were erased by the
>> one of the
>> master
>>
>> Seems like a control is done the first time that syncrepl update the
>> entry (the
>> first time, pwdAccountLockTime and pwdFailureTime are not erased),
>> but the
>> second time the control is not done.
>
> I have had a very similar setup for some time now and have never
> observed this kind of behaviour from the ppolicy overlay. I am quite
> confident it should work correctly in the situation you describe.
>
> There might be a valid reason for pwdAccountLockedtime and
> pwdFailureTime attributes disappearing like perhaps expiry of
> pwdLockoutDuration. Please see the account_locked() function in
> servers/slapd/overlay/ppolicy.c for this.
>

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.


This behavior was detected by one of my customer, and I was able to
reproduce it on my own computer.




Clément.