The Curious Case of the Redundant UAC Policies

[Chris Jackson]

First posted to MSDN on Oct, 06 2009

One of the unfortunate consequences of actually having to ship your software at some point is that you have to make some compromises along the way. The decisions you make can vary based on the time you are called upon to make them. As frustrating as that is for somebody who is trying to understand the system by trying to reverse how we make decisions, it remains a fact of life. Case in point: for anybody who has explored the updates to the User Account Control (UAC) policies on Windows 7, you may have noticed that there are multiple policies which appear to govern the exact same thing. In fact, they do govern the exact same thing. User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode has the following options: Elevate Without Prompting
Prompt for credentials on the secure desktop
Prompt for consent on the secure desktop
Prompt for credentials
Prompt for consent
Prompt for consent for non-Windows binaries (default) User Account Control: Behavior of the elevation prompt for standard users has the following options: Automatically deny elevation requests
Prompt for credentials on the secure desktop
Prompt for credentials (default) At the same time, you’ll find a policy that configures the secure desktop: User Account Control: Switch to the secure desktop when prompting for elevation (enabled by default) What’s going on here – aren’t these directly overlapping? Well, first let’s help you sort out how to use the policies, next we’ll explain why there are two ways to configure the same thing, and finally we’ll chart out the outcome to give you the easy answers. A configuration request to use the secure desktop always wins. Whether you configure the admin policy, the standard user policy, or the secure desktop policy, any vote for the secure desktop will cause Windows to use the secure desktop. So, what happened? While we were re-doing UAC to make it “less prompty” for Windows 7, we were changing a number of things. We added the ability to exclude Windows binaries. We added a slider instead of an on-off switch. While you are mucking around anyway, you may think, “what if I wanted to have different secure desktop behavior for my standard users than I do for my administrators?” You can’t with only one policy. And it doesn’t take that much additional effort to add a couple of additional options. But you’ll note that there is no secure desktop option for Prompt for consent for non-Windows binaries. We’d left the secure desktop policy there for application compatibility reasons, but we didn’t use it. So, we’re happily moving along, when we eventually noticed that there were some accessibility issues in some scenarios when not using the secure desktop, so we needed to have an option to make the “less prompty, but on the secure desktop” setting which, as you can see, doesn’t exist. Now, if you think about it as if it were your own software, how long would it take you to fix it? It’d take you no time at all to add a new option to the dropdown. You can probably come up with a very easy way to implement the change in consent.exe for reading that policy as well. But Windows is a complex place. That’s not all you’d have to do. What about the customer experience improvement program? You have a finite, already defined amount of room to feed back all of your configuration and data here. If you change your compression algorithm to incorporate this new option, then you impact all kinds of teams. Could you do it? Sure. But it was at a point in the process when you stop making “blue sky” designs that are the best implementation, and instead fall in the category of “do the minimal change necessary to achieve the required goals”. Architectural changes late in the process aren’t going to win if there are other alternatives. The fastest way was to start using the existing secure desktop policy again. So we did. Better that than to delay shipping.

So, here’s what your secure desktop behavior will be, depending on configuration:

Acct. Type	Account Elevation Policy	Secure Desktop Policy	Secure Desktop Used?
Administrator	Elevate Without Prompting	Enabled	n/a
Administrator	Prompt for credentials on the secure desktop	Enabled	Yes
Administrator	Prompt for consent on the secure desktop	Enabled	Yes
Administrator	Prompt for credentials	Enabled	Yes
Administrator	Prompt for consent	Enabled	Yes
Administrator	Prompt for consent for non-Windows binaries	Enabled	Yes
Administrator	Elevate Without Prompting	Disabled	n/a
Administrator	Prompt for credentials on the secure desktop	Disabled	Yes
Administrator	Prompt for consent on the secure desktop	Disabled	Yes
Administrator	Prompt for credentials	Disabled	No
Administrator	Prompt for consent	Disabled	No
Administrator	Prompt for consent for non-Windows binaries	Disabled	No
Standard User	Automatically deny elevation requests	Enabled	n/a
Standard User	Prompt for credentials on the secure desktop	Enabled	Yes
Standard User	Prompt for credentials	Enabled	Yes
Standard User	Automatically deny elevation requests	Disabled	n/a
Standard User	Prompt for credentials on the secure desktop	Disabled	Yes
Standard User	Prompt for credentials	Disabled	No