This post is again related to Admin By Request and it’s a feature called Support Assist that I came across while I was working on my previous blog post – Admin By Request client version 7.
Support Assist with Admin By Request was actually introduced with the Windows client version 6.4 that was released back on August 17th, 2020.
This post is intended to discuss the same to understand what purpose it serves, to help you know what is Support Assist and how it helps Admin By Request to audit actions performed by the IT Helpdesk Engineers with elevated privilege on end-user systems.
To begin, as I always do, let’s start from the basics.
Table of Contents
Admin By Request: Different Ways to Request Elevation
Let’s start with all the options an end-user gets on a Windows 10 endpoint enabled with Admin By Request to request for elevated privilege.
Run As Admin
This is the most common scenario which your end-user would be using to request elevation to install/uninstall an application or run a particular application with elevated privilege.
As you can understand, this is a per-time per-app elevation request that end-user would require to make when requiring to run an app/process with elevated privilege.
You would see such requests getting audited in the Admin By Request Portal as shown below.
You can click on any records to see the activity records in more detail as below.
Request Administrator Access (Admin Session)
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.
IT Admin can allow the end-user to start a protected admin session on the workstation where the user requesting the elevation is provided with a sandboxed elevated session for a specified period of time as configured. This allows the user to perform various elevated tasks simultaneously which would otherwise require separate approvals.
In the below snap, you see an example Admin session in use where the end-user (me) is installing an application and also working on an elevated powershell session.
If the Admin session is not allowed, the end-user (me) would have had to make two elevation requests, separate Run as Admin requests for performing the same set of activities.
[Though this might not seem to be the best of examples, hope you are getting the point am talking about.]
As usual, the entire admin session is audited for the activities performed and is available for future reference.
You can click to see further details, what all activities were performed during the elevated session.
Both the features as shown above had been a part of Admin By Request since its inception and helped to address end-user elevation request requirements.
Then what is the new feature Support Assist all about?
Get to know Support Assist with Admin By Request
Understand the use-case scenarios of the new feature
- 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 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 goes about doing their works on the device as configured and given to them by the company. Not very much affluent with self-service, they reaches out to 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.
Also 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.)
Now based on the configuration of the scope that applies to the end-user, Admin By Request may either prompt to provide a Reason for the requested action or not (for UAC!).
Consider the condition is being met. The Helpdesk engineer starts the admin session (or Run as admin) on the end-user device over the remote and performs the necessary activities as requested.
As usual, the action will be audited in the Admin By Request portal. But the audits for this case will be for the end-user persona.
It will show the elevation request being made and the activities being performed by the end-user and not the Helpdesk engineer.
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 Admin By Request in your environment.
For proper audits, you would need to ensure that your IT Helpdesk team also goes via the Admin By Request flows when supporting end-users.
- 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 persona/identity/account requesting elevation and performing activities.
This is not an ideal scenario as well when it comes to the accuracy of audits, since even though the action is being performed by an IT Helpdesk engineer which is true, but it is to support the end-user request.
If auditing actions performed with elevated privilege on the endpoints is a concern, then ideally for such scenarios, the audit should show the IT Helpdesk engineer executing the actions on the request of the end-user persona, thus logging both the identities engaged in the entire transaction.
This is what Support Assist in Admin By Request facilitates.
Support Assist Demo Experience
Consider an IT Helpdesk Engineer initiates a remote session over Teams or any remote tools as used to the end-user system to assist on a submitted ticket. The IT Helpdesk Engineer
- clicked on the Admin By Request icon from the System Tray, then clicked on the option About Admin By Request, and from the next window clicked on Connectivity.
- clicks on the Support sign-in button from the window that appears.
This results in Admin By Request to generate a prompt that states Run as different user asking for credentials.
The IT Helpdesk engineer performs sign-in using own credentials and a sandboxed admin session (Support Assist session) starts on the endpoint.
The Admin By Request client displays the account used by the IT Helpdesk to initiate the Support Assist session.
Notice that the Support Assist Admin Session runs using the account used by the IT Helpdesk Engineer to sign-in which is different from the current logged-in Windows Account which is typically the end-user account.
Viewing Audited Events for Support Assist sessions
Navigate to the Auditlog tab within the Admin By Request portal to see the audited events.
You can easily identify a Support Assist elevation event from a regular elevation event in the audit log 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 IT Helpdesk Engineer to initiate the Support-Assist session.
Support Assist audit events clearly shows
- the logged-in Windows user (end-user) [Typically the Requestor]
- the account of IT Helpdesk engineer who assisted the end-user [The Executor]
- the app/program which was elevated (and if any software was installed/uninstalled during the support session)
THE END
Well that was all for today. Hope you would find this informative.
As I have mentioned in my other post, the product Admin By Request offers a free license to allow you test its functionalities on upto 25 endpoints to check if it meets your requirements. Check the FAQs.