linux dedicated local account?

Hello ​@tonghualeo 

We have a few KB's that should answer your questions. 

For mapping local Linux dedicated accounts have a look at "How to map multiple dedicated accounts to a single user account"
https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0017036

And "How to onboard Linux or Unix servers and local Linux or Unix accounts"
https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0018722

To stop SUDO from requiring a password for a specific command you can add an entry in the sudoers file. 
Our Docs have an example of this the section on creating a functional accounts on the Unix or Linux platform showing how to create a functional account to not be prompted for certain commands.
https://docs.beyondtrust.com/bips/docs/ps-dss-authentication#ubunturedhat

If using Powerbroker for Linux then I would recommend using pbrun instead of sudo and creating rules to define what users can run what commands on what systems.

How to integrate EPM-UL and use PBRUN for elevation
https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0017238

If you have any questions please let me know.

Regards,

John

Hey ​@tonghualeo, 

Thank you for asking! The recommended approach for onboarding a local account is in three steps: discovery, onboarding, and mapping. For the sudoers item, that’s a bit more thorny and I’ll address at the end. 

Dedicated Account Mapping - Any Local Account

The dedicated account mapping here is for any local account on any system. A quick note is that there is a general guide for mapping multiple dedicated accounts to a user: https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0017036,

These are presented in three steps to show the unique phases, and to ensure the flow works before combining them into smaller smart rules. 

Discovery

For the Linux systems, or any target system where you’d like to have this flow, they will need a discovery scan performed. Since you’re asking about Linux, you likely don’t need to worry about compatibility with built-in tools unless the OS has been customized. In that case, you’ll need to set up a custom platform. 

1. Treat this like onboarding any Linux local account: Password Safe - Getting Started (linked to Linux Root Accounts use case)
2. For any other platform, it’s the same discovery scanning process. 

If you’re looking to expand beyond Linux, the general platforms with discovery and auto-management from built-it capabilities are listed in supported platforms. Password Safe supported platforms. Our Technology Alliance Partnership team (TAP) has many additional examples in BeeKeepers for managing other platforms in PasswordSafe. 

Onboarding

Instead of root accounts in Password Safe - Getting Started (still linked to Linux Root Accounts use case), you’ll look to onboard the credentials that are used as dedicated accounts. 

Mapping

This is separate from the others to ensure the mapping process works as expected. You’ll need to have a dedicated account mapped via suffix or prefix to the user ID in PasswordSafe. 

Check that this is a mapped account in the Managed Accounts setting (it’ll show a checkbox).

Once the three are working as expected, you can shorten this into 2 smart rules (1 - discovery, 2 - managed account onboarding and mapping)

Sudo Thorns

Having sudo and no password is challenging to advise. If the account is compromised, this provides easy access to become the root user and pursue chaos.

Sudo and checkout passwords

If the password is compromised on one machine, sudo with password requirements means that it’s at least restricted to that one machine. While nothing is perfect, this becomes a ‘choose the hard.’ Rotating passwords on session end will limit the window of potential abuse.

Sudo without password - specific commands

If there are a set of expected commands, then this could be set up for the userid. However, that ‘expected commands’ set shouldn’t include “su -” and effectively be password less.

Application Specific

While this isn’t likely the use case for the dedicated accounts, if there’s a specific application that users are running, then a Linux application could be set up to auto-inject the credentials to launch the application and the users would have access to it. 

Other Tools

This challenge with account access (PasswordSafe ) and permissions (ability to sudo) isn’t well suited for a one-size-fits-all tool, and is an area where multiple layers need to be covered. 

Endpoint Privilege Management for Linux (EPM-L) would remove the sudo challenges and could have some commands be a run-all option, however your policy could still require a password if so configured. 

Privilege Remote Access (PRA) provides more granular access with PasswordSafe as the engine for discovering and rotating credentials, and the ability to inject credentials. I think of PRA and RS as the front-end for consumers of PasswordSafe and PasswordSafe as the powerhouse that has many integrations available for managing credentials.