Remote Session Access Profiles

Access Profiles are required to enable users to initiate remote sessions. These profiles define and control which users are permitted to start remote sessions, to which endpoints, and with which features.

Before a user can access a remote session, they must be assigned an Access Profile associated with the asset managing the endpoint. This guide walks through the process of assigning an Access Profile to an asset, either by inheritance or through direct assignment.

Note

Users with the Administrator role automatically receive access to all assets in the Asset Database that support remote sessions. This built-in profile includes all session features, has session recording enabled, and requires MFA before session initiation. To restrict this elevated access, assign a more limited Access Profile to the Administrator, which will override the default profile.

Assigning Access Profiles

Consider a container named Windows Servers, located in the Root Container (Root Container / Windows Servers), which holds several Windows-based servers. You want to allow all members of the Windows DevOps group to access these servers.

1. Login with an Administrator user.
2. Navigate to this Windows Server container and open the menu: Manage > Access Profiles.
3. Click Add.
4. In the Add Access Profile form, complete the following:
   • Asset: Confirm the correct asset is selected (in this example, the container Windows Servers).
   • User or Group: Select the Windows DevOps group from the appropriate directory.
   • Name: Choose the appropriate Access Profile. If no suitable profile exists, you may use a default or create a new one, as described in the Access Profile article.
5. Click Save to complete the assignment.

Once saved, the Access Profile appears in the asset’s Access Profiles list with a status of Enabled. You can use the Actions menu to Edit, Disable, or Delete any Access Profile directly assigned to this asset.

To verify the Access Profile has been applied correctly, log in as a user assigned to it, navigate to the Windows Servers container, select a child asset, and confirm the Access button is visible. Clicking Access will open the Session Launcher, where the user can review settings, enter an MFA token if required, and initiate the session.

Access Profile Inheritance

Access Profiles are inherited from parent containers to their child assets (either assets or sub-containers). This simplifies profile management, but exceptions may be necessary in some cases.

Continuing with the previous example, when viewing a child asset within the Windows Servers container, the assigned Access Profile appears in italicized font, indicating it is inherited from a parent container. Inherited profiles cannot be edited or deleted at the child level; the only available action is to Disable them. When an inherited profile is disabled, it appears with strike-through formatting, indicating it is no longer active on that specific child asset. Disabling an inherited profile prevents the assigned users or groups from accessing that asset, but it does not affect access on the parent container or other child assets where the profile remains enabled.

To assign access to a different user or group specifically for a child asset, use the Add button on that asset’s Access Profiles page. This creates a direct, unique profile assignment that applies only to the selected asset (shown in regular font). If the child asset is itself a sub-container, this new assignment is then inherited by all of its children.

To Edit or Delete an inherited Access Profile, you must modify it from the parent container where it was originally assigned. This may require navigating several levels up the container hierarchy.