Secure By Design Series – Admin By Request

This is a follow on from my previous post, talking about different possible approaches to removing Admin permissions from users’ devices.

This time I’ll go a bit deeper into some of the things we can do with Admin By Request (ABR), that smooths the removal for those most likely to feel the bite.

Who does this impact?

The main groups of device users most likely to be impacted by removing their admin permissions tends to consist of:

  • IT Admins/Support
  • “Power Users”
  • Developers
  • Users with legacy/bad applications
There’s probably other groups and scenarios, but these are the ones I tend to see most. I’ve glibly put in the “Power Users” group of users, that range anywhere from:
  • people that are clued up and have legitimate reasons for needing admin rights through to
  • those with a high-spec gaming rig at home and have used Linux twice so absolutely need admin rights as how could they possibly do their job without it!!
Joking aside, most of the time admin rights are not needed for daily usage. You certainly shouldn’t be running productivity tools like Outlook and a Web Browser with local admin rights. So how do we provide and yet limit the impact of giving rights when needed, or the concept of Just In Time (JIT)?

What’s the solution?

ABR turns the focus to JIT elevation of individual applications, rather than making a user a full local admin.
This allows the user to run safely for the daily normal activities, but still choose to elevate and run an individual application with administrative rights, only when needed (or Just in Time).
Out-the-box with ABR, this can work straight away (assuming the user has any admin rights removed, which can be done via ABR settings as well). The user will then get prompted for a reason why they’re trying to run an application as an administrator. They will then have to wait for the request to be approved.
Good in some use case scenarios, not in all.

Any Limitations?

While having an approval mechanism for general users (and probably the “Power Users”) can actually reduce the effort for IT Support, for trivial tasks such as printer driver installation (See print nightmare) it also means that IT Support themselves can leverage it during support calls. No more accounts with local admin rights on all workstations. Bonus!
However, for IT Admins, Developers or known legacy/bad applications, it would soon become a drain on support if they had to approve every request coming through. Not to mention the user dissatisfaction having to wait to elevate PowerShell or Visual Studio, for example.
However, ABR has configuration to ease this…
There is the option to create “Sub Settings” where you can override the base settings applied globally for groups of users to change the experience.
For example, a common sub setting may be to allow IT Admins to elevate without approval, maybe with just a reason (or not) for example.
Shows a sub setting configuration that turns off approval requirement

You can see in the picture above, while normal users would have to be approved for an elevation, members of the specific AD group assigned to this sub setting no longer require an approval or reason to be entered.

Meaning they can just simply right click, choose “Run As Administrator” and carry on with their task without interruption. 

However, if they do require a full administrator session (to avoid constant prompts) they need to enter a reason (for auditing purposes) but still don’t require approval.

Simple terms, these are trusted individuals.

But wait, there’s more

However, there are still times when even a couple of extra prompts (Code of conduct messages etc) can still cause user dissatisfaction, so we can even more granularly tune the solution, in the form of pre-approved applications.

As another example, it’s very common to have to elevate Visual Studio for various tasks, so pre-approving that specific application will further streamline the experience.

While pre-approving apps in a sub setting that doesn’t require approval is usually redundant, the trick here is to turn off the setting for user confirmation…

Admin by Request pre approved application list

A similar configuration could be applied to legacy/bad applications that require admin rights. Creating an pre-approval and forcing the app to run elevated will mean the user doesn’t have to alter their workflow and can simply click the app shortcut and carry on with their day.

Shows setting a specific application to always launch elevated.

The brilliant thing is, you don’t have to simply trust that the system isn’t being abused, it’s not a closed magic black box. There is a full audit log of activities which can be used to keep an eye on what’s going on in the environment and data can be viewed in various reports or pulled into Power BI for your own reporting customisations.

Shows the Audit Log feature of ABR

Need more info?

This post is still just scratching the surface of ABR and I could easily write for hours, but I hope this gives a view into some of the initial configuration options that remove some of the hurdles/common objections to removing admin rights.

If you would like to know more or have a demo of the Admin By Request solution, feel free to reach out to myself and the team here at PowerON, we will be more than happy to help.

Find us on Twitter: @StevyBsc or @PowerON_UK

Or get in touch with our team here.

Share on:


Webinar: Protecting your Data in 2022

Let’s face it – backups are rarely checked or updated once implemented. So how would you know if your data had been breached?

Find out more
Share on Facebook
Share on Twitter
Share on LinkedIn

Related blogs

two people at desk looking at code

AOVPN DPC V4.0 is Now Live!

Today we’re very excited to announce the release of AOVPN DPC 4.0 with support for Windows 11! AOVPN Dynamic Profile Configurator is now functional with