FAQ: Why can’t I bypass the UAC prompt?

The frequently asked question, "Why can't I bypass the UAC prompt?" is often accompanied by statements like one or more of the following:

  • "We want our application to run elevated automatically without prompting the user."

  • "I don't get why I can't authorize an application ONCE and be done with it."

  • "Unix has setuid root which lets you run privileged programs securely."

The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like setuid/suid or sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.

As I'm sure everyone knows, large parts of the Windows ecosystem have a long legacy of assuming that the end user has administrative permissions, and consequently a lot of programs work correctly only when run that way. (I'm not going to delve into that history here, nor will I entertain any finger-pointing on the topic at this time. One of these days I'll post my thoughts on that subject.) As computer security has become increasingly important, breaking that cycle became absolutely imperative. It is with the release of Windows Vista that the first major move in that direction is achieved. Indeed, the primary purpose of the technologies that comprise UAC is to make the "standard user" the default for Windows, encouraging software developers to create applications that do not require admin. It's not perfect by any means, but changing the ecosystem will take a long time, and UAC is a good first step.

Pre-approving code to run with elevated permissions without going through an elevation prompt, as described in the bulleted scenarios above, seems at first glance to be both useful and convenient. However, the negatives far outweigh those benefits. In particular:

  • The "standard user by default" vision would become impossible and ultimately never happen;

  • Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.

If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.

What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.) There would be no real way to protect that setting from anything running as admin. This would be especially true if it were settable via Group Policy (which would be expected, if not demanded).

"Well, so what? We're only talking about applications I approved!" OK, let's say that's true, but how do you ensure that a malicious user cannot use the application for purposes other than those for which it was intended? And at least as important – how do you ensure that malware that has infected the user's session cannot drive a setuid application programmatically to take over the system? Ensuring strict behavioral boundaries for complex software running with elevated privileges is (at best) incredibly difficult. And ensuring that it is free of exploitable design and implementation bugs is far beyond the capabilities of software engineering today. The complexity and risk compounds when you consider how many apps have extensibility points that load code that you or your IT admin may not be aware of, or that can load code or consume data from user-writable areas with minimal if any validation.

Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years, and continues to do so. In fact, several of the bugs in the recent Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)

In the past, elevation of privilege has tended not to be noticed in Windows – there is no real "elevation" if you're already running as admin. (**) With the Vista shift toward "standard user", EoP threats become much more important, and it is vital that Windows do as much as practical to mitigate them. That is also why Windows services are no longer able to interact with the user desktop. Taking on the setuid headaches that *nix has had to live with does not seem like a profitable deal.

We expect that in ordinary day-to-day usage, users should rarely, if ever, see elevation prompts, since most should rarely, if ever, have to perform administrative tasks – and never in a well-managed enterprise. Elevation prompts are to be expected when setting up a new system or installing new software. Beyond that, they should be infrequent enough that they catch your attention when they occur, and not simply trigger a reflexive approval response. This will increasingly be the case as more software conforms to least-privilege norms, and as improvements in the Windows user experience reduces prompting further.

Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)

Nitpicker's corner (***)

(*) Pointing out the obvious: local privilege escalation by definition means that the bad actor is already on your system. However, there's a huge difference between malware running as you (non-admin) and malware running with root privileges.  If there weren't, there would be no point (from a security point of view) in running with least privilege.

(**) "Elevation of privilege" in this context means "unauthorized elevation of privilege". Technically, yes, Administrator is not as powerful as System (in that there are operations that Administrator will get Access Denied where System will succeed), and System is not as powerful as kernel-mode code (in that there are operations that fail for user-mode code running as System that succeed when called from kernel code). However, two of the things that Administrator is authorized to do include: 1) configuring arbitrary code to run as System, and running it; and 2) loading arbitrary code into the kernel, and running it. Hence, if code is running as admin, there is nothing it is not authorized to do.

(***) "Nitpicker's corner" might be a trademark of The Old New Thing.

