We see target accounts go out of sync apparently randomly after the expired password processor, or a scheduled password update job, rotates the password or SSH key. From what we can see, the password or key in fact is changed on the target device/credential source, but when we look at the current target account password/key, we find that it's the same as the last history entry in the password history. It looks like PAM successfully updates the account and creates a credential history entry at the time the account is updated on the target server, but then somehow retains the old password/key. The target account has status Unverified. We don't find the new password/key anywhere, and the only way to recover is to reset the password/key on the target server.
There was a problem in PAM code. If an account was updated while a password verification job was in progress, specifically after the verify job started, but before it processed the password/key verification of this particular account, then the subsequent Verify task would use the old password, fail, and save the account with Unverified status and old password/key.
Release : 3.4 and 4.0
Component : PRIVILEGED ACCESS MANAGEMENT
A bug was identified in PAM and will be fixed in upcoming maintenance releases 3.4.6 and 4.0.2, as well as in the next main release 4.1.
For affected releases, try to avoid any overlap with scheduled jobs that verify accounts and scheduled jobs that update accounts. If you use the PAM expired password processor to automatically update accounts when they expire per Password Composition Policy setting, you can't control the time these accounts will be updated. In that case try to avoid running Verify jobs for a large number of accounts that take a long time to complete. The same argument applies to the use of password view policies that change target account passwords on/after view. These also will generate account update jobs whose timing you cannot control.