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

[This item was authored by Aaron Margosis and originally appeared on his Non-Admin Blog.]

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 enable "standard user" to be the default for Windows, encouraging software developers to create applications that do not require admin.  The move to standard user is a new paradigm and creates the need for software developers to write applications that do not require admin privileges. Creating a shift in the ecosystem will take a long time due to the large deployed base of legacy applications, 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 (41)

  1. Nik says:

    That’s a very good and interesting summary.

    Personally I think a lot of the Unix vs Windows issues here are cultural. For example, in the Unix world it’s common for an app to create and install its own user (which may or may not be less privileged than root :-), which makes finer-grained control easier.

    With Windows apps, and we’re talking third party apps mainly rather than Microsoft’s own, services almost universally run as SYSTEM or similar. There’s often no reason why they can’t run as a dedicated user and/or at lower privileges, but the de facto standard (probably as its the easiest option) is to run admin.

    I personally think it’s good that you’ve taken a strong stand on UAC; I suspect that after a year or so of bickering the development community will catch up and everyone will benefit from least privilege by default.

  2. mpd says:

    Let me preface this by saying I’m a born pessimist.

    Personally, I don’t think UAC (or any other least privilege mechanism, for that matter) is really going to fix anything.  If you convince a user to install your software and the consent dialog comes up, they’re just going to hit OK.  It doesn’t really matter if it’s good or bad software.  Maybe at first they freak out a little and hit no.  Then they discover they can’t run the software.  They’re going to start again and hit “OK”.

    In the book, The Old New Thing, Chen relates a story about talking to a user who is upset because after repeated attempts he could not open an email attachment that Outlook had flagged as a virus.  If you tell a user not to run a program because it’s malicious and they run it anyways, how is anything like UAC going to help them?

    [Aaron Margosis] mpd, I’m a pessimist too, but do you really think that because you can find examples of users who will do anything to shoot themselves in the foot, that no one will benefit from UAC?  I can’t agree.  Furthermore, UAC isn’t just about putting a “Continue” prompt in front of privileged operations — it will also help enterprises (and parents) have their employees (and children) running as standard user and never needing to or being allowed to run anything with elevated privileges.

  3. Ben says:

    That is the best justification for the way UAC currently operates that I have seen so far. This may cause some inconvenience in the immediate future, but ideally newer software will work better with it. I do thing there are some things that could be addressed with its current implementation. Some operations seem to require far too many prompts. For example copying a file into a system directory first comes up with a prompt saying it will require administrative privileges, and then followed by the UAC prompt. This would be better wrapped into a single prompt.

    Before reading this article I also would have advocated having an option to allow a program to always be elevated. However I would instead settle for a feature that allowed me to temporarily disable UAC prompting (without rebooting) while I performed some system maintenance. While in every day usage the UAC prompt should not appear often, there are times where a lot of configuration is required (for example setting up new programs). I do find it tedious to have to click through many prompts.

    I am guilty of using a workaround when I am going to be doing several administrative tasks. I bring up a command prompt with elevated privileges, terminate explorer, and reload explorer from the command prompt. Now explorer is elevated and anything that it launches will also be elevated. When I have finished I terminate explorer again and reload it from a non elevated prompt. This is quicker than disabling UAC, rebooting, then re-enabling and rebooting.

    I would be interested to see if Microsoft would be willing to implement a temporary suppression of the prompt. This would be a non persistent setting that only lasted until the user reset it or computer rebooted. Additionally it could potentially be set on a timer. For example, suppress UAC prompting for next 30 minutes.


    [Aaron Margosis] What kinds of tasks are you performing that having Explorer elevated helps?  (If it’s unavoidable, you might want to review this post.)

    Suppressing prompting for a period of time runs into the same problems described above.

  4. Tired of clicking says:

    I have to agree with some of the previous comments in that there are just too many UAC prompts for those of us that work outside the user profile path. I fear that after a while, most of us will just wind up blindly clicking yes to any and all UAC prompts.

    [Aaron Margosis] What kind of work are you doing outside of the user profile path?  (This isn’t a challenge — it’s just a request for more information.)

    Perhaps as we get smarter we can tie a UAC prompt to some tangible evidence passed from malware, spyware, adware and virus tools running in the background?

  5. Karl.J says:

    so the user can only use code that has been allowed to run? who decides what can run if not the user?

  6. Nidonocu says:

    +agree with Tired of clicking. Giving the user real information they can understand in a prompt for consent dialog is critical to them making the right choice.

    Not everyone can afford a software signing certificate (and most users don’t notice the difference between the green, gray and yellow banners). But cheap app developers should be able to submit their software/installers to somewhere like Spynet so that Windows Defender can chip in on a UAC dialog using a file hash and say ‘this software has been rated safe and free of malware’. I would think such a thing might be expensive to organise, but the benefits would be huge.

    Otherwise I do agree with this article. UAC is a good start, but providing more information would mean Power Users who try new software all the time can take advantage of it rather than see it as a hindrance to their daily installs of new applications.

    [Aaron Margosis]  “Rated safe and free of malware” is not possible, and none of the UAC dialogs suggest anything like that — there is no way for any clearinghouse to determine whether there are any intentional or unintentional bugs/features in a given program that would allow undesirable actions.  If you’re going to run anything on your computer, especially with elevated privileges, you need to trust the publisher, trust the source that you received it from, and trust that what you’re installing has not been modified since the publisher created it.

  7. Yuhong Bao says:

    BTW, the fourth exploit listed can be exploited with UAC as well .

  8. from Me says:

    Look, I support forcing people to run a lower privileges and forcing a prompt for elevated privileges.  I do not think that Vista has implemented it properly.

    I use Linux extensively and have used Vista some.  But, what I don’t like about Vista is that a single install could require multiple UAC prompts.  If I decide to install the program and I verify my ID with my password, then the program should install.  I shouldn’t have to see UAC several times.

    [Aaron Margosis] Sounds like a problem with the installation package.  E.g., Office installs a bunch of apps, but prompts for elevation only once.

    Another thought is to split the control panel into two parts: one for non-admin tasks and one for admin-only tasks.  I frequently close and reopen control panel apps when I am trouble shooting.  It would be nice to use UAC to open the admin side, and then have the prompt suppressed for 10 minutes while I use various apps.  I wouldn’t mind reauthenticating every 10 minutes, but for every single app is a bit much.

    [Aaron Margosis] What a lot of people do is to launch an elevated command prompt, and then run elevated tasks from that command prompt.  (Running something from an already-elevated context does not incur another prompt.)  It requires knowing the command lines (e.g., secpol.msc for Local Security Policy), but that should be comfortable territory for a Linux user. πŸ™‚

    There needs to be a better balance between security and usability.  I support the security, I just think that the implementation uses a bit too much brute force.

    BTW, I looked at those links you provided from Secunia.  They do not support your claim that SETUID is dangerous.  All they said was that a competent and malicious user with physical access to you your box could possibly exploit a program and gain some elevated rights.  They were all labeled “less critical” and would take quite a bit of work to exploit.

    The fact is that with physical access, I could exploit just about any box.  Few systems are safe when a malicious user is at the helm.   UAC is supposed to stop non-malicious people.  Isn’t that correct?  So let’s not throw FUD and make UAC easier to use.

    [Aaron Margosis] I think you’re misinterpreting the Secunia stuff.  “Local elevation” does not require that the attacker have physical access — it just requires that the attacker get code running on your box.  A browser exploit will work just fine for that.

    Let’s make UAC easier to work with and then people won’t circumvent it.

  9. The every day user says:

      Dont you yhink that this might be to large of a feat. it seems like you should be puting more thought into the concerns of the user and less into your plan of changing the world of computing.

       i am continuesly frustrated at how vista’s security works. and frankly i could’nt give a rats ass about how you hope to change things, i just want my programs to run when i tell them to run not be forced to endure your "great" ideas for changing the way programers program.

      Microsoft has failed its every day user community. i have used windows all my life.  gamming is my passion as well as my favorite pass time and having to dig through submenue after submenue just so my game can access the servers the preducer hosts is someing id much rather not do because of what you think you can do for the world by providing overactive security

  10. from Me says:

    One other thought….

    It is not right that Microsoft has been forced to implement Draconian security.  In my opinion, MS should provide the security and allow users to configure it.  

    While I understand that MS has it’s hands tied over this issue and I understand that many security gurus are insisting that MS protect end users from themselves, that whole concept is ridiculous.  

    Given a toss up between an evil internet and a heavily controlled safe internet, I would take the evil one every time- not because I do malicious things, but because I am opposed to the concept that others must protect me from my own stupidity.  If people won’t secure their computer, fine them with civil penalties.  Whatever. (I don’t use AV and I run virus free in XP because I operate securely.)  Don’t force me to operate on someone else’s terms just because others are to lazy to understand this stuff.

    It’s certainly a trade off, but I am in favor of options for the consumer, not forced regulations.

  11. digucit says:

    This post was published to digucit space at 03:24:38 27/08/2007

    UAC and the secure VISTA…not


    sitting here with 2601 viruses detected so far by f-secure, I am trying my best (but after 48hrs of scanning and trying all manner of approaches to gain access to My pc) I  have to question this UAC policy , The reason for this is simple if like me you have managed to get a virus, the one in question is some variant of the RONTKBR.GEN,  I contracted this back in April and wrote a few reports back then but I was ignored, I managed to quite easily remove it that time. But now I have a much scarier version, which will NOT allow regedit, nor a notepad generated key to be written to reg.  Will not allow any *.exe to be run, or down loaded,   effected files can be detected by Trend housecall, Symantec, f-secure, but they are failing to remove/clean the files.

    The files that you need to kill/rename/delete and their paths are shown by the scan engines but they are cloaked when you look for them using the dos prompt.

    Your files show hidden option is disabled….and you are running with no rights from the admin, so you can not open the user control panel and disable the Admin account security settings.

    Oh yes and it shuts down if you try anything that might cure it, like certain websites and blogs

    Windows Defender gives the pc a clean bill of health (where do I get a refund) and

    The Live OneCare vista scan sees something, and then fails to cure it after HOURS

    So in all 48 hours later I am eyeing up my old win95 WITH ENVY

    PC is 2.8 dual core p4, with 300 GB main, 200 GB sata, 40 GB sccsi

    VISTA ultamite

    2 GB ram plus 4 GB ready boost usb

    256mb geforce6800 dual DVI with two screens…. as pictured on my spaces.live

    The point is that UAC and work around from boot etc, allows me to be locked out of my machine, I can run the regedit if I run command prompt from a boot/install vistaCD…cancel…see options..Fix

    But the information the scanners see in the registry are not present in the registry I can see from booting to X virtual drive

    I know that somehow this thing has created a User account and put my name on it. However this is the strange thing.

    When the p.c boots is goes okay to the welcome screen and then complete blank desktop loads, no icons nothing,

    You have to do ctrl alt Del to then load task manager

    I then instruct it to run iexplore.exe, and then for the tools menu I select view files to get the file explorer launched, then I must navigate to the PUBLIC folder and select any of the folders and click inside then on the sample or the exe file it has created, like music.exe

    The minute I click this hey presto the WOW kicks in

    I suddenly get back my desktop and can see use all programs, but cannot do anything that requires Admin rights.

    So there you have it, UAC + some smart kid makes MY vista so secure that I cannot get into it without climbing over all the backyard fences and sneaking in a window, but then I can’t make a noise or I get kicked out


    The same bug is in an xp laptop, and again has stopped any regedit/hidden files, but I suspect this will be easier to cure.

  12. digucit says:

    This post was published to digucit space at 04:03:05 29/08/2007

    The cure…….after 72 hrs….4 gallons black coffee…

    Not to leave you all hanging in there wondering if I ever got my Vista Back from the dead, I am pleased to say that I have but no single thanks to any one company as the all had a failing in one area or another.

    Remember the challenge, no regedit, even from F8 boot or false reinstall

    Administrator denied access to run, no desktop, no folder view, no local polices, reboot on trying any of the above or visiting certain websites.

    All this hassle over two simple digits 1&0

    One would think that in a cold boot F8 dos prompt that one could control the machine.

    I could rename regedit to regedit.com but could not use the RUN command to open it from command prompt…….

    The offenders in the end were (there are a few because I suspect the signature file presented itself different to varying virus scanners.




    Brontok A

    The cure was as follows

    Housecall.trend could remove the infected files but could not stop the processes, nor could I.

    F-secure was able to remove virus but not stop re-infection

    But it did at least allow .exe files to be loaded,

    This allowed AVG to run and kill virus

    But the Admin and regedit remained blocked

    The antibrontok tools from Bitdeffender restored registry access

    And the good old manual resetting of folder view, and superhidden values returned Both PCs to a working state

    [Aaron Margosis]  If malware has been able to run at system/root level, you have no assurances that you’ll be able to detect the infection, let alone remove it.  The integrity of the trusted computing base (TCB) has been compromised at this point, so no information you receive from it can be trusted.  Well hidden malware can also often find ways to hide even when you boot into a separate trusted OS (e.g., from a CD) — that’s assuming the BIOS itself hasn’t been 0wn3d.  BTW, this isn’t just a Windows issue — the same is true of Apple, the *nixes, OS/2, etc.  One of the big reasons for running as non-admin is to protect the integrity of the OS.

  13. Steve says:

    The idea of prompting an administrator everytime he needs to do something is ludicrous.  If I’m logged in as administrator, I should have the keys to the kingdom.  If I’m not competent to make decisions about which programs I run and what processes I perform, then I shouldn’t be logging in with administrator privilege.  Please give me the freedom to shoot myself in the foot on my own computer if that’s what I want to do.

    [Aaron Margosis] If it is your computer, you already have the freedom to shoot yourself in any way you want.  You can set the elevation prompt behavior to “elevate silently”.  You can disable UAC completely.  You can reset access control in the registry, file system, DCOM launch permissions, etc., to grant Everyone “Full Control”.  Godspeed.  But we’re not going to make that the default for everyone else, OK?

  14. Dave says:

    As an IT guy, I absolutely agree with Steve above.   If I want to shoot myself…let me!   It is my responsibility to secure my systems against viruses, spyware, spam, etc. with the best tools possible.   This issue and others have kept us from upgrading to Windows Vista…we remain at Windows XP Pro and Windows 2003 Enterprise Server.

    Microsoft, if you want to do me a favor, have your security capabilities configurable by the administrator.   That is, allow the admin user to install “trusted software” without the prompt.   The admin can supply a list of “trusted” software apps that don’t require the UAC prompt.   If the app is not trusted (yet), allow an option to make it trusted from here on out.

    [Aaron Margosis]  Dave, my apologies if I sound flip, but did you read the post?  In a perfect world where software (and software engineers) truly possess magical powers, what you’re asking for would be great.  But as detailed in the post, it would ultimately harm customers/users more than it would help them.

  15. Another Dave says:

    Quote: But as detailed in the post, it would ultimately harm customers/users more than it would help them.

    Not as much as having to turn off user access control entirely just to run an application as administrator without typing in a password every time. Much as I applaud your efforts to avoid security pitfalls, if the alternative to a user unfriendly nagging prompt is no security whatsoever, then people will settle down with no security and we end up exactly where we began.

  16. Beau says:

    I cant agree more with UAC in its current form, i’ve found it to be useful and i think this approach is something that has been coming for a long time.

    From the responses i’ve read here most of the people posting are either system administrators or home administrators… not base users. The point of UAC is to stop base users from doing things they shouldnt be, it does its job brilliantly, with a world that is quickly becoming internet dependant with more virus’, malware and spyware out there it makes more and more sence to rely on the "least priv" rule where a base user has no rights to change system settings it makes sence when you stop thinking about the system administrator’s perspective, and look at it as a user.

    A user is more likely to visit a web site that contains malware/spyware than an administrator (perfect world) and they pose the greatest risk on a network where if a virus infects one machine there is the chance that multiple machines would be effected aswell. With a user (base user) being prevented from running code that has not be authorised on the network by a PERSON this results in a greater control over what code is running around, less chance of virii and a greater productivity.

    The argument of "disable UAC" to use legacy applications is garbage while i have come accross the problem myself, it is preferrable to me that a program that may not be coded correctly be prevented from running, be it because the program puts temporary files in my system32 folder, modifies my host file, or inserts hidden files into locations that it really shouldnt. It is an argument that i’ve had with programmers many many times where they require DLL’s be placed into system/32 folders to allow their programs to run… portability of applications suggest that you have all the required files in the install folder of the application itself, using the system’s preinstalled files if required, not put new files into a system specific file. Doing this would remove the need to UAC Authorise to put files into the system folders… problem solved with smart programming.

  17. Dan from Redmond says:

    Unfortunately UAC prompts for not only “risky” tasks, but also for the most MORONIC reasons.

    Case in point.

    I am a user. I attach a USB hard drive or key to my system, and proceed to copy files TO MY HOME DIRECTORY. Why the hell would UAC prompt for this?

    [Aaron Margosis]  It wouldn’t.  Either permissions on your home directory are messed up, or something else is going on here.  But copying files into your Usersusername folder should not trigger a UAC prompt.  (Are you sure it was a UAC prompt and not something else – like “are you sure you want to overwrite xyz”?)

    I want to copy, or move files from my USB attached devices. Again, same prompt. If it was copying or manipulating the home directory, thats one thing..but this…

    appdata virtualization is also a complete mess. If I want to look at data files stored by my apps, or edit application installs, where do I look? program files is not enough..Now I need to go look at appdata, and its myriad subdirectories.

    [Aaron Margosis]  OK, but you realize that allowing apps to store data under %ProgramFiles% presents serious problems, too, right?  I for one think that what the UAC guys came up with is a very reasonable solution – and I can’t think of a better way myself.  Apps that store data in user profile folders (as they should) are not affected by virtualization.  Also, if you use Windows Explorer and browse to a folder that contains virtualized files, you’ll see a “Compatibility Files” button in the Explorer toolbar that will take you right to the folder where the virtualized files went.  Pretty cool, IMHO.

  18. Ben says:

    Hi Aaron, In response to your question about what tasks I need explorer elevated, the answer turned out that I didn’t need explorer elevated. I just used it as a convieneint way to launch other apps that are now elevated.

    The times I want to be able to have UAC temporarily suspended is when I want to perform a lot of admin tasks in a row. For example installing a bunch of apps.

    I have found a happy solution though since I first read this article. I now have a registry file that sets "auto consent" on. This does exactly what I wanted. I only have to answer the prompt once for that and then I can perform all other tasks with elevation occuring automatically. When I am done I set the setting back.

    While I will agree that having this temporary auto elevate on does expose the system somewhat. It is a risk I am willing to take. And while I have the computer in this state I am not running my web browser etc.


  19. CS says:

    I tried, I really did, but I’ve come to the conclusion that UAC is a "good idea" only because it had good intentions.  It’s poorly conceived, poorly designed, and poorly implemented.

    And it doesn’t really help security much: in practice, it just moves the burden to users, who are inconvenienced without being given enough useful information to make sound decisions.

    Don’t confuse the benefit of running in a lower-privilege account with a need for UAC.  As several have pointed out (and as I’ve seen), prompts just guarantee a response, not necessarily a correct response.  (Begging the question by saying "Well, it helps users who are smart or careful" goes back to usual engineer’s defense of pushing the problem to the user, doesn’t it?)

    And boy, is it annoying.  In my case, administering 3 different Vista machines for various users at home, I figured it was proper to leave UAC on.  But dang it, some programs just don’t work right with UAC, and not for any good reason, either.  (File backup with Robocopy, file edit with Vim are two examples.)

    Any don’t give me any crap about finding better ways.  I’ve been working in software for about 30 years now, so let’s say I know how to figure things out.  I spent several hours on microsoft.com and various other websites to find a solution that would work.  After a point, the elusive benefit of UAC just doesn’t pay for the effort.

    I know, the Microsofties will keep telling themselves and their friends that Vista is almost a wonderful thing, or at least a "step in the right direction".  The rest of us grow increasing sceptical about where those steps are leading.

  20. verm says:

    Try to download an EXE from the web.  How many warnings do you see saying that what you download could be malicious?  (including the yellow bar at the top of IE6 SP2)How many of those warnings are people so used to seeing that they simply respond "yeah yeah whatever – click"?  Now add a new warning at every new generation of the OS and/or browser.  How long before it becomes a "yeah yeah whatever – click" ?

    I’m not saying UAC is a bad idea.  I like it. I feel it protects my system, however rarely it may come up.  It’s not my system I’m worried about, it’s my 70-year old dad’s.

  21. Jamie Gordon says:

    Implementation of security in any OS is the responsibility of the user.  Microsoft, governments etc. seem to believe that their role is to interfere where I believe it is to carry out the wishes of the group. I would advise a look at the history of past totalitarian regimes, all have failed, as will Microsoft if they do not produce an OS for adults.  I will now load W2K on my brand new laptop.

  22. Joshua Hudson says:

    I am a software engineer facing a strange thing. Our software works just fine with UAC off as an admin or limited user. Turn it on and it doesn’t work, admin or limited doesn’t seem to matter.

    But the worse issue is this. If it is on during the install, even if you explicitly elevate the installer, the install fails, and wedges itself so that even uninstall and reinstall with UAC off fixes it. Therefore I have been asked for a programatic way to disable UAC that will stick without reboots.

    The problem is not admin vs. limited at all. UAC itself is the problem.

    [Aaron Margosis]  That sounds very unusual — have you gone in with a debugger to identify the specific failure points?  Feel free to contact me directly through the contact link on my own blog,

  23. dnm says:

    I am writing as an end user, a gamer, rather than a security person. UAC prompts way too much. I agree with CS, it’s incredibly annoying. If a user want to lower security allowing a program to run again that still has the same checksum I think that would be a good compromise, but only if the user uses the extra checkbox for that. What happens now is that users get fed up with the constant nagging from UAC, and disables it. Example: at one time I had two applications that wanted to elevate at boot:last.fm and xfire. I have password on for UAC as well. So writing passwords three times at bootup got me extremely fed up with UAC. I really felt the Mac Ad was right on the dot. Now last.fm introduced an extra service in order to avoid elevation every bootup. Xfire guys refuses to do that, so if I didn’t change the config for some games (in fact disabling xfire support for those games) I would  still get an UAC prompt every boot.

    <rant mode="on">

    Now the extra service makes me think of startup programs which I really hate. I don’t need the machine to boot up any slower, it boots really slow now, since every developer seem intent on sticking an extra process in startup.


  24. Ray Coleman says:

    There are something i can not download that i know are safe. How do i bypass this security to download.

  25. toad says:

    I for one run as a limited user on both XP and Vista. I like UAC. The one problem I see is that to elevate requries knowning another (administrator) account’s password. If I know this password, then there is nothing preventing me from just logging in as this administrator to begin with (at least on Home versions).

    What I have done then to protect my admin account (at home at least) which should virtually never be used for anything is to create a new group called "Superusers" (only an admin can add users to it) and a service called "Superuser Manager" – when the service sees a member of Superusers group (like my limited user self) log on, the service adds me to the administrator group (so, now I am in both Users and Administrators groups). So, desktop explorer is running as a limited user and when I run something that requires evelated rights, UAC prompts and behold my user self is in the list and I can enter my OWN password to elevate the program. When the "superuser" logs off, they are removed from the Administrators group so the logon/logoff process can be repeated. This whole thing works on XP as well and 2000 (not with service though) and you can Runas to elevate essentially.

    The only thing I wish I could do is "hide" the real admin user from the UAC dialog completely… There seems to be no way of having administrator accounts that never show in the UAC list…

  26. Hal says:

    TweakUAC (http://www.tweakuac.com)

    Runs on Home/Home Premium, removes the @#$% repeated escalation prompts.

    The alternative is disable UAC completely, which defeats the purpose.

  27. Russ says:

    By not providing setuid capability, you have forced us back into using administrator accounts.  I’ve got a custom h/w + s/w solution that requires admin privs to run.  I’d like to setup a non-admin user account, and give admin privs to the custom app only.  Since that is not possible, the only solution is to use an administrators account.

    [Aaron Margosis]  Another option:  figure out why the app requires admin rights and address that problem.  Is the purpose of the app to do computer administration?  If not, then the app shouldn’t require admin rights.

  28. Russ says:

    [[Aaron Margosis]  Another option:  figure out why the app requires admin rights and address that problem.  Is the purpose of the app to do computer administration?  If not, then the app shouldn’t require admin rights.]

    One of the apps is a control panel applet, which accesses a device driver via an ioctl interface and writes to the registry.  Should this require admin rights?

  29. Tyler says:

    Does that type of object have an ACL?  If so, the device driver ought to specify whether a user is able to open it.

    Writing to the registry is a question of where, and what.

  30. Denny says:

    Microsoft never wins.

    People bash them thinking their products suck because Windows started crashing or their system is plagued with Adware. They don’t realize they actually did it to themselves. The only thing Microsoft is guilty of is making computers way to easy to use.

    Now Microsoft comes up with a potential patch for stupid people and now they’re bashed for nagging people to death.

    I’ve been a Windows System Admin for the last 10 years and can’t count the number of times I’ve had software vendors tell me I have to make my users local admins in order to run their software. I can’t count the number of times I’ve ran RegMonitor and FileMonitor to figure out what permissions to tweak to make their poorly written software run under user credentials.

    For all of you bashing Microsoft, go nag the producers of the software you are trying to run and demand they code to accepted industry standards.

  31. Tepid says:

    [quote] Microsoft never wins.

    People bash them thinking their products suck because Windows started crashing or their system is plagued with Adware. They don’t realize they actually did it to themselves. The only thing Microsoft is guilty of is making computers way to easy to use.

    Now Microsoft comes up with a potential patch for stupid people and now they’re bashed for nagging people to death.

    I’ve been a Windows System Admin for the last 10 years and can’t count the number of times I’ve had software vendors tell me I have to make my users local admins in order to run their software. I can’t count the number of times I’ve ran RegMonitor and FileMonitor to figure out what permissions to tweak to make their poorly written software run under user credentials.

    For all of you bashing Microsoft, go nag the producers of the software you are trying to run and demand they code to accepted industry standards. [quote]

    Absolutly dead on right.

  32. Tepid says:

    I wanted to add,

    We had a couple of vendors tell us they weren’t going to recode for Vista, and to either run as a local admin with UAC off or don’t use thier software.

    We aren’t using thier software.

  33. Golan says:

    I´m still running XP Pro cause UAC sucks.

    Every time I try to run an app, UAC ask me if I want execute it. If I trigger the exec, let me do it.

  34. Khanh says:

    My app is a server/client application that replicates project files from the server on every startup. Now I am forced to limit the project files to USERS/PUBLIC? That would be kind of "ok". Default Project Directory is already %allusersprofile% or something, so I just tell my customers "you shouldve used default, lol".

    So, everytime I update my server, the clients (who run as user of course) automatically download the update. But under Vista they can’t install it, because they can’t write to their directory. So does the admin have to visit all 500 Workstations twice a day to enter his credentials so the application can update itself?

    I can’t tell my customers to disable UAC or change Vista default settings to run my app.

    So am I forced to install my application under USERS/PUBLIC too? Or better yet, install under "program files/bla" and set read/write access to everyone? Or tell my customers "my app only works as administrator and even then fails sometimes"?

    That would render UAC totally meaningless. If the only way to make your application work properly with Vista, is by AVOIDING any restricted (and protected) directories, whats the point of having them?

    Only workaround I’ve found so far is this one:


    But that’s more of a hack. It’s about installing a system service that waits for a custom command, then uses the winlogon.exe token to start your application as elevated. Any malware that knows this backdoor is present can elevate itself. Of course you can keep the custom commands secret, but thats just security by obscurity. Shouldnt be too hard to intercept the commands, either.

    Anyways, what I need is a flag for my app that says "If this .exe wants to, it can elevate itself without admin prompt, even if logged on as user".

    And for setting this flag you’d need to be an administrator, of course.

    I don’t mind installing the application once and clicking my way through the prompts.

    But I, or rather my customers, do mind the other 1500 days that I would have to visit every workstation.

  35. Khanh says:

    And by the way, about this whole “user will not get used to the prompts thing because after a while there will be fewer”:

    User loads something from the intarwebs, double clicks and gets “hey this could be potentially dangerous, are you really sure you want to run this and and do you know exactly what you are doing?”

    What does he do? Just not run the application, shut down his computer and go play in the garden? Ask his “administrator” about it who can look at the filename?

    If it was something detectable by antivirus, antiadware, windows defender, whatever, they would’ve popped up already and denied access, right?

    How the hell can the user know whether the app is dangerous before he has even ran it?

    He can’t.  He has no way. So he will just click yes.

    [Aaron Margosis]  Rather than simple file copying to update the app, take advantage of MSInstaller capabilities:  if an admin installs an app that is signed by a trusted publisher, updates to the app can be installed by a standard user if the update is signed by the same trusted publisher.  Another alternative would be for the app to be installed in the user’s profile rather than a machine-wide profile.

  36. Khanh says:

    Thanks for the fast reply.  Really appreciate it. I was always unsure whether .msi files needed administrators to verify. Does the standard user see the "ARE YOU SURE YOU WANT TO INSTALL" prompt for minor upgrades? Or is it possible to make the update sneakinstall itself?

    Another thing is, I can’t install it per user. I thought about that. Advantage would be that other users can’t access that directory, malicious code ran from other users couldnt destroy it. But that is also a drawback, because with 10 users on one workstation the load on the server would grow too much if they logged in one after another to get the update.

    Also, I used to be able to update my program directory "on the fly". My program directory has a folder with some .dll’s in it, which have to be distributed to the clients. You install em on the server, clients immediately replicate. I guess I will have to move everything to USERS/PUBLIC for full write access.

    Yes I may sound pessimistic, but you always have to expect the worst from the users/customers and be prepared. They could go online with all workstations at once, switch users at once, etc.

    I know that MS has been saying for years "design your applications so that standard users can run them without problems", but end-users have always used administrator accounts under XP. There was never a reason to rethink the concept and lose valuable  time to gain de facto nothing.

    But now we are FORCED to comply. Because the default security level is so high, we can’t tell the users to change system settings.

  37. kurt says:

    hello I have a problem using Windows Vista since the last update of program gives me this error when trying to connect to a server (Xfire requires UAC elevation to run the game)

    someone knows how I fix am from spain and I use a translator to write I hope that I understand.


  38. ElCarso1 says:

    UAC, another thing that makes Windows harder to work with.

    It seems that something must get worse, harder to work with, with new versions.

    Sure, many things was better with XP compared to earlier versions, but in som areas I did experience a clear falling off.

    With Vista things became even worse.

    I installed Vista for the first time during the spring, tried to work in it (I’m a developer), tried really hard (convinced that it’s just a matter of time and to get used with it), but I just couldn’t do it.

    Now I’ve gone back to XP and I’m able to continue doing my work without having an annoying and downright stupid "big brother" hanging over my shoulder telling me completely unnecessary things.

    I’m still forced to switch to Vista from time to time for testing purposes; but I keep UAC off, otherwise it’s hell.

    Unfortunately what I’m developing right now is an automation tool (an application that reads instructions from text files and executes them), which it is very useful and can make life easier by speeding up routine jobs and by eliminating the risk for human errors (always present when manual handling is involved).

    Computers are here to make things quicker and easier for us, not slower and more complicated; and one big opportunity is made available through automation.

    Automation means that you write down what you want to do in the form of instructions (it may be quite complex tasks which normally require hours of manual work).

    Then you test everything, and then you save the file and create a shortcut to it.

    From now you can forget all the details of the job to do, you can forget all all the manual struggle, you just do everything quickly and safely with a single click!

    It is now clear that UAC is the number one enemy of automation.

    The purpose of UAC should be to prevent people from doing the wrong things, but it goes far beyond that. It prevents people from automating their tasks, consequently preventing people from making their work more productive.

    All of this because of the incredibly retarded idea behind UAC, treating us like idiots incapable of taking a single step without supervision of mister know-it-all.

  39. Luis Marrero says:

    [Aaron Margosis]  If malware has been able to run at system/root level, you have no assurances that you’ll be able to detect the infection, let alone remove it.  The integrity of the trusted computing base (TCB) has been compromised at this point, so no information you receive from it can be trusted.  Well hidden malware can also often find ways to hide even when you boot into a separate trusted OS (e.g., from a CD) — that’s assuming the BIOS itself hasn’t been 0wn3d.  BTW, this isn’t just a Windows issue — the same is true of Apple, the *nixes, OS/2, etc.  One of the big reasons for running as non-admin is to protect the integrity of the OS.

Skip to main content