Everything you need to know about Support Assist with Admin By Request – Learn with Joy

0
Support Assist with Admin By Reuqest

Today’s blog post focuses on the Support Assist feature of Admin By Request.

What is Admin By Request?

Admin By Request from Fastrack Software is a Privileged Access Management (PAM)
solution for Windows (Server/Client) and Mac endpoints that allows you to revoke 
local admin rights of the end-users from the workstations/endpoints without 
interrupting normal work flows.

Want to know more about Admin By Request?

Do check out my previous blog post where I have talked about how the product works.
Note that it was with the then GA release of the ABR windows client (version 6.3). 

Recently, the team redesigned the end-user expereince with the new version of its
windows client, version 7, GA released as of November 16th, 2020. You can read
my blog here to find out what's new with this release. 

When I was doing the beta testing for the now public released ABR client (version 7), I came across a feature that was actually introduced back with the previous client (version 6.4) – Support Assist.

This blog post is to discuss and understand what that new feature is and what purpose does it serve. To understand the same, let’s start with the fundamentals of Admin By Request.

Different ways a user can request for elevated privilege with Admin By Request

On a Windows 10 endpoint enabled with Admin By Request client, the end-user gets the following options for requesting privilege elevations.

Run as admin

This is the most common scenario which your end-user would be using to

  • request privilege elevation to install/uninstall an application, or
  • run a particular application with elevated privilege.
Admin By Request - Run as admin is the most common form of elevation requests to be made by end-users. By nature, it is per-time per-app elevation request that end-user would require to make when requiring to run an app/process with elevated privilege.
Admin By Request – Run as admin is the most common form of elevation requests to be made by end-users. By nature, it is per-time per-app elevation request that end-user would require to make when requiring to run an app/process with elevated privilege.

As you can understand, this is a per-time per-app elevation request that the end-user would require to make when requiring to run an app/process with elevated privilege.

You would see the audit entries for such requests in the Admin By Request portal as shown below

Admin By Request - Check the Run as admin audit events from the ABR portal
Admin By Request – Check the Run as admin audit events from the ABR portal

You can click on any records to see the activity records in more details as below

Admin By Request - Click to open a Run as admin audit event to see further details for that transaction.
Admin By Request – Click to open a Run as admin audit event to see further details for that transaction.

Request administrator access

Run as admin, though the most common form of elevation requests to be made by your end-users, due to its nature of being per-app per-time is not that effective for scenarios where it involves or requires to run multiple tasks with elevated privileges simultaneously.

This is where Request administrator access comes handy.

You being the IT Admin can allow the end-user to start a protected admin session on the workstation where the user requesting the same will be provided with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

Admin By Request - Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.
Admin By Request – Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

In the below snap, you see an example Admin session in use where the end-user is installing an application and also working on an elevated PowerShell session. [Though this might not seem to be the best of examples, hope you are getting the point am talking about.]

Admin By Request - Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.
Admin By Request – Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

If the Admin session is not allowed by IT Admin, the end-user would have required to make two elevation requests, separate Run as admin requests for performing the same set of activities.

As usual, the entire session is audited for the activities performed and is available for future reference.

Everything you need to know about Support Assist with Admin By Request - Learn with Joy 1
Admin By Request – Check the Admin Session audit events from the ABR portal

You can click to see further details, what all activities were performed during the elevated session.

Admin By Request - Click to open an Admin Session audit event to see further details for that transaction.
Admin By Request – Click to open an Admin Session audit event to see further details for that transaction.

Both the features as shown above had been a part of Admin By Request for a long and helps to address end-user requirements when it comes to elevation requests.

Then naturally comes the question.

What is Support Assist? What is the need for this new feature?

Understanding Support Assist and the need for it

Consider a scenario as below

  • End-user reaches out to helpdesk with a request to install some applications on his company device required for work. 
  • End-user asks helpdesk engineer to take a remote session and perform the activities as required as he is not that good with computers.
  • Helpdesk engineer initiates a remote session with end-user consent and proceeds to start an Admin session on the end-user device. (Or maybe request for Run as admin to execute an installer file.)

At this point, Admin By Request may either prompt to provide a Reason for the requested action or not, depending on configuration settings of the scope that applies to the end-user.

Admin By Reuqest - IT Admin can create seperate scopes (Global and multiples of sub-setting scopes) and then use those scopes to further control the elevation requests using any combination as deemed suitable per organization security policy.
Admin By Reuqest – IT Admin can create seperate scopes (Global and multiples of sub-setting scopes) and then use those scopes to further control the elevation requests using any combination as deemed suitable per organization security policy.

Whatever be the configuration, the Helpdesk engineer starts the admin session (or Run as admin) on the end-user device over remote and performs the necessary activities as requested.

As usual, the action gets audited in the Admin By Request portal, but the audit event is tagged to the end-user account.

This is not ideal since even though it was the end-user requesting for the actions in the audit events as captured, but the activities were actually performed by the Helpdesk engineer.

Also when questioned later, the end-user may actually deny the audited actions stating that he/she provided remote access to the Helpdesk engineer and then went away to grab a coffee or maybe something else.

On the contrary, if the Helpdesk engineer logs-in to end-user device using his own credential and then there can again be two scenarios.

  • Helpdesk engineer has local admin rights on the endpoints by virtue of Azure AD Device Administrator role  or made via OMA-URI/PowerShell script deployment, and logs-in to the end-user device to perform the necessary actions/activities as per user request.

This action can’t be audited by Admin By Request and as such should be avoided if you are implementing ABR in your environment. Ensure that your Helpdesk team also goes via the Admin By Request flows when supporting end-users. This ensures proper audits of admin actions

  • Helpdesk engineer does not have local admin rights on the endpoint, but still logs-in to end-user device to perform the activities as requested by user, elevating the session/process via Admin By Request.

