--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