Versatile admin elevation

Version 6 of Admin By Request brings with it a rather ‘tasty’ new functionality which enables ‘per app’ elevations using the traditional ‘run as administrator’ method which most users are familiar with. So with the launch of ‘run as’ functionality, we thought it would be a good time to dish up a brief re-cap of all three elevations methods available in Admin By Request, and cover the best situation to use them in.

1. Elevation Via Whitelisting (now called pre-approval)

Admin By Request comes with sophisticated approval workflows built in, which enable portal administrators to process each elevation request based on a ‘reason’ and to then decide on whether or not to approve it.

But what if you have a known application, perhaps legacy, that some staff need to use all the time? You don’t want to have to ‘workflow’ these requests, but at the same time you don’t want there to be a Local Admin ‘free buffet’ either.

This is the ideal scenario for application white-listing.

To set up an application for Whitelist:

• Log in to the portal and navigate to ‘Settings > Whitelist’
• Select ‘new’ to create a new Whitelist entry
• Enter the location of the file (program files, Windows directory, any, or custom) and then the file name.
• On the Whitelist setting is changed it might take a few hours for settings to be taken up by clients.

Any user can now run this program without having to gain full local admin rights to their system.

For more granular control, you can deploy a sub setting and create additional Whitelist entries for those users in that sub setting – so if you need to Whitelist an application for engineering, you would add this only to the engineering sub setting Whitelist, so only that department could auto elevate it.

TIP: Learning Mode automatically detects elevations and enables one click adding to Whitelists.

2. Run As Administrator Elevation

(Above) If a user / group has ‘Run As Admin’ mode enabled, they can request elevation simply by right clicking on the application in question and selecting the ‘Run as administrator’ icon from the properties.

New in Admin By Request 6 is the ability to perform ‘per app’ elevations. The main benefit of this is, like whitelisting, you are giving the user the ability to elevate just a single application, rather than granting elevated access to the entire system. Another benefit of the new ‘Run As Admin’ mode is that it works the exact the same way as users likely got apps to run with Admin Elevation before, so there is minimal need to ‘re-educate’ users in how to get elevated rights when running apps.

Unlike whitelisting, ‘Run As’ elevations can be configured to require the user to:

• Fill out a ‘reason’ for the elevation
• Require manual approval to run the application elevated

You have the option to assign different users / groups of staff different combinations of these options, with the use of our sub settings functionality.

So when you need to manage the granting of elevation ‘per application’ and not the entire system, the ‘Run As Administrator’ method is the right choice.

3. Full Session Elevation

(Above) In order to obtain ‘Full Session’ elevation (again only if enabled for the user/group), right clicking on the green ‘Admin By Request’ icon in the tray invokes the ‘Request administrator access’ option from where the user can start the full session elevation workflow.

Sort of self-explanatory, full session elevation provides exactly that, in that any user given full session elevation gets full local admin rights on their system.

Full session elevation mode is ideal for the following situations:

• Developer using a lot of elevated applications
• Elevation access to ‘system’ resources such as drivers, printers etc
• Someone that needs to have their elevation only for a specific amount of time

As with ‘Run As’ mode, everything in the elevation session is audited, so you will get to see the reason why the person needs the elevation, anything installed, uninstalled or run.

Some extra protections were added to Full Session elevation mode in version 6, such as the ability to block the elevation of any system files (CMD.EXE etc) whilst running elevated, and the ability to ‘force terminate’ any elevated processes once the timer has run down.

4. No Elevation, Elevation!

(Above) if you have excluded a user from Admin By Request in order to deny them the ability to request elevations, it is still possible to perform an ad-hoc elevation with a single use PIN. The end user (or IT support person working on PC) would enter PIN 1 into the portal, and use this to generate PIN 2.

Technically there are FOUR ways to get elevation in Admin By Request, the fourth way is not ‘user self initiated’ and so should be treated separately.

Let’s say you deploy Admin By Request to your entire organisation of say 1,000 staff, however you only want to give 600 people the ability to use Admin By Request to elevate as and when they want. To do this you set up a master ‘Global Scope’ in the portal settings. This scope defines who is able to run Admin By Request in order to either auto elevate or request elevation. Anyone not in this scope, can’t use Admin By Request to elevate unilaterally.

However, a very nice feature, new in version 6, is that even if a user is out of the Admin By Request user scope, it is still possible to obtain elevation, via a special single use challenge / response PIN code. This code is ONLY be obtained from IT / portal administrator.

So if a user brings their laptop into your IT department and you know this user is out of Admin By Request user scope, and they need elevation ‘in profile’, all is not lost. You can easily generate a PIN and start an elevated session, hopefully while that user pops out to buy you a plate of prawn sushi – served three ways!