[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
- From: quanah@symas.com
- Date: Fri, 12 Oct 2018 16:27:47 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
--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>