Comments (20)
  1. If privilege elevation was really required, as opposed to lazy programming, wouldn’t the classic approach be to delegate the privileged operations to a device driver or a system service?

    I.e. SQL server requires special privileges to access the data files, but end users don’t need any special admin rights to connect to the database.

  2. stupid says:

    "Unix and Unix-like OSes such as Mac OS X" … did  typing Linux hurted 🙂

  3. Since RunAs.exe won’t run a program elevated, is there a way to trigger an elevation prompt from a script?

  4. rwx---rwx says:

    > functionality like setuid/suid or sudo found

    > in Unix and Unix-like OSes such as Mac OS X

    and Vista Business, Vista Ultimate, and Windows Server 2008.  For previous versions of Windows Microsoft provided a separate download for Windows Services for Unix, but now it’s built-in.

    Maybe part of Microsoft made the right decision while part of Microsoft made the wrong decision, but I have a feeling that this is one case where customers probably don’t complain about being given a choice.

    > As computer security has become increasingly

    > important,

    As Microsoft has become increasingly aware of the importance of computer security,

    Really, I am glad that Microsoft is becoming increasingly aware of the importance, but why does Microsoft still think that operating systems didn’t exist before the creation of Microsoft.  Sorry this is getting to be a rant, but you know you provoked it.

    > Pre-approving code to run with elevated

    > permissions […] The “standard user by

    > default” vision would become impossible

    I think the opposite is true.  “Standard user by default” is still troublesome because of the inconsistencies and frequency of UAC prompts.  Now look at services.  If a service is installed to run as SYSTEM (or to run as the lesser-powered Administrator ^_^) it has the privileges that it needs, it doesn’t interrupt the user’s work, and it doesn’t discourage the advance of “standard user by default”.  A decision is made to trust the individual program.  The same kind of decision could be made when installing an individual program that runs on demand instead of running as a service, and it would provide even more encouragement to the advance of “standard user by default”.

    > any compromise could lead to full system

    > compromise

    Yes.  Just like with services.  In other words, take adequate care in programming and testing before deciding whether to trust.

    > How would future software for Windows be

    > written? Answer: To silently elevate.

    Make them noisy during installation time, and some users will still get the message.  (Other users won’t get the message, they’ll still click on LUA prompts to run viruses which promise porn, but we can’t do much about those users anyway.)

    > Privilege escalation due to setuid and sudo

    > has plagued Unix-like systems for many years,

    > and continues to do so.

    Yes.  No one has a monopoly on careless coding and lack of testing.  Let’s appreciate those rare birds who are allowed to work with diligent care.

    > “Nitpicker’s corner” might be a trademark

    Microsoft doesn’t have a corner on nitpickers.  Nitpickers were fixing bugs before Microsoft existed.


    re the importance of computer security:  More individuals and organizations are depending on computers for more of their critical needs than ever before, and their systems are under attack more than ever before by increasingly sophisticated criminals.  So, yes, I will defend my assertion that computer security has become increasingly important.  (And your assertion that Microsoft ever thought they invented the concept of the operating system is just silly.)

    re services:  Windows services offer one way to make elevated operations available to users, through controlled interfaces.  A significant difference between services and setuid programs is that services do not run interactively, and the user does not interact with them directly.  This allows the interface between the user and the service code to be defined with much tighter constraints.  If you were to have a setuid-type program that desired to expose a file-save dialog, that dialog could allow the user full access to the entire file system.

    — Aaron

  5. rwx---rwx says:

    services do not run interactively, and the

    user does not interact with them directly.

    True, the interactive part opens the client side of a named pipe and we need to prioritize code inspections of the service-side program more urgently than the client-side.

    Maybe we can say that for any situation where the "users"[*] would want a program to run with setuid, the application should be divided into two parts and one part should run as a service.  OK, I think I can agree that setuid isn’t really necessary.

    [* end users + administrators + managers etc.]

    ) (And your assertion that Microsoft ever

    ) thought they invented the concept of the

    ) operating system is just silly.)

    (You’d be amazed by the thinking of some of your colleagues.)

  6. megame says:

    Great article.

    I was hoping that explanation like this would be published by Microsoft along with release of Vista.

    There have been too many questions like: "why just does not Vista copy Unix/Mac security?" and part of your article is good answer to that question.

  7. Typical MS Partner says:

    One thing that I hear echoed is why isn’t there a set way for a program to detect at what level it’s running instead of just "try and fail". That doesn’t seem as well designed as if you have an api way to know if you can or can’t do something -vs- let’s try something catch the failure or force a admin dialog when we could be smart and not do it to being with.


  8. Christian says:

    What about COM+? Isn’t it easy to configure any COM-object to run evelated?

    [Aaron Margosis]  Out-of-process COM objects can be configured to run elevated, but you still get a UAC prompt before it occurs.

  9. Christian says:

    So I cannot have the parts of my programm that need to be run elevated as COM+-object and just use them?

    Vista will detect if a normal programm loads these components and will show the consent dialog and eiter terminate my programm or let it run?

    I thought that running elevated services with clear interfaces all the time wastes ressources and is visible to lots of users that like to remove useless clutter from their system.

    COM+ on the other side allows to do the same things as a service, but it will demand-start a dllhost.exe with my interface and code running elevated.

    What is the security reason? A service could do the same!

  10. Zen says:

    The important point missed in this feature is UI experience. After a while user habitually clicks on yes, making this whole exercise fruitless.

    [Aaron Margosis]  I don’t think so.  What you’ve called out is a potential problem, but what we’re expecting is that after a system has already been set up and apps have been installed, users will see few if any prompts, so each one should stand out and command attention.  I think the UI experience is actually not bad at all — it’s better than training users to reflexively type their passwords, as other systems do. 🙂

  11. While I understand where Microsoft is coming from as far as needing to break the cycle, everyone I have talked to about Vista immediately says, "turn off UAC and it will solve most of your problems." If everyone turns off UAC because it is so troublesome and there is no way for admins to make it do what they want, then the whole UAC exercise is pointless. There NEEDS to be a way for admins to configure programs to run with admin rights without giving the users admin credentials. At the end of the day, if UAC hinders business, UAC will be disabled. If it takes 3 lifetimes to figure out how to make UAC do what you want, UAC will be disabled. While it may sound like a responsible moral decision, Microsoft is no further ahead by trying to force this issue.

  12. Aaron Johnson says:

    I totally agree with Karl’s post…"turn off UAC and it will solve most of your problems."  It will.  I am having a terrible time transitioning our scripts, programs, software, and policy to the UAC environment.  I want to use the UAC, but it is going cause so much in-efficiency in our system, i don’t know how we are going to do it.  It think the UAC works well at home, but in our large enterprise, it is not working well with automated tasks.

  13. Aaron Johnson says:

    By the way, someone want to try testing something?  I think this is a problem related to the UAC.  I’ll give you my test scenario.

    Windows Vista Enterprise 32-bit

    Joined to domain

    GPO that runs a batch file that maps a drive (net use)

    Put a domain group in Administrators, put a different group in Users

    Log on the machine with a domain account in the Users group.  You should get your mappings.

    Now put a group (can be same group as in Users) in the Network Configuration Operators group. Now log on again with the domain user account.  Did you get your drive mappings?  I don’t.

    If I turn off the UAC then I do get the mappings.  If I take the group  back out of Network Configuration Operators, i get mappings.  For giggles, instead of adding the group to NCO I tried Power Users, and again no drive mappings.  Take the group out and drive mappings are back.  But the problem is not just the drive mappings, other programs do not work right in this scenario.

  14. John Grange says:

    Only one problem this whole #$%#$% is that the way you describe as the right way causes me to have to turn off UAC because it simply makes it impossible for me to run administrative tasks with my "Domain Admin account" I run Mac OS X as my primary OS and I’m sorry they got the escalate privileges right, it works, and doesn’t get in the way of doing your job.

    Currently on my new server 2008 I have two options, A) always run as the built in administrator because the built in file system can not promptly for more rights when needed, or B) turn of UAC. both options defeat the whole bloody point of UAC in the first place, so you tell me how they got it right?!

    If I am missing something please advise me, I would be glad to learn how to do things "the proper MS way". Right now I simply can not recommend 2008, its great idea, but poorly implemented.

  15. Rick Downer says:

    Here’s my problem. Users don’t have admin rights. App requires elevation – I can’t change that, it is what it is. So whenever the user runs that app they have to come to me to type the admin password for them. Either that, or I give the user the admin password, in which case I might as well make them an admin. Now, doesn’t THAT defeat the ENTIRE purpose of users no longer running as admins?

    [Aaron Margosis]  The idea is that apps to be run by users shouldn’t require admin rights in the first place.  Apps should require admin rights only if they are performing legitimate administrative operations.  Can the vendor (or internal developer) update the app so that it works correctly as standard user?  If not, there are many mitigations that can help get these apps to work correctly without admin rights.  (Which one to use depends on what it’s doing that fails, or why it’s demanding UAC elevation.)

  16. John C. Kirk says:

    The Symantec link has changed – that blog post is now at:


    [Aaron Margosis]  Fixed.  Thanks.

  17. André says:

    I'm using task scheduler to start applications autoelevated since Vista Beta2 and this works fine. So I can put a schtask shortcut in startup folder and they run elevated without any interaction.

  18. JML says:

    if wscript.arguments.named.exists("elevated") = false then

      createobject("Shell.Application").ShellExecute "wscript.exe", """" & wscript.scriptfullname & """ / elevated", "", "runas", 1


      'what you want to do with elevated rights

    end if

  19. jyao says:

    Vista is proved to be a bad release for MS, as is Win 8. A bad product does not necessarily mean every aspect of the product is bad, but quite a few are indeed bad. IMHO, UAC feature is bad when manipulated/presented in such a way by MS, yet, the bad decision maker(s) never get deserved consequence.

  20. kasajian says:

    sudo command for Windows, in just a three line batch file.


    [Aaron Margosis]  Umm… doesn't that just trigger a standard UAC elevation?

Comments are closed.

Skip to main content