Skip to main content

We have created the Local account on Custom Platform /Linux system mapped it user one-to-one since We cannot mapped it dedicated since user's Admin account and Requestor id is not matching . Below is scenario, 
1. User Admin id is PA09192
2. user's Requestor Id :MSP9192

 

Since users Requestor id and Admin Id are not matching , we have mapped this using one to one so that user can login to BT and should see this id ->PA09192
This mapping is working fine and user is able to see this Id. However problem here is When any user , having Admin access, logs in to BT, they are also able to see  this id -PA09192.

 

Below KB article explains the reason but we dont want Admin to view and access this id 

https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sys_kb_id=4b4c8e7f473f5a541bf1db37536d434a

 

Can anyone please let me know how can we block Admin users from viewing non dedicated mapped/Shared id from viewing and accessing from Password Safe.

 

Regards,

Imran Aiyani

good morning, I have a few questions about this. 

  1. is the account logging into PWS an AD account?
  2. is there a smart rule/group for this account?
  3. how have you dedicated the accounts to each other. 

here are some thoughts 

To block admin users from viewing or accessing non-dedicated mapped/shared IDs in BeyondTrust Password Safe, you can use a combination of role-based access controls, Smart Rules, and Access Policies. Here's how to approach it:

Steps to Restrict Access to Shared or Non-Dedicated Accounts

1. Use Role-Based Access Groups

  • Create specific roles for different user types (e.g., Admins, DBAs, Helpdesk).
  • Assign minimal permissions to roles that should not access shared accounts.
  • Ensure that only designated roles have access to Password Safe Account Management and Session Access features. [docs.beyondtrust.com]

2. Configure Smart Rules for Account Segmentation

  • Use Smart Rules to categorize accounts:
    • Dedicated Accounts: Use naming conventions or metadata to tag these.
    • Shared Accounts: Tag separately using account attributes.
  • Assign Smart Rules to Smart Groups, which can then be linked to specific user groups. [docs.beyondtrust.com]

3. Apply Access Policies

  • Create Access Policies that define who can:
    • View account details.
    • Request password checkout.
    • Initiate sessions.
  • Apply these policies to Smart Groups containing shared accounts, and exclude admin roles from these policies. [docs.beyondtrust.com]

4. Use Managed Account Aliasing (Optional)

  • If needed, use Managed Account Aliasing to abstract shared account access, allowing only specific users to access them without revealing actual credentials. [beyondtrust.com]

Best Practices

  • Audit regularly to ensure access controls are enforced.
  • Avoid assigning Full Control to general admin roles unless absolutely necessary.
  • Document account ownership and access justification for shared accounts.

I believe we can work with some smart rule filter and/or access policies to help with this.


Hi frank,

 thank you so much for reply. below are my comments 

1. for shared accounts we dont have any matching attributes to map hence we are using one to one mapping. i.e. creating smart rule with only show as smart group setting and then assigning it to group which has user who needs to access it. 

2.yes users login to password safe are using AD account using saml sso. form login is disabled for all

3.Apply these policies to Smart Groups containing shared accounts, and exclude admin roles from these policies.  can you please elaborate how can i exclude adminstrator group so that they dont see non dedicated account or shared id?

awaiting your response. thanks in advance

 

Regards 

Imran