How Do Session Policies Work?

From the /login administrative interface, create session policies to apply to objects within BeyondTrust. Once applied, these policies are layered each time a session starts, and the results of the layered policies determine the permissions for each session.

For more information on how to create session policies, please see Create and Edit Session Policies.

Order for Applying Session Policies

Session policies are applied in a specific order. This order is hard-coded by BeyondTrust and cannot be changed, and higher priority policies cannot be overridden.

The order in which policies are applied is:

  1. Jump Item
  2. Public Portal
  3. Representative
  4. Global Default

The first applied session policy that defines a setting is used for that setting. If a lower policy also defines that setting, the second policy's setting is ignored.

Any permissions that are left undefined by the first applied policy may be defined by the next policy in the list. If the first applied policy defines all permissions, then none of the lower policies defines any permissions. If no policies are defined for the session, then the global default policy defines all permissions. Because the global default sets all undefined permissions, all permissions within the global default policy must be defined.

Jump Items

A session policy can be applied to a Jump Client, Local Jump Shortcut, Remote Jump Shortcut, or Shell Jump Shortcut. When a session is started through this Jump Item, the applied session policy sets the permissions that are available within this session. Any permissions that are not defined by the Jump Item session policy can be defined by a lower policy (i.e., public portal policy, representative policy, or global default policy).

Jump Client Mass Deployment Wizard

Jump Clients deployed from the mass deployment wizard of the /login interface can be assigned a session policy during creation. You can apply one policy for when the customer is determined to be present and another for when the customer is not present.

 

Jump Client Properties

To assign a session policy to a Jump Client deployed within a support session, first customize the Jump Client. Near the bottom of the properties dialog, select a session policy. You can apply one policy for when the customer is determined to be present and another for when the customer is not present.

 

Jump Shortcuts Mass Deployment Wizard

Local Jump Shortcuts, Remote Jump Shortcuts, and Shell Jump Shortcuts imported via the mass deployment wizard of the /login interface can be assigned a session policy during creation. For Local or Remote Jump Shortcuts, you can apply one policy for when the customer is determined to be present and another for when the customer is not present.

 

Remote Jump Shortcut Properties

To assign a session policy to a Jump Shortcut deployed from the representative console, scroll to the bottom of the properties dialog. For Remote and Local Jump Shortcuts, you can apply one policy for when the customer is determined to be present and another for when the customer is not present. Shell Jump Shortcuts have only one session policy field.

 

You can change the session policy for a deployed Jump Item from the Jump interface of the representative console. View the Jump Item properties and select the session policy.

Public Portals

Customer Client - Session Policy

A session policy can also be applied to sessions that come through a specific public portal. This most notably affects customer-initiated sessions. If you have multiple public portals, then the session permissions may differ depending on which public portal your customer used to start a session with you.

Because Jump Items and Support Buttons are associated with public portals, this also affects sessions started through either of these methods.

A session policy is assigned to a public portal from the /login > Public Portals > Customer Client page.

Jump Clients

Jump Client Properties

When a Jump Client is deployed within a support session, the Jump Client is by default associated with the same public portal as the support session. To change this, first customize the Jump Client and select a public portal from the properties dialog. All future sessions started from this Jump Client are associated with the selected public portal. Jump Clients deployed from the mass deployment wizard of the /login interface are also associated with a public portal, selected before deployment. You can change the public portal for a deployed Jump Client from the Jump interface of the representative console. View the Jump Client properties and select the public portal.

According to the order of application, the Jump Client's session policy is applied before the public portal's session policy.

 

Support Buttons

BeyondTrust Buttons - Edit

Support Buttons can also be associated with a public portal. When deployed within a support session, the Support Button is by default associated with the same public portal as the support session. Support Buttons deployed from the mass deployment wizard of the /login interface are also associated with a public portal, selected before deployment. You can change the public portal for a deployed Support Button from the Support Button management interface of the representative console. Edit a Support Button and select the public portal.

Session policies cannot be directly associated with specific Support Buttons. However, based on the order of application, the session policy for the Support Button's public portal is applied before any other session policies.

 

Jump Shortcut

Local Jump Shortcut Properties

When creating a Jump Shortcut, either from within the representative console or from /login, you can select a public portal to be associated with the shortcut. You can change the public portal for Jump Shortcut from the Jump interface of the representative console. View the Jump Shortcut properties and select the public portal.

According to the order of application, a session policy applied to a Local Jump, Remote Jump, or Shell Jump takes precedence over the public portal's session policy.

 

Ad hoc Jump To sessions (started via Jumpoint or local push) are also affected, although all Jump To sessions are associated with the default public portal and cannot be changed. However, if you have assigned a session policy to your default public portal, that session policy is by association applied to Jump To sessions. This encompasses Local and Remote Jumps, Local and Remote RDP sessions, Local and Remote VNC sessions, Shell Jump sessions, and Intel® vPro sessions.

Representatives

User Accounts - Attended Session Permissions

A session policy can be applied to a representative by means of their user account, group policy, or rep invite profile. For all user objects other than rep invites, you can define separate policies for attended and unattended sessions run by this representative. Attended session policies apply to customer-initiated sessions and sessions started via Support Button. Unattended session policies apply to sessions started through a Jump Client, Jumpoint, or local Jump. The rep invite profile is selected when the session owner creates the session invitation.

 

Global Default

Session Policies

The global default session policy must be defined. All permissions undefined by more highly ranked policies (i.e., Jump Item policies, public portal policies, representative policies) are set by the global default. Therefore, this policy cannot be deleted, and all permissions within this policy must be defined. Even if all of the policies applied to a session leave one or more permissions undefined, the global default policy ensures that those permissions are still defined for the session.

This policy comes pre-defined with all permissions set to the lowest possible permission level. Modify these settings as appropriate for your organization.

Apply Session Policies

When configuring a representative (user account or group policy), the administrator has three options for applying a session policy. When configuring a public portal or Jump Item, only the first two options are available. When assigning a rep invite profile, only the first option is available.

  1. Use a previously-defined session policy:
    • From /login > Users & Security > Session Policies, session policies can be created independently and can then be applied to objects within BeyondTrust. You may not set individual permission options for the object to which a session policy is applied.
    • When applying a session policy to a representative within the /login interface (user account or group policy):
      • Selecting a session policy displays its description and a read-only view of its permissions.
      • If you wish to modify the selected policy, click Edit. This takes you to the Edit Session Policy page, where you can edit the permissions set. Be aware that changing this policy changes the permissions for all objects that use this policy.
    • If a permission is undefined within the session policy, then the lower policies set that permission. If no other assigned policies set that option for the session, then the global default policy's rule is applied.
  2. Do not associate a session policy:
    • Because no session policy is set for this object, the lower policies must define the permissions for the session.
    • If other session policies are defined but leave some permissions undefined, then the global default policy's rule is applied to those permissions.
    • If no other session policies are defined, the system falls back to the global default policy.
  3. Define custom session permissions that are valid only for the object currently being configured:
    • No externally defined session policy applies. You set each permission individually.
    • If a permission is undefined, then the lower policies set that permission. If no other assigned policies set that option for the session, then the global default policy's rule is applied.
    • If no session policies are available to be assigned to user objects, then each permission must be defined.

Furthermore, when configuring a representative, you can choose to define one policy for attended sessions and another for unattended sessions. You can also choose to apply the same permissions to both. Additionally, if configuring custom settings for both attended and unattended policies, you can copy the settings from one to the other.

Attended session policies apply to customer-initiated sessions and sessions started via Support Button. Unattended session policies apply to sessions started through a Jump Client, Jumpoint, or local Jump.