@edwinb77
We recommend every group of users be in a single policy based on permissions. IE - Support team, group policy, and jump groups they need to be associated with the same name for ease of use.
If you are using a default policy in the SAML provider, we recommend that it be set to none if possible, otherwise, put the policy at the top with allow override in EVERY SECTION. It would be recommended to make it a policy with the bare bones structure to log in and do the basic needful until you add them to a group with the desired permissions. Example here:
1. Create a group policy -> /login -> users and security -> group policy -> create a new group policy.
2. Under Account settings - this controls account expiration, 2fa, and the reps ability to edit it's own name, photo, and ability to show on the public site.
3. Under General permissions - This controls various hostname/login controls and functions. This is also where reporting is located and can grant the user access to their own reports to view, teams reports or All reports.
4. For basic remote support - Scroll to representative permissions -> make sure the following is selected:
a. Allowed to provide remote support
b. Under jump technology -> jump clients are selected and any other permissions or session functions such as RDP, Local jump, ect.
c. Under jump items roles -> set default role, leave Teams, Personal and System as NO ACCESS. If you do NOT set system to NO Access, they will have access to ALL jump clients.
d. Under attended permissions -> set prompting behaviors and allow screensharing – set any other permissions you want - Attended sessions is session key, public portal issue submission, clicking a reps name or Support Button. These are all Customer initiated sessions.
e. Under unattended permissions -> set prompting behaviors and allow screensharing – set any other permissions you want - Unattended sessions are jump client, jump to, remote jump - all rep initiated sessions.
Our product uses a top-down hierarchy system so if users are in more than one policy, they will inherit the policy at the bottom of the list if it is allowed to override. You will probably want every permission to override.
When setting the order of policies, I would put the policy with the MOST needed permissions at the top (admin) and the permission you do NOT want to override... then the next restrictive policy followed by the next ect.. until the MOST locked down permissions are at the bottom. There is ONE specific section you never have to put under no override UNLESS you want to lock the group into a specific jump group.. and that is memberships. If all other permissions are locked in a users policy, but you want them to have access to another jump group, adding a user to that policy will not impact their permissions as long as the users original policy is set to no override in all sections other than membership.
The type of account doesn't matter, just the policies they are in and the order of the policies."
