Set Jump Client
Pinning and Unpinning Permissions
Allow Users to Pin Jump Clients
Permission to deploy, remove, and modify Jump Items always grants the user permission to download and install Jump Clients prior to support as described in Deploy Jump Clients During a Support Session or Prior to Support. However, this does not necessarily mean that the user has permission to pin Jump Clients during a support session. To pin a Jump Client during a support session, the user must have the permission Jump Clients Pinning/Unpinning. This permission can be defined in any of the three following locations in /login:
- Users & Security > Users
- Users & Security > Group Policies
- Users & Security > Embassy
- Users & Security > Session Policies
If you need to assign the permission to only one or two users, do so from the Users page.
If you need to assign the permission to one or two groups of users, do so from the Group Policies page
If you need to assign the permission to three or more groups of users, to specific Jump Clients, or to one or more of your public portals, do so from the Session Policies page.
Regardless of where you set this permission, the configuration works the same. Locate the Jump Clients Pinning/Unpinning permission and select Allow.
Selecting Deny prevents pinning/unpinning of Jump Clients. Selecting Not Defined falls back to a lower priority session policy or the global session policy.
If you allow this permission for a specific user on the Users page, then that user can pin/unpin any session they start.
If you allow this permission for a specific Group Policy
However, if you allow this permission for a specific Session Policy, no change occurs until you assign this policy to one or more users, group policies,
Assign a Session Policy to a User or Group
To assign a session policy to a user account, group policy,
Making the pin/unpin permission available to rep invite is meaningless. External representatives cannot have ownership of sessions, and only the owner of a session can pin/unpin Jump Clients.
To assign a session policy to a user
Assign a Session Policy to a Public Portal
Public portals allow you to assign additional DNS hostnames to your BeyondTrust Appliance and specify a different look and feel for each one, along with different behavior and permissions. You can define public portals on the /login > Public Portals > Public Sites page.
If you allow pinning/unpinning for a public portal, then all sessions started through that portal allow the representative to pin/unpin, regardless of any permissions assigned to the representative's user account
To assign a session policy to a public portal:
- Go to /login > Public Portals > Customer Client.
- At the top of the page, check the Select a different public site to edit dropdown to make sure you have the desired portal selected.
- Under Customer Client :: Session Policy, use the dropdown to select a policy.
Assign a Session Policy to a Jump Item
To assign a session policy to a Jump Item, set the Availability of the session policy to allow Jump Items. While Jump Items include more than just Jump Clients, the pin/unpin permission applies only to Jump Clients.
When a session policy which allows pinning/unpinning is assigned to a Jump Client, then any user who starts a session with that Jump Client can unpin it, even if that user is denied permission to unpin Jump Clients in all other sessions.
To assign a session policy to a Jump Client, the user must have permission to change the session policies associated with Jump Items.
When a user has this permission, they can right-click any Jump Client they are allowed to modify, click Properties, and assign a session policy to the Jump Client using the Customer Present Session Policy and Customer Not Present Session Policy dropdowns.
The way customer presence is determined is set by Use screen state to detect customer presence on the /login > Jump > Jump Clients page under Jump Client Settings. If checked, the customer is determined to be present only if a user is logged in, the screen is not locked, and a screen saver is not running. If unchecked, the customer is considered present if a user is logged in, regardless of screen state.
Troubleshoot Settings with the Session Policy Simulator
If a specific user is unable to pin/unpin Jump Clients during a session, you can use the session policy simulator to troubleshoot the issue.
- Log into /login as an admin and go to Users & Security > Session Policies.
- Scroll to the Session Policy Simulator section and enter the Representative and Session Start Method in question.
- Click the Simulate button and check the result for the permission Jump Clients Pinning/Unpinning.
If the simulator indicates that the user should be able to pin/unpin for a given session, and yet in practice this is not the case, then verify that the user has permission to modify Jump Clients:
- Log into /login as an admin and go to Users & Security > Users.
- Edit the user in question and locate their Jump Group Memberships.
- If a Jump Group specifies a specific Jump Item Role for the user, click on the role to see its settings. If the role is set on the user, scroll down to the user account's Jump Technology section and click Show for the associated Jump Item Roles.
- At least one of the associated Jump Item Roles should give the user permission to Create and deploy new Jump Items and/or Remove existing Jump Items.
- If a Jump Group Membership is defined by a group policy and/or if the Jump Item Roles are not editable, then modify the group policy which is controlling these memberships and/or permissions.
- There may be multiple policies involved, so you may need to check each one.
- If the same permission is defined in multiple policies, you may need to reorder them or change the option Allow this policy to be overridden? for Add To Jump Groups, Remove From Jump Groups, and/or Representative Permissions.
- If you reorder policies or allow override, remember that a group policy listed further down in the list of policies overrides policies further up in the list only when the permission in question allows override on the first/topmost group policy; otherwise, the first group policy takes precedence.