USER Account Control… but I’m an ADMIN!

User Account Control (UAC) has now been with us for almost 4 years, and still it is a mystery to a lot of people – what it does, why it does it and what value it adds… so I shall try to shed some light on this for those that want “complete control” of a system when logged on as an administrator.

I do not, under any circumstances, recommend disabling UAC.
If too many prompts are being thrown, look at what you are doing and why (if!) the application needs administrative access.

The most recognized UAC feature is the dimmed screen with the popup like this:


This is known as the ”Over The Shoulder” (OTS) prompt – the process starting has a flag that indicates it requires administrative privileges, this could be from any of the following:
- the built-in manifest for the executable
- a manifest created for the executable, for example by the Application Compatibility Toolkit (ACT)
- the shortcut used to launch the process has “run as administrator” checked

This is a user awareness feature – to inform the user that starting this process may potentially change the system if not used correctly, or so that they can determine whether it ought to be running (e.g. silently launched malware).

The above screenshot was taken when logged on as an administrator – yes, admins get to enjoy UAC too… and if you think about it, this makes more sense than for a standard user without privileges who has make a mess of the entire system.

The one and only exception to UAC for interactive users is the built-in Administrator user account – even members of the Administrators group are subject to UAC.

If a non-admin user launches a process that requires/requests elevation, the OTS prompt would also ask for credentials for an administrator to authorize the  action.


NOTE: From here onwards I am referring to the UAC model from Windows 7/Server 2008 R2 onwards, as it has been revised a little since Windows Vista, so some features may not apply to earlier versions of Windows.

Q: Can the OTS prompt be enabled/disabled on a per-application basis?
A: Yes, using manifests – look into the Application Compatibility Toolkit and set the requested privilege level accordingly:
asInvoker = no elevation, use the user token of the parent process
highestLevel = use the highest security token of the logged-on user
requireAdministrator = elevation will always occur
Of course, if the application does require administrative privileges and you force it to launch non-elevated, it probably won’t work correctly

Q: Can OTS prompts be auto-accepted for specific applications?
A: No, UAC behaviour is consistent for all applications

Can OTS prompts be auto-accepted for non-admins? A: No, if a process requires elevation then an administrator must enter credentials to authorize the action (otherwise this would be  massive security hole) – they can, however, be auto-denied through a policy:
User Account Control: Behavior of the elevation prompt for standard users

Q: Can OTS prompts be auto-accepted for admins?
A: Yes, there is a policy to configure this:
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
I do not recommend using “Elevate without prompting” as this seriously diminishes the value of UAC


For years we have been trying to convince people to log on as standard users, not administrators (and definitely not THE Administrator) but it has caused too many issues with legacy applications not working correctly, or failing to even start due to “access denied” problems because of what the application was trying to do.

UAC was introduced as a stop-gap to help end users work out what applications believe they need admin rights (as opposed to those that have just assumed them), and also for developers to finally take into account user permissions when writing their applications.

If an application launched by a standard user tries to write into an area considered as protected by the system (i.e. BUILTIN\Users does not have write permission there) then before Vista this would have likely crashed, hung or thrown an error message.

However, with UAC the write I/O is actually virtualized to a location under the user’s profile ( %userprofile%\AppData\Local\VirtualStore) which is what allows it to believe it succeeded – see my blog entry from 2008, Virtualization in Vista for an example of how this works.

In this respect, UAC is a global “shim” for many applications that works perfectly so they work and do not require (or even prompt for) elevation.


Some users want to log on as a user with administrative privileges for day-to-day use, and this is where UAC also plays a part, allowing them to be treated as a standard user unless they (or a process they run) request elevation.

This is achieved by admins getting a “split token”, which is really 2 security tokens associated with their logon session.
The first is their “full” token with all group memberships and privileges assigned, used when a process is elevated.
The second is their “standard user” token which has the Administrators group and administrative privileges stripped.

When a process is started by an administrator, unless elevation was triggered then the standard user token is used – so attempts to make changes to the system will fail (or get virtualized) for this process.
Any I/O done by this process will conveniently ignore the fact that the user is a member of Administrators except for any explicit DENY settings.


Consider the following scenario:
Alan is a member of the Administrators group, Bob is a member of the Users group
UAC is enabled with the default settings
Folder C:\FOO exists, with inheritance turned off and only Administrators having Full access
File C:\FOO\FOO.TXT was created by the Administrator user account

If Administrator logs on and starts a Command Prompt process (always elevated due to the UAC exception, remember?) then TYPE C:\FOO\FOO.TXT will result in success.

If Alan logs on and starts a Command Prompt process elevated (triggers an OTS prompt, as Administrators are still subject to UAC by default) then the same command will also succeed.

If Alan starts a Command Prompt without elevation then the command will fail with “access denied”.
This is the one that catches people out - they assume as Alan is a member of Administrators this should work.

If Bob logs on and starts a Command Prompt, the command will also fail.

If Bob wanted to launch an elevated Command Prompt then Alan would have to enter his own credentials at the OTS prompt, granting that specific process administrative privileges – from this process the command would succeed.


In the above scenario we can allow Alan to access the file from a non-elevated process by adding an Access Control Entry (ACE) in the Access Control List (ACL) on the file which is either Alan’s specific user account or a another security group to which Alan belongs – then his standard user token will have this when he logs on.

(This is why I mentioned explicitly disabling inheritance in the scenario, to avoid having permissions that have filtered down from the root or parent folder, such as BUILTIN\Users having read access.)


Another quirk of UAC to be aware of – when a member of the Administrators group creates an object using their admin token, the owner is set to the Administrators group, but if it is created using their standard user token it would be owned by the user specifically.

This needs to be taken into account when enumerating permissions if CREATOR OWNER is mentioned in the ACL – owning an object does not grant you any permission other than to change the permissions, so taking ownership of an object is only step 1 of 2 if you are trying to get write access (or delete it) – you then have to grant yourself the necessary permissions.


So be aware of using the standard user token when logged on as a member of Administrators when trying to resolve “access denied” issues – don’t remove your user from the Users group just because you are in the Administrators group or you may remove way too many required (read) permissions and be more restricted than a regular user!

Be aware also of the unique nature of the Administrator user – it’s disabled by default on the client versions of Windows for a reason, and being a member of Administrators is not quite the same as being the Administrator.