Customer/End User Approval for Jump Client Sessions

Others can correct me if I’m wrong, but I don’t believe you can stop a Rep from initiating a jump into the machine - however, you can set it so that each tool they use requires permission from the user.  For example, you can set it so that the person has to hit the “approve” button in the chat window before the Rep can see their screen, their system information, etc.  However, I don’t believe there is direct way to prevent someone from initiating that first initial jump/connection process to the device.

That being said, if you want this for small subset of users/computers, there is technically a way you can “rig” it to work like needing pre-approval for specific users:

1.  You set up MFA on their account using your MFA device (not theirs).  Don't require MFA for login, just enable it and then set it up on your own MFA device.
2. Use a jump group/group policy to require MFA when connecting to devices in that jump group.
3. When the user wants to jump into any computer in that group, it will ask for a MFA code/push - that only you have.  They’d call/chat you for that code/push, you provide/approve it, and it will allow them to initiate a jump into the computer.

To my knowledge, this is the only way you can stop someone from initiating a jump.  Again, someone please correct me if I’m wrong.

Thanks for your reply, its appreciated, the challenge we have is that we are supported third party clients, who are not part of our organization, as such we cant enable MFA for them, and our users aready go through MFA to access Remote Support.

The clients we are working with want an Approve Reject mechanism, which i believe PRA has for a connection, and i was lead to believe that Remote Support also has similar.

I think that may be the differentiating feature between Remote Support and PRA.  PRA seems to be more geared toward securely enabling external entities access to internal devices.  Remote Support, while having the ability to access outside resources, seems to be more geared towards secured internal remote access to internal resources.  You can certainly use group policies in Remote Support to limit who can access what resources, and at specific times, but stopping a session from being initiated is a bit more difficult.  That being said, being able to jump into a device doesn't mean they have the ability to actual screen share, run commands, etc.  You, as the admin, have to give them those additional rights.  Someone correct me if I’m wrong here, but I think the “default access” is just chatting in the chat box.  You have to provide all other rights outside of that.

Thinking more on this… there may be another way to make it happen.  Do it via group policy in the admin console.  Each vendor has it’s own policy and login schedule.  When the vendor doesn't need remote support, you make the login schedule from like 1:59 AM to 2:00 AM, and force logout when their scheduled time is over - but don't tell them about this 1 minute time frame.   That way, even if they try to log in outside of that timeframe, they get an error. Then when you want them to actually have access, you change the group policy for the span of time you actually want them in.  Just remember to change it back after they’re done.  They are allowed to log in at that time, but no other time.  You can technically even set this up in advance for a day later in the week. 

For us, the Bomgar Integration Client (BIC) really helps with peace of mind as it records everything done in all sessions, in case we discover a problem later.

TL;DR - I don’t think there is a native way to do what you want in Remote Support, but there is a way to use the Login Scheduling to do something similar.