Understanding Session and Group policy behavior | RS

Introduction

Why Session and Group policy logic exists

When you support users in real-world scenarios, you manage multiple variables such as who connects, which endpoint they access, and how the session starts. With the help of Session policies, you can control which tools are made available (or not available) based on two major factors:

1. What Group Policy (or Policies) a user is a member of
2. Which Session Policy (or Policies) are active based on where they are sourced from

Because Remote Support must accommodate a wide range of use cases and scenarios, it includes logic that evaluates and applies every relevant setting and configuration.

To remove the guesswork from how Remote Support determines and assigns these settings, this document explains how Session Policy Logic and Group Policy Logic work.

We begin with Key terms, and then Session Policies.

Key terms

Session Policies

Session policies set rules that controls which tools and actions are available in a support session (for example, Screen Sharing mode, File Transfer, Command Shell, Registry Editor, and more). Session Policies can come from many different areas in Remote Support such as:

• Jump Item Session Policies
• Support Portal/Public Site Session Policies
• Group Policies
• User Assigned Session Policies

🚧

Important information

Starting in 25.3 and higher, Rep Invite Session Policies take precedent over Jump Item Session Policies

⚠️

Warning

Order of evaluation is fixed and must be followed. The system processes policies in a defined sequence, and you cannot change or bypass this order.

If more than one Session Policy can be active, how can we be certain which session policy tools will take effect over others in any given situation?

For example, a Representative may connect to an endpoint that has a Jump Item Session Policy where several tools are set to Deny, while at the same time that Representative belongs to a Group Policy where those same tools are set to Allow. In cases like this, how does Remote Support determine which session policy takes precedence? Is enforcement all-or-nothing, or is it evaluated on an individual tool basis?

Remote Support uses a defined set of logic rules that evaluate a user against each individual tool. These rules follow a sequence of checkpoints to determine whether access should be Allowed or Denied. The next section explains how the system evaluates these tools, per policy, and determines how they get applied.

Session Policy evaluation overview

Remote Support assesses every tool by checking policy sources in a specific order, stopping as soon as it encounters a policy that provides a defined Allow or Deny value.

The first defined result of Allow or Deny locks that answer and blocks the answers from subsequent session policies from taking effect. The impact of this logic is that the first Session Policy that sets a tool to Allow or Deny always takes precedence.

If a tool is set to Not Defined, the system continues to the next checkpoint to look for an Allow or Deny decision.

Session Policy evaluation order summary

1. Jump Item Session Policy
2. Public Portal/Site Session Policy
3. Group Policy
4. User Assigned Policy
5. Global Default Policy

1. Jump Item Session Policy

The system first checks the Jump Item Session Policy for an Allow or Deny decision.

Apply a session policy at the endpoint object to enforce rules on which tool can be used or not whenever someone connects to that Jump Item. Jump Item level session policies have the highest priority among the policy types that participate in the session*.

If a tool is explicitly set to Allow or Deny, that decision applies.

If a tool is set to Not Defined, the system moves to the next Session Policy checkpoint to seek out if an answer (Allow or Deny) needs to be applied.

2. Public Portal Session Policy

If a Session Policy is applied to a Public Portal, then the system checks the Public Portal Session Policy next.

Because you can have multiple Public Portals, you can apply different Session Policies for each portal. This is useful when different business units or external users need different tools to be set to Allow or Deny due to regional regulations or compliance purposes.

The system scans all tools in this policy for an Allow or Deny decision.

If it finds a defined result, this policy determines the outcome.

The system evaluates this policy only when a session policy is applied at the public portal level.

🚧

Important information

Public Portal Session Policies can be active in a Remote Support session even if a customer does not initiate a session via a Public Portal Site.

For example, when a Rep invites a customer to a session with a Session Invitation Link, a Public Portal is featured and is therefore using the Session Policy designated to that Public Portal.

3. Session Policy defined by Group Policy

If the system finds that there are still tools set to Not Defined at the Public Portal Session Policy level, the system check continues on to the Session Policy defined by Group Policy.

There are two options available for configuring a Session Policy at the Group Policy level. You can:

1. Select an existing session policy and reuse it or
2. Create a custom session policy within a group policy itself.

To verify which session policy is defined in a group policy:

1. Go to User & Security > Group Policies.
2. Expand Attended/Unattended Session Permissions.
3. Locate the Attended/Unattended Session Policy setting.

✅

Best practice

We recommend creating your Session Policies separately first, then applying it to the Group Policy configuration. This gives admins transparency of what is actually applied by providing context to how it relates to the appropriate Group Policy (Level 2 Support Session Policy → Level 2 Support Group Policy).

If you want to create a Session policy right from within your Group Policy configuration page, simply select Custom from the Attended/Unattended Session Policy drop-down and define your Session policy permissions for each tool.

4. Session Policy defined at the User Level

If the system still does not find an Allow or Deny decision for a specific tool, it will continue its search and checks the Session Policy defined at the user level.

At this level, you can do the following:

• Apply an existing session policy, or
• Create a custom session policy for the individual user.

User-level session policies allow you to define Allow, Deny, or Not Defined for each tool under the Attended/Unattended Session Policy section.

✅

Best practice

It is a best practice to define most user behavior through group policies for scalability and greater efficiency. Try to avoid direct user assignments whenever possible unless for rare exceptions.

5. Global Default Policy (Fallback)

If none of the previous checkpoints return an Allow or Deny decision, the system applies the Global Default Policy. The Global Default Policy cannot be deleted or be set to Not Defined. The system requires this policy to ensure that a decision is always available.

The Global Default Policy does the following:

• Acts as a required fallback mechanism in the event a tool is set to Not Defined throughout the entire Session Policy check process.
• Always returns Deny by default **
• Does not support Not Defined.

