As standard good practice, all our target accounts are configured to be updated by a service account, including our Oracle DB accounts. There is no problem with the password update process, and we have jobs running to update the password daily to satisfy business requirements. But we keep getting reports that accounts get locked. This raises red flags, because it may indicate that someone tried an unauthorized access into the Oracle database.
We understand that this is caused by the PAM update process, where the managed account first tries to logon with the new password, causing the failed login count to increase by one, and only after that the service account logs on and sets the new password.
We see that this logic flaw recently was fixed for the UNIX target connector as a new feature in 4.0.2. We need this to be fixed for the Oracle target connector as well.
Privileged Access Manager, all versions up to 4.1.4
The logic had been coded with the use case in mind that an administrator would set target account passwords in PAM to the new correct password in the credential source. In that case it makes sense to first check, if the newly entered password is the current password. But it is not right for scheduled jobs, where PAM itself creates and sets a new password.
The logic was changed for the 4.1.5 release, please upgrade.