Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication

[quanah@symas.com]

--On Friday, October 12, 2018 4:14 PM +0000 quanah@symas.com wrote:

> --On Thursday, October 11, 2018 9:25 PM +0000 quanah@openldap.org wrote:
>
>> When the second action is performed (c), all consumers will go into
>> REFRESH mode:
>
> There appears to be a serious bug in ppolicy.  If I look at the accesslog
> data that was written out, the "pwdFailureTime" attribute is cleared on
> two  different entries instead of just the user entry that had its
> password  reset. I.e., pwdFailureTime is cleared on the user AND the DN
> of the  manager entry that made the change.

Ok, this was a red herring.  The idmgmt user had a pwdFailure attribute 
set.  I removed that, and still the underlying err=16 problem occurs, but 
the idmgmt user reset does not (which is correct now).

The user entry on the other masters has the following set after the 
password failure:

pwdFailureTime: 20181012161037.177876Z

The MOD op recorded for it on the master accepting changes has:

reqMod: userPassword:= {SSHA}He+QPQcFD+1/j9uGZl617/eP50B3/QKj
reqMod: pwdChangedTime:= 20181012161047Z
reqMod: pwdFailureTime:-
reqMod: entryCSN:= 20181012161047.202928Z#000000#001#000000
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com
reqMod: modifyTimestamp:= 20181012161047Z

So this should succeed, and yet it fails.  Need to figure out why.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>