All Windows users are familiar with the User Account Control (UAC) prompt:

It’s been a bit of a love-hate relationship from the very start, when UAC made its first appearance with Windows Vista. This old Apple commercial illustrates the UAC experience fairly well (click photo to view video)…

And although the security software has improved in leaps and bounds since Vista, it’s still far from perfect – particularly for bigger enterprises with a large number of endpoints.

UAC and its quirks are a big reason why software like Admin By Request exists – we saw the need to be able to do a lot more that what UAC could deliver out of the box: compliance, management, logging, granularity and more, all rolled into a good user experience.

So let’s take a look into what UAC is and isn’t, and why it’s an important (albeit, clumsy) part of Windows security.

The Idea Behind It

UAC exists to prevent illegitimate changes to the computer system – changes that could be made by apps, users, or malware.

The security feature also aims to enable users to elevate in flow from a standard user account to an administrator account; to run common processes as a standard or administrative user without logging off, switching users, or using Run As.

How It Works:

With UAC, the system creates an access token for a user at log in, which contains specific data for authorisation purposes, such as the level of access that the user is granted.

This data is used by Windows to track what resources a user can and can’t access.

Standard User

Standard user access tokens have the least amount of privileges on the device possible.

On a standard user account, apps can only be launched with the standard user access token, and these apps are only able to operate within the bounds of the access rights granted to a standard user.

Administrative User

A full administrator access token, on the other hand, includes Windows privileges and SIDs.

A user account that belongs to the local administrator group has Windows privileges assigned to it. However, all apps launched by this user will run in the security context of a standard user by default; that is, unless an administrator specifically authorises the app to gain admin-level access to the system.

When an app does need to run with more than standard user rights, UAC will prompt the user to provide consent or input administrator credentials via the pop-up UI.

When consent is given or credentials submitted successfully, UAC allows the app to make use of a full administrative token, and the user to then have explicit control of apps that are making system level changes on their device.

Quirks and Questions

Firstly, there’s question of whether UAC offers too much flexibility.

Being user-driven, the low-compliance software can be circumvented by impatient users thanks to some much-too-lenient setting levels available for selection with the UAC settings page:

Of the four levels of UAC settings, the lower two allow for changes to be made to Windows settings without the consent or credentials pop-up being displayed – with the lowest also allowing for installations without approval.

Even if policies in the workplace require UAC settings to be set at the highest level (default), what’s to stop a user circumventing UAC controls on a home device that has access to company resources?

As the saying goes, “If you know what’s good for you”. The truth is, most users don’t. And with UAC, underqualified users can still end up making decisions that compromise the system and network.

But on the other side of the fence, sticking to the recommended default UAC settings leads instead to users pulling hair, gnashing teeth, and demanding blood (or at least, a little bit of independence).

Paul Boutin, Gadgetwise writer with the New York Times, described the UAC experience accurately: “Those (UAC) pop-ups are like having your Mother hover over your shoulder while you work.”

And user’s far and wide have resonated this cry, citing intrusive repetitiveness and disruption as the bane of their Window’s user experience.

Intrusive Repetitiveness

At the default setting level, UAC will more than likely be prompting both administrative and standard users to the point where it disrupts productivity.

In order to gain elevation when prompted with the credential UI, standard users would require their own separate admin credentials, someone else’s admin credentials, or for an IT tech to physically come and enter credentials on their machine.

In an enterprise with 25,000+ endpoints, you can imagine the chaos:

Unnecessary admin accounts littering the workplace.

The potential for administrative credentials to be stolen or compromised soaring every time an IT admin enters their details for a frustrated standard user trying to do a simple, everyday task.

Administrative users (who need frequent elevation) feeling justifiably frustrated at continuously having to enter their details throughout the day when they have already been approved within the workplace to make changes to the system.

And so on and so forth.

Window’s UAC dream of a ‘seamless approval flow’ experience, that a large organisation needs to function effectively, isn’t achieved.

But, despite complaints, disabling UAC would result in even worse situations than those described above.

So what does an organisation do when a necessary security tool doesn’t quite strike the right balance between security and flexibility?

Finding the Balance with Admin By Request

They find a user access security tool that delivers the whole package of tight security and good useability in one.

Admin By Request’s high-compliance, policy-driven Privileged Access Management (PAM) solution, suitable for enterprises with any number of endpoints, addresses the need for UAC – and refines the solution.

1. Elevating processes and not the end user.

The ‘seamless approval flow’ experience is achieved without compromising security, with Admin By Request allowing for on-demand elevation of applications – not users.

When the software grants administrator access, the app gains elevation while in use, but the user account never gets full administrator access to the system.

This method ensures the Principle of Least Privilege (POLP) and Just-in-Time elevation (JIT) – granting users the minimum privileges necessary, and only when necessary – are adhered to at all times.

2. A customised consent.exe

When a user requires elevation, a customised Admin By Request version of UAC’s Consent UI displays the PAM software’s default ‘Confirm’ pop-up to the user.

The software can also be configured to display a credentials pop-up.

The settings that determine which pop-up is displayed to different groups of users can be configured within the Admin By Request user portal, under global and sub-settings:

3. Whitelisting

Admin By Request allows for the whitelisting of applications known to be safe, so that users aren’t interrupted every time they need access to common processes.

When configuring whitelisting in the Admin By Request user portal, if you leave ‘User Confirmation’ toggled off, the app in question will start as admin:

This highly productive feature allows for common, approved apps to simply start as admin, meaning your once frustrated developers don’t have to confirm every time they want to start Visual Studio.

Essentially the solution takes a user-driven, self-elevation approach – but only within the bounds of policies and security settings set out within the Admin By Request user portal.

None but your IT admins are able to make any changes to Admin By Request settings, and all elevated activity is monitored and logged within the Admin By Request Auditlog, giving compliance the tick.

The scale is never tipped in favour of flexibility over security or vice versa – as is often the case with our fair-weathered friend, UAC.

Summary

Microsoft’s UAC is a necessity and certainly carries some benefits in desktop management.

Admin By Request takes the best bits of UAC – and then adds more.

Download the latest version of Admin By Request today.