🚧

Important information

• If a session policy decision comes from the Global Default Policy, treat it as a warning. This result indicates a policy gap that you should review and address.
• **By default Remote Support sets all answers to Deny for the Global Default Policy. Review your Global Default settings to confirm these settings have not changed during onboarding or from a previous admin.

.

Session Policy examples

Below are some examples highlighting how the system decides what to do for each tool according to the Session Policy evaluation order summary.

Example 1: File Transfer tool

Given the following example:

• The File Transfer tool is set to Yes for Group Policy.
• The File Transfer tool is set to No for Public Portal.
• The File Transfer tool is set to Not Defined for Jump Item.

Outcome: The representative cannot use the file transfer tool in a Remote Support session.

Reasons why: If we use the checkpoint hierarchy list, the first item in the list, Jump Item, is set to Not Defined. We move to the next list item, Public portal, which is set to No. Even though Group policy is set to Yes, the first valid answer takes precedence, which in this scenario is Public portal.

Example 2: Registry tool

Given the following example:

• The Registry tool is set to No for Group Policy.
• The Registry tool is set to Not Defined for Public Portal.
• The Registry tool is set to Yes for Jump Item.

Outcome: The representative is able to use the file registry tool in a Remote Support session.

Reasons why: Using the checkpoint evaluation order, the first item in the list, Jump Item, is set to Yes. Since this is the first item in the checkpoint and the first valid answer, the policy is applied. While this setting would rarely be applied in the real world, we wanted to use this as an example to highlight and reinforce the impact of the logic on what gets applied.

🚧

Important information

Use the Session Policy Simulator. If you want to audit or confirm how session policies are applied in any given scenario, run the simulator to identify which policy provided the winning decision.

Hopefully by now you have a better handle on how Session Policy logic applies to real world scenarios. To keep things simple, we used examples where a representative was part of one Group Policy only.

In reality, many organizations have representatives that are members of multiple Group Policies.

How does Remote Support resolve situations when these settings conflict with one another? That is the purpose of our next section in understanding how Group Policies logic works.

Group policy permissions

Group policies define permissions and settings for groups of users. They help administrators standardize and streamline access control across the environment, not only for session policies but for all configuration areas (/login and the Rep Console).

Because a user can be part of multiple group policies, the system uses a specific evaluation logic to determine how to apply the correct settings in each scenario.

Multiple Group assignments evaluation logic

Whenever a user signs in to /login or a Representative Console, the system evaluates them against any Group Policy they are a part of. If the system finds that a user is part of two or more Group Policies, all applicable settings get applied. For example, if a user is part of a Windows Support Group Policy along with a Mac Support Group Policy, then they will inherit answers from both Group Policies.

What happens if a user is part of two or more Group Policies that contain conflicting answers, like in the example below?

In this context, the system triggers an evaluation process that reviews the user against all of the Group Policies they are a part of from top to bottom. Because the system checks the Group Policies from top to bottom, it applies the configuration of the Group Policy that answered last for the specific setting.

As the result, the following logic is applied:

In the previous example, we saw how the system decides what to apply when we have binary answers (Allow or Deny).

Let’s see how this logic plays out when three Group Policies with three distinct configuration options are available for one user.

✅

Example: John Doe belongs to three group policies

Outcome: John Doe receives View All Sessions reporting permissions.

Reason why: Because the system processes group policies in order and applies the last defined result.

🚧

Important information

Just like Session Policies, if configuration settings of all applicable Group Policies return Not Defined, the system looks at the user’s account for answers.

Group Policy Logic Bypass: The Final Checkbox

In some occasion, an admin may have a unique edge case scenario where all Group Policies are set according to expectations with the exception of one or more particular settings. In the scenarios an admin may not want to configure an entirely new Group Policy just to accommodate a change of one setting.

Instead, an admin can take advantage of the Final Checkbox. This allows an admin to bypass the Group Policy order logic and set that answer to take precedence over other competing Group Policies a member is a part of.

To illustrate, let’s say John Doe is getting trained to become the new Windows Server Support Manager. To prepare for the final steps of taking the new role, John Doe is added to the Windows Server Support - Manager Group Policy. To be safe, admins decide to turn on Final Checkbox on some of the settings applied in the Windows Server Support Group Policy. This way, John Doe still inherits all configurations and permissions needed to be a successful manager, while giving admins the ability to apply less privileged settings from another Group Policy.

✅

Example: Policy check with Final setting

John Doe signs in and belongs to the following reporting groups:

Outcome: As a result of the logic, John Doe inherits the setting from Windows Server Support Group Policy- View Only Their Sessions. All other group policies he belongs to are ignored for this setting.

Reason why: Because there is a Final setting in Windows Server Support group, this takes precedence and wins even though it is not the last group policy to answer.

✅

Tip

• Order policies carefully. Use Change order to arrange group policies. Place least permissive policies higher and more permissive policies lower if you want broader access to apply last.
• Favor group policies over user policies. Define most user behavior through group policies for scalability, and reserve direct user assignments for exceptions.
• Use the Session Policy Simulator. If the effective result is unexpected, run the simulator to identify which policy provided the winning decision.

Key takeaways:

• Session Policy Check Process: Remote Support determines which session tools can be applied for a user during a remote access session. It performs a Session Policy Check that evaluates all available tools from the various session policy sources in a defined order. This order controls which policies are applied first and ultimately determines which actions and tools are allowed.
• Group policy order matters. When a user belongs to more than one group policy, the system applies them top to bottom. The policy that answers last takes precedent, unless a higher policy marks a setting as Final.
• Final setting: This only applies to the users who are part of the Group Policy which contain a Final setting. When selected, Final overrides permissions from lower placed policies. If you select Final checkbox on two or more Group Policy settings, the first final read takes precedent.