Skip to main content

Hello Team, 

 

We have observed a issue with PasswordSafe, where Managed Account Next change date is calculated based on Last scheduled change date. If the user changes the password manually, Next change date is not updated to new date based on Password change Frequency (Xdays). 
The problem observed today, is that teams who have manually changed the password for a Service account ahead of a policy based 90-day rotation, as part of a RFC change window, will suddenly have the service account password rotated automatically again (potentially just a few days later) on the 90-day rotation enforcement date by PasswordSafe - thus breaking their production service. 

How can we achieve this use case in such a way that Next change date is updated based on last change date (scheduled & manual)?

Hey ​@SammedPatil - I would recommend opening a case for this behaviour. That said, the passwords shouldn’t rotate during a session. 


I’m going to throw out my observations on this behavior

We use a 1-year policy on non-person (service) accounts. 

When we manually change the password, we see the same behavior you mention. Later in the day however, it shows the proper change date for the next change.

A BeyondTrust engineer explained it to me once, the account password is changed and BeyondTrust then shows the wrong change time/date for a few hours (or more) but it catches up eventually. Something to do with jobs running behind the scenes.

I would suggest you play with it. See if the password changes the next day or whatever it claims or if the change date eventually shows the correct date based on the password policy.

 

One other thought here, check your smart rules. You should never have more than 1 smart rule managing the password rotation. We have the default 1-year rotation but we also have accounts that can be rotated every month, every 3 months, etc. To filter it all out, we use security groups in Active Directory to filter out the accounts and apply the proper timing to them.


Multiple “Ideas” have been submitted for this ‘feature.’ I believe all have been moved to ‘future considerations.’

Below is mine and links to a few others...

 

Provide ability to allow the ‘next change date’ to be updated based on the ‘last change date’ and ‘frequency’ - Reset next scheduled change when password rotation is forced ahead of schedule – Currently an account configured with a recurring reset policy every X days, and has a future scheduled change that has a password change prior to the scheduled change would still change again on the scheduled change date rather than having the next change date recalculated based on the change frequency.
Additional Ideas with similar concepts:

Password Last Change Should Be Source of | All Product Ideas - Public

Option to update NextChangeDate whenever | All Product Ideas - Public

Mirror ManagedAccount properties returned | All Product Ideas - Public


Reply