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
Q: 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.
I was just browsing around on TechNet for info and came across Paul Addams blog and a post about UAC
It was the mistake to leave the user in the admin group. The people only look at which group they are.
next, the documentation is too complicated for the average joe.
UAC could be considered a half-way house to getting users to be users - letting them logon as Administrators but be treated as Users.
The mistake of making the first user a member of Administrators was made a long time ago and I'm sure is not trivial to undo.
I log onto my home machine as a standard user and when UAC pops up I have to enter the credentials of an administrator, UAC has been left at the default.
Some modern apps still trigger OTS prompts, so we still have a way to go before developers will not assume the user has admin privileges.
UAC needed to be opaque in terms of its presence (popups) but as transparent as possible in its behaviour (it does not PREVENT things from happening, it just ALERTS the user).
Removing admin rights from users that have enjoyed or expected them for years would have a much bigger impact, and John Q User is probably not ready to have 2 sets of logon credentials and understand when to use them.
Me, I'm just glad I wasn't on the team designing UAC, that must have been one heated debate :)
what you do is losing the best UAC improvement, having 2 tokens. In your case the UAC acts like RunAs service. This is bad and causes lot of bugs (settings are configured for the admin, but not for the current user).
Better: Setup creates 2 Users (Admin and standarduser), the user get a new membership (LUAEnhancer group, where you also get the 2 tokens). So people have the same comfortability like the when they are in the admin group when UAC is on, but the see that they are STANDARD users. Next, with this you can control which users can have the UAC enhancements. Currently you can only turn UAC on or Off. This is stupid and bad. 3rd, the UI must be coded better. Setting of the personalization trigger incorrectly an UAC prompt, because the Dialog is next to setting which belong to the system settings.
I'm using the default config but set the UAC slider to highest to get the Vista level back, which his much more secure, than the default crap setting in Windows 7, which can be by-passed (www.pretentiousname.com/.../win7_uac_whitelist2.html). I'm using the task scheduler as woraround to start program with elevated rights at startup.
In my blogs I try to clearly distinguish between that which is fact and that which is opinion, as there are many different "best" ways to achieve something depending on a number of variables.
The purpose of UAC has been described as "user awareness" and "convenience", and incorrectly at times as "security":
1. It lets non-admins run legacy or poorly-designed applications that would normally get "access denied" - virtualization
2. It lets all users be aware when an application is recognised as requiring admin privileges at launch - OTS prompt
3. Makes the default behaviour of launching a process for admins the same as users - Protected Admin
I distinguish between my daily use of a computer and infrequent administrative tasks I want to perform, by using separate user accounts with the relevant privileges and permissions.
If an application triggers an OTS prompt when I run as a standard user, I would log on as the admin user to find out what permissions it "requires" and then grant those permissions to the Users group and shim the application using ACT.
I would not run the application as the admin user, elevated - i.e. "Run As".
This also avoids the problem you mention about settings being configured for the wrong (admin) users per application, as I run only ever run applications as a user, and administer the system as an admin.
So for me, "best" is "more secure" - not using (or even being granted) more privileges or permissions that are needed to do the job at hand.
I feel am getting the best features UAC provides a standard user through virtualization and the presence of the OTS prompt, which then prompts me to address why the OTS prompt is appearing rather than simply accept it.
As UAC is not a security feature, relying on it as such and wanting it be as configurable as possible (whilst remaining "secure") is going to lead to disappointment.
The mention of the piggybacking the OTS prompt as an admin to elevate a process is an example of how responding to "there are too many popups" leading to a design change can introduce side effects, so being able to further configure the details of its behaviour would, in my opinion, be bad.
To cite an early line in my blog again:
"If too many prompts are being thrown, look at what you are doing and why (if!) the application needs administrative access."
Investigating the cause of a specific issue and using a surgical fix to address it is much better then using a sledgehammer approach which, while solving it, adds a lot more potential for harm.
See Mark Russinovich's "Inside Windows 7 User Account Control" article from July 2009 for a very good analysis, his method of explanation is much better than mine:
Jim Allchin is referenced by Mark too, in his blog entry "Security Features vs. Convenience":
I enjoyed reading this, I sort of already had this idea but it wasn't something which I knew for certain. Now I realize that UAC isn't just a nusance but actually a capable, handy feature which allows you to stay logged in as a user without compromising pc security nor program compatibility.