How to enable "Automatic Password Change" for local Linux servers?

Hi,

I recently came across a similar use case involving the management of over 50 non-domain joined Windows systems. In that scenario, the following approach was implemented:

• A local functional account was created on each system, all using the same username and password.
• A single local functional account was then added to Password Safe, with Automatic Password Management enabled.
• This Functional Account was applied to each onboarded system. While the username remained consistent across systems, Password Safe managed unique passwords for each system.

This method proved to be significantly more efficient than creating and managing individual functional accounts within Password Safe for each system.

Hi Paul,

Thanks for taking the time to answer my query — that approach could definitely help resolve several challenges we're facing.

As a follow-up: is there a way to verify that the credentials are being rotated individually for each server, even though we’re assigning the same local Functional Account across all systems at the start?

Just want to make sure that Password Safe is managing unique passwords per server as expected.

Appreciate your guidance!

Password will be uniquely generated based on the Password Policy even though you are using the same local FA.

Apart from View Password, I don't think there is an option to check the uniqueness of the each password.

FYI, only sync accounts will have the same password, rest of the managed accounts will always have a unique password.

Hi,

To echo Prudhvi’s point, the password is uniquely generated in accordance with the Password Policy assigned to the Managed System. Currently, there is no method to verify these credentials through the user interface. However, I am unsure whether this capability is available via the API.

For Managed Accounts, password verification can be scheduled using the Test Agent. Please note that this functionality is not supported for Functional Accounts.

Sync Accounts are particularly beneficial when working with local scan credentials. For instance, you can create a single Managed Scan Credential using subscriber local accounts that share the same password. This allows one Scan Credential to be used across multiple local systems within the same scan job. That said, Sync Accounts are not recommended for use with Functional Account

Hi Paul & Prudhvi,

Thanks for the detailed explanation. I understand that the Managed Account password will be generated according to the Managed System.

My question/concern is mainly regarding the Functional Account (FA). As we onboard a local FA, will its password be changed if I enable it to be managed by BT?

Yes, password will be changed when you enable the auto management on Password Safe either in Managed Accounts or in Functional Accounts.

Hi ​@prakash.r Thank you for asking this question . Sorry but I thinks its best place to ask a follow-up. 
​@Prudhvi Keertipati ​@Paul Dann 
In this scenario , does the FA account’s original password remain as-is in Passwordsafe ? I think yes. as it is being used to onboard newly imaged systems.

Also, once the system is onboarded and if we have set “automatic password management” on the functional account , only then it will be changed (be unique) on each system ?

From  availability perspective, can it be beneficial to keep the FA password fixed (non auto-managed).e.g in case there is some issue with managed account password , at least the fixed-password FA can be used to manage it ? 

If there is no existing break glass mechanism into Linux servers then it is better option not to auto-rotate FA password. Unmanaged FA will be useful when Managed Accounts are out of sync and have to manually login to system to troubleshoot.

​@bt101 Yes, when FA auto-management is enabled, Password will be rotated and unique to each system. At global level, FA password will remain same. 

Yes, that is correct. When “auto-management” is enabled for the Functional Account, the password will rotate (per assigned schedule for the Functional Account) using the designated password policy and will be unique to each system. 

Experience observation, if you deploy large quantity of local accounts on over 1,000 assets, the discovery scanner processing time and/or Smart Rule processing time may be an issue.

Instead of discovering the accounts, use the Managed System Smart Rule that “creates” the local account vs. depending on the discovery process (hint: it does NOT create the account). 

In the link below, see the section titled: Add Known Local Admin Managed Accounts Using a Smart Rule

Link: https://docs.beyondtrust.com/bips/docs/pathfinder-assets#add-known-local-admin-managed-accounts-using-a-smart-rule 

This is really useful ​@CharlesN :)