Secure By Design Series – Admin By Request

April 13, 2022

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.

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…

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.

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.

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.