Thanks for asking ​@ravi.bisram! You have brought up two topics: 1) secrets safe implementation with least privilege in mind and 2) local vs domain managed groups.

As a TAM, I’m often giving advice to a customer on our best practices and applicability based on their environment. As such I’ll list the following as ‘suggested practices’ as there are always caveats that can change the recommendations.

====

Quick Reference: the documentation Secrets Safe will go over this at a more granular implementation detail, but not the permission set suggested as there is no single best-practice.

===

Secrets Safe: Least Privilege Suggestions

There are two areas for granting permissions for Secrets Safe. First is PasswordSafe User Management, and the second is the Secrets Safe unique safe itself.

PasswordSafe Configuration: User Management

The first place for granting permissions is User Management and assigning the Secrets Safe feature to the User Group.

Read Only - they can use Secrets Safe but not Manage Secrets Safe

• This would be the end-users of Secrets Safe and where non-administrators of the PasswordSafe platform should be permissioned
• This should only be provisioned to users authorized for Secrets Safe access

Full Control - this will grant them administrative permissions for managing Secrets Safe itself

• This should be restricted to those who must manage Secrets Safe such as creating new safes. In a least privilege model, this is a dedicated administrative account rather than the regular user account
• This is organization dependent of how they want to manage Secrets Safe overall

Configuration: Groups

Note: Administrators group should be users that are dedicated administrative accounts tied to regular user accounts and not the regular user accounts for the least-privilege model

Secrets Safe: Safe Permissions

Users who have Secrets Safe Full Control can create new safes (previously: team folders) and assign permissions to a User or a Group who can also be granted Manage Safe permissions. For up to date Secrets Safe, the removal of the owner from PasswordSafe does not delete the safe contents. 

Suggested Safe Creation:

• Secrets Safe administrator creates the safe and assigns ownership of the safe to the requesting team, or authorized requestor (please have a process here!) to then manage access to the safe.
• The Manage Safe permissioned user will potentially add other trusted Managed Safe users to reduce a single point of failure for managing the safe in day-to-day operations. Otherwise, the Secrets Safe Admin would need to be contacted to assist with appropriate authorization. 

Suggested Safe Management:

• The Safe Manager (person with Manage Safe permissions) adds a team to the safe with the appropriate lowest-level access as required that should be lower than Manage Safe. 
• While users could be assigned, the suggestion is to do this based on groups for role-based style access.
  • For user-based permissions granted, ensure routine auditing of permissions is completed as this is likely overlooked from overall group-based auditing. 

Secrets Safe: Local vs Domain Groups

Whether local groups or domain groups are a more secure solution depends also on the organization’s overall IAM strategy. The following notes are assuming no automated Identity and Access Governance (IAG) solution (e.g. SailPoint, Entitle - BT product, etc.)

Local Groups does provide the PasswordSafe administrators the granular control over user access provisioning. The cost of this granularity is the manual overhead around the user lifecycle of mover/leaver/joiner, and properly managing the account permissions based on these criteria. In my experience, this is often a source of challenges around any local accounts regardless of platform. Auditing is required.

The domain groups does require the implicit expectation that the management of the domain is well controlled and the implications of adding users to groups is understood the full impact. The mover/leaver/joiner process is more handled through setting up well organized role-based user groups in PasswordSafe. In terms of people being added to groups to gain further access - assuming it’s human error, this needs to be reviewed as a part of the general domain auditing process. If you’re assuming you’re mitigating against a bad actor, PasswordSafe is only a fraction of the concerns that should exist. Note, if they have access to the domain, they could get the credentials of a user already in PasswordSafe with high privileges. Auditing is required to ensure these still match. 

Tips: 

• Entitlement by User, Entitlement by Group reports are not stored in an easily accessible location with restriction locked if they are exported outside of PasswordSafe. 
• These reports are reviewed regularly.
• Review the Inactive Managed Accounts to reduce the access people have to systems if some managed accounts are no longer required. This is an overall reduction of attack surface.

While not a sales post - this entire user permission issue around the roles they should have is precisely why we have Identity Security Insights. This part of your question is a tricky issue for all platforms that allow local accounts and domain accounts. The Insights product provides a method to holistically review the user permissions across various data sources to highlight potential issues, and detect suspect behaviour.