--On Friday, October 12, 2018 4:14 PM +0000 [email protected] wrote:
> --On Thursday, October 11, 2018 9:25 PM +0000 [email protected] 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>