In this case, the audit will pick up the Helpdesk engineer as the current logged-in Windows user requesting elevation and performing activities.

This is not ideal either since even though the actions were performed by the Helpdesk engineer, which is true, but it was at the request of the end-user. Also, the end-user would not be able to monitor the actions of the Helpdesk engineer.

Thus, if auditing actions performed with elevated privilege on the endpoints is a concern, then the ideal audit event should show

  • the Requestor [End-user]
  • the Executor [Helpdesk Engineer], and
  • the actions/activities being performed with elevated privilege,

thus logging both the identities engaged in the entire transaction. This is what Support Assist in Admin By Request facilitates.

Support Assist introduces a whole new way of how IT Support can work to assist end-users more efficiently within the scope of Admin By Request.

When assisting end-user, helpdesk/deskside support engineers, instead of using the end-user logged-in Windows session or log-in to the end-user endpoint using own credentials to help resolve end-user requests, can make use of the Support Assist feature of Admin By Request which allows them to sign-in to Admin By Request on the end-user devices within the current end-user logged-in Windows session to start a support session within Admin By Request which is separate and not tagged to current logged-in Windows account and perform the actions as necessary to help resolve the end-user request.

The audit event for the session captures both the logged-in Windows user and the account used by the Helpdesk engineer to perform Support sign in.

Use-case scenarios of Support Assist

  • Users for whom IT has disabled both Run as admin and Admin Sessions (can be done using Global and Sub settings scopes) and as such are bounded to take assistance from the IT helpdesk for any tasks to be performed on the endpoint which requires admin rights.
  • Users for whom Run as admin/Administrator session is enabled but they are not the typical tech-savvy “IT users” and only go about doing their works on the device as configured and given to them by the company. Not very much affluent with self-service, they reach out to the IT helpdesk frequently to help sort issues.
  • Users who do not want to request for a Run as admin/Administrator session for app install/uninstall since they know the action will get audited and thus a concern.

Experience Admin By Request Support Assist feature

  • Helpdesk engineer starts a remote session with the end-user to assist.
  • Helpdesk engineer clicks on the Admin By Request icon expanding the System Tray and clicks on About Admin By Request and then clicks on Connectivity.
Starting a Support Assist session with Admin By Request - Available with client version 6.4 and above.
Starting a Support Assist session with Admin By Request – Available with client version 6.4 and above.
  • Helpdesk engineer clicks on Support sign in button the window that appears.
Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.
Starting a Support Assist session with Admin By RequestSupport Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.
  • Helpdesk engineer performs sign-in using own credentials.
Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.
Starting a Support Assist session with Admin By RequestSupport Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

A new Admin By Request session starts which runs as a separate process.

An Admin By Request branded pop-up window is displayed for the entire duration of the session which shows the account name that the helpdesk engineer used to sign-in to start the support session and also a timer similar to the Admin session.

Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.
Starting a Support Assist session with Admin By RequestSupport Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

There are actually two instances of the Admin By Request client process running on the end-point when a Support Assist session starts.

One always runs with the end-user identity (or the logged-in Windows user) and the other gets started as a result of Support sign-in running with the identity used by the Helpdesk engineer to sign-in to Admin By Request to start the support session.

A Support Assist session initiates two processes of Admin By Request on the endpoint - one running with Windows logged-in user account and the other running with the helpdesk engineer provided account to do the Support sign in
A Support Assist session initiates two processes of Admin By Request on the endpoint – one running with Windows logged-in user account and the other running with the helpdesk engineer provided account to do the Support sign in

Note: Helpdesk engineer starting a Support Assist session does not gain complete local admin privilege on the endpoint. The session is under the effect of the settings as configured by the IT Admin for the scope to which the Helpdesk engineer belongs.

Once done with assisting the end-user with the requested changes, the Helpdesk engineer can end the Support Assist session by clicking on the Done button and further confirming with Yes in the pop-up window.

Ending a Support Assist session with Admin By Request - Helpdesk Engineer clicks on Done when completed with making the necessary changes on the endpoint as requested by end-user and confirms to close the elevated support session.
Ending a Support Assist session with Admin By Request – Helpdesk Engineer clicks on Done when completed with making the necessary changes on the endpoint as requested by end-user and confirms to close the elevated support session.

Viewing Audit Events for a Support Assist session

Navigate to Auditlog tab within the Admin By Request portal to see audited events.

You can easily identify a Support Assist ABR elevation event from a normal ABR elevation event by looking at the User column.

Such events always come up with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.

Support Assist session with Admin By Request - Support Assist sessions can be easily identified in audited events since they appear with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.
Support Assist with Admin By Request – Support Assist sessions can be easily identified in audited events since they appear with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.

Support Assist audit events clearly shows

  • the logged-in Windows user (end-user) [Typically the Requestor]
  • the Helpdesk engineer who assisted the end-user [The Executor]
  • the app/program which was elevated (and if any software was installed/uninstalled)
Support Assist with Admin By Request - Support Assist sessions clearly shows the Requestor [End-User], Executor [Helpdesk Engineer who assisted] and the actions performed during the transaction.
Support Assist with Admin By Request – Support Assist sessions clearly shows the Requestor [End-User], Executor [Helpdesk Engineer who assisted] and the actions performed during the transaction.

The End

Well that was all for today. Do check out my other blogs on different Intune topics here.

Stay tuned to this blog siteSubscribe to get notified of new posts and be a member of the How To Managed Devices (HTMD) community.

Use the HTMD Forum to post your queries related to Intune/SCCM and get expert advice and answers from the HTMD community.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.