Seeking Solution: SPP Entitlements and User-to-Server Access Mapping Issue

I've encountered a challenge with entitlements in SPP concerning user-to-server access mapping. With our configuration, individual domain accounts are set up to grant access to particular Windows Servers. However, when a user initiates a new request within SPP, they are presented with an array of accounts linked to each server under the "New Request" window. For clarity, while a user should only see Server01 linked to Account01, they're seeing options like Account01, Account02, etc., for the same server. A screenshot is attached for reference.

While browsing this forum, I came across a potential solution that suggests setting up distinct Access Request Policies for every server and pairing them with the appropriate account. However, this approach seems impractical given our scale of over 600 servers and 100+ accounts.

Is there an alternative method to ensure users view only the specific account designated for each server without seeing multiple options?

Thank you,

Muhammad Faraz Khan

  • Hi,

    Are you saying that for each target server, there is a single unique AD account that is used to access a single server?

    If the (account to server) relationship is 1:1 then the entitlement for each (account to server) will also be 1:1

    Another option is If each SPP user has their own privileged account (Not shared between users) then you can use a single entitlement and link the privileged account to their users then use a single linked account entitlement.

    Example:

    User1 - is a regular AD user which is used to login to SPP

    User1-Admin - privileged account that belongs to user1

    You can configure SPP so that it can link User1-Admin to User1 so that each user can request their specific linked privileged account only and access the servers defined as part of the entitlement scope. 

    For more information on linked accounts feature, please refer to the admin guide here:

    https://support.oneidentity.com/technical-documents/one-identity-safeguard-for-privileged-passwords/7.3/administration-guide/99#TOPIC-2015985

    Thanks!

  • Thanks, Tawfiq, for the swift reply.

    To clarify the challenge, we're encountering despite having the Linked Accounts feature set up, let me illustrate with an example:

    Example:

    User1 - standard AD login for SPP.

    User1-Admin1, User1-Admin2, User1-Admin3 - privileged accounts associated with User1.

    User1 has ownership of 3 servers. However, when User1 initiates a new request in SPP, he sees all three Admin Accounts as login options for all servers. To break it down:

    • For Server1, User1 sees options to log in using Admin1, Admin2, or Admin3.
    • For Server2, the same three options appear.
      ... and so forth.

    My goal is to distinctly map Admin1 to Server1, so only Admin1 appears as a login option for Server1. The same specificity is desired for other servers too.

    I trust this makes the situation clearer.

    Best regards,

    Muhammad Faraz Khan

  • Hi Muhammad,

    In the Entitlement > Access Request policy > Security Tab

    There is an option to "Enable scope filtering for linked accounts"
    - When selected, this setting allows you to limit the number of requestable accounts to linked accounts that are also defined in the policy scope tab.

    Example:

    - if the  Access Request policy is for Server1, you can check the box for "Enable scope filtering for linked accounts" and Add the User1-Admin1 to the Scope in addition to the Asset being Server1

    If User2 also has a User2-Admin1 linked to them then you can also add that to the scope.

    The result:

    User1 will see only their linked account User1-Admin1 for Server1

    User2 will see only their linked account User2-Admin1 for Server1

    For Server2 you will need another Access request policy similar to the above except the Scope has Server2 instead of Server1 and all the linked accounts that should be filtered for Server2.

    Users will only see their own linked accounts and not other user's linked accounts as long as the option for scope filtering is enabled and the linked accounts are defined in the scope tab.

    This feature is available in SPP versions 6.14 & 7.0 LTS or above.

    Thanks

  • Hello Tawfiq,

    Thank you for your insights. While we have implemented the approach you mentioned, there seems to be a nuanced challenge we're encountering.

    To illustrate: User1 possesses several admin accounts, namely Admin1, Admin2, and Admin3. Concurrently, User1 administers multiple servers: Server1, Server2, and Server3. For clarity, Below is the visual representation. From the image, it's evident that every server is accessible via every admin account. Ideally, Server1 should be exclusive to Admin1, Server2 to Admin2, and so forth. My goal is to ensure each server is paired with its designated admin account. This discrepancy is more prominent in the SPP Web Portal, though it's straightforward in the Desktop Client.

    I hope this provides a clearer understanding of the situation at hand.

    Warm regards,

    Muhammad Faraz Khan

  • Hi Muhammad,

    Can you share how the Access request policy is currently configured in both the Security tab and the Scope Tab?

    You would need to have a separate RDP Access Request Policy for each Server in order to accomplish a 1:1 account to Server relationship.

    Thanks!

  • Hello Tawfiq,

    Per your request, I've attached the images from the Security and Scope Tab. I attempted the method where I set up multiple ARPs for each server. While it was successful, it's challenging to implement this for over 600 servers and more than 200 accounts.

    Best regards,

    Muhammad Faraz Khan

  • Thanks for the update.

    If the Scope has All Servers and All accounts (since you added the groups) then the result would be expected to show all accounts for all the servers.

    If the requirement is to show 1:1 (single account to single server) then the only way is to configure a separate Access Request policy per server.

    I would suggest you to consult with One Identity Professional Services team by discussing this use-case with your account manager in case you need assistance with using a script to create the configuration so that it is not done manually.

    Thanks!

  • Hi Tawfiq,

    I have similar request - Users have individual AD account managed by SPP and linked account option works fine for domain joined server with single Entitlement and Access Request policy as you mentioned.

    However, for workgroup server - we have same case of users having individual account. Is there an option of linking the workgroup server accounts to individual users? the Linking option could only show the directory account.

    Creating only separate Access Request Policies with scoping individual user account and Server is only option? also, I can see the permission to request access comes from Entitlement. So would it be the case that for each user I have to create separate Entitlement, with Access Request Policies to scope users individual account and server?

    Is there any other way for workgroup server?

  • Hi Deep,

    Linked accounts can only be Directory accounts, there is currently no option to select local accounts as Linked Accounts for a user.

    If the requirement is to show 1:1 (individual local account for each single user) then the only way is to configure a separate Entitlement per user.

    Thanks!

  • Hi Tawfiq,

    Thank you for confirming!

    In my case, I would have more than 10 workgroup servers with about 20 users each, hence it won't be practical to create 20 entitlements and then 10 Access Request Policy for each. Also, managing joiner/mover process will be difficult as I will have to create new entitlements/Access Request Policy for each new joiner. Do you know what's the best way to handle such situation? Shared account isn't an option for me. 

    Are you aware about any such feature planned in roadmap to allow non directory accounts to be linked to user profile? This will help to decide strategy for my PAM deployment.