UAC - What. How. Why.
- Posted: Mar 05, 2007 at 10:40AM
- 60 comments
There has been a large amount of confusion and concern out there about Vista's new user security model (Everybody runs as Standard User, a new user account security construct, UAC, acts as gatekeeper of process security boundaries - a doorway to process
security context elevation).
Users should be in control of what executes on their system under Admin (full trust, highest privilege) context. User Account Control was created to enable users to prevent or allow a process to run in an elevated way (which simply means that the process can successfully execute code that can do core system operations).
In this interview we tackle UAC from various angles:
1) What problems does UAC attempt to solve?
2) How does UAC actually work?
3) Why did we implement UAC UI to be so aggressive, from a user experience point of view?
4) How will UAC evolve?
Here, Jon Schwartz, UAC Architect, and Chris Corio, UAC Technical Program Manager, discuss, in detail, the history of UAC, the architecture and design of UAC, the new security model of Vista (we are all Standard Users (gone are the days of running as Admin by default on Windows), what happens when a UAC security dialog is invoked, how UAC impacts developers, how UAC will evolve...
Enjoy this latest episode of Going Deep.
Users should be in control of what executes on their system under Admin (full trust, highest privilege) context. User Account Control was created to enable users to prevent or allow a process to run in an elevated way (which simply means that the process can successfully execute code that can do core system operations).
In this interview we tackle UAC from various angles:
1) What problems does UAC attempt to solve?
2) How does UAC actually work?
3) Why did we implement UAC UI to be so aggressive, from a user experience point of view?
4) How will UAC evolve?
Here, Jon Schwartz, UAC Architect, and Chris Corio, UAC Technical Program Manager, discuss, in detail, the history of UAC, the architecture and design of UAC, the new security model of Vista (we are all Standard Users (gone are the days of running as Admin by default on Windows), what happens when a UAC security dialog is invoked, how UAC impacts developers, how UAC will evolve...
Enjoy this latest episode of Going Deep.
Comments closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.
Follow the discussion
Oops, something didn't work.
What does this mean?
Subscriptions allow us send you email notifications when new content is added. You need to be signed in to Channel 9 to use this feature.What does this mean?
Subscriptions allow us send you email notifications when new content is added.sign up for email notifications?
I really don't understand why there's been this backlash about UAC. Something had to be done, and UAC is I think a very pragmatic and yet elegant solution. Sure at first its a little shocking - but the truth is, even as a developer, that once you've reached a steady state and your machine is broadly speaking configured with the various tools and packages you need to create code etc then the number of secure-desktop prompts you encounter falls away dramatically. To the point that I definately **feel** more secure under UAC. I get a real sense of comfort knowing that I'm not being to be led into letting some bit of malware run off with the system.
The only thing I have done is to enable the capital 'A' (legacy) administrator account so that I can occasionally launch a PowerShell instance in "XP security backwards compatibility mode". And in almost all cases that's because of some batch tool that does have a manifest to prompt for privilage elevation build in. Nope, UAC is a Good Thing - more of the same please.
On XP members of both Power Users and Administrators can share folders on the network. The same appears to be true on Vista, but only if you create a custom MMC snap-in, as the 'Share...' context menu item insists that you must elevate to a full Administrator account (both with and without the wizard). Is there any workaround for delegating the right to share folders to standard users, or at least to make the experience a little less odd for members of the Power User group?
The other (minor) annoyance is the way Journal bugs you to elevate to add the printer driver every time you start it until you finally let it. Grrr.
Overall though, the UAC implementation is really well done and I'd congratulate everyone who worked on it as you've done a great job of making my job (a sys admin) a whole lot easier!
Same here.
I've been selling Vista in the following order:
1. Security
2. UAC
3. Reliability and diagnostics
Bear in mind that I'm pushing this at people who are complete non-geeks.
I'd upgrade to Vista right now too but I need all the Vista-equivalents for my Media Center features (Remote Desktop, EFS, Media Center, Movie Maker, etc.). So I have to save up for Ultimate.
A big part of what makes UAC suck is the modal dialog box. People filter out modal dialogs eventually and just click through them regardless of the messages. The more they have to click through, the more they will.
UAC is the boy who cried wolf.
There is one "feature" in UAC. What I did:
- disable UAC ("during PC initial setup")
- change location of "default" folders such as "Documents", "Downloads", "Pictures" etc
- enable UAC
My "first 60 seconds" after reboot - one big, no huge, "BLOODY HELL!". Why? Because UAC disabled access to new locations of "default" folders. I've lost access to the "Pictures", Outlook lost access to messages, etc. I had to adjust security for each folder - take ownership and give "full" permissions for.. ME. But even after this UAC prevents access to some places (no prompts, just "you don't have permissions to..."). After 1 hour of the battle I've just disabled this "feature" and misteriuosly I've got access to all folders and files. It was just one of the reasons.
The Power Users group is deprecated, the only reasons it's still there is for (wait for it) backwards compatibility (even says so in the group's description). You shouldn't be using it.
BlackTiger: I could move those folders without even needing to elevate, so I don't know what you're talking about.
EDIT: Or perhaps you mean that you could change the location but couldn't access them afterwards? That can happen if your account doesn't have the necessary rights to the new location. But that's not UAC's fault, it can happen on XP too.
The people who complain are what folk who tend to endlessly install and deinstall software, drivers etc. Tinkerers basically. And I can see how the UAC would be a bit of a pain for them. And tinkerers are alos the same sort of people who will hang around in forums, complaining a lot (not that there is anything wrong with complaining if you don't like something). So this is why the UAC problem looks a lot bigger than it actually is.
Your average Windows user does not spend much time configuring the system after the first few hours setting it up and installing software. The majority of users won't see it very often.
So (I'm not MS employee!), please tell me why I have this problem ONLY IF UAC IS ENABLED. This problem disappears if UAC is disabled. WITHOUT ANY ACTION RELATED TO FOLDER'S SECURITY.
Oh, I know that. It's just that putting someone in the Power Users group does at least allow them to share folders, albeit after jumping through a few hoops.
There should be a cleaner way to delegate that right, I just can't figure out what it is.
I'm only guessing because I'm not psychic, but with UAC enabled a user doesn't have access (without elevating) to folders where the Administrators group has access even when that user is a member of the Administrators group. Either the Users group or the user personally must have access rights to the folder.
I do think UAC is a good and needed thing. It's clear that running as an admin all the time is dangerous.
What I don't undertand is why or how come changing your system DPI is so risky for your sistem that only administrator can do it? What was the criteria used to rate it so dangerous?
Atte:
Raptor
Jonathan here (the guy from the video) to answer some of the questions that were posted.
BlackTiger:
The issue you hit isn't actually related to UAC. The problem actually involves a subtlety with running elevated combining with the method you used to change your configuration.
When you're running elevated (either as a member of the Administrators group with UAC turned off, or after going through the elevation prompt with UAC on), any directories/files that you create are owned by the Administrators group, rather than your user account. When you relocated the directories, you had UAC turned off so the ACL was set in a way that granted no access to your user account directly (i.e., you had access via membership in the Administrators group). When you turned UAC back on, you were then running with a filtered, non-admin token and as a result, had no access to the directories that you had created when you were running elevated.
That's also why you only see the issue when UAC is enabled.
JChung2006:
The modal dialog behavior (or rather, switching to the secure desktop to display the elevation dialog) is actually configurable by policy. If you want to switch it off, simply do:
Start
"Local Security Policy" (launches secpol.msc)
Local Policies --> Security Options
Select "User Account Control: Switch to the secure desktop when prompting for elevation"
Change the policy to "Disabled"
Note that you'll need to explicitly launch secpol.msc elevated (via right-click + "Run as administrator...") if you're running as a standard user. The policy change will take effect immediately.
The huge caveat here is that turning off this policy exposes you to UI spoofing attacks that target the elevation dialog (e.g., overlaying different text, or a different dialog image entirely, on top of the elevation prompt). This becomes possible once the elevation dialog is displayed on the user desktop.
--Jonathan
It's not just a matter of risk. You have to remember why standard users were created originally: to restrict people from modifying system wide settings in a managed environment (e.g. corporate network). The fact that this also provides security from malicious code is a side benefit that was probably not even originally intended, and has only become important in recent years.
UAC builds on the existing separation between administrators and limited users. This works in two directions: it provides both an easy way for limited users to perform administrative tasks (instead of a simple "access denied" the can respond to the UAC prompt provided they have the password) and it protects administrators by not having them be administrators all the time. Basing UAC on this makes sense because it builds on existing and proven security mechanisms (ACLs, policy mechanisms, etc.) rather than invent something completely new.
It does however mean that UAC will prevent a non-elevated user from doing anything that a limited user wouldn't be able to do, even when it isn't strictly security related. Deleting a shortcut from the "all users" start menu doesn't pose a security threat, but it does affect all users of the machine so in a corporate network you probably don't want to allow your users to do it. Same goes for the DPI settings. These aren't security risks per se, but they are actions a limited user can't take (for good reasons), thus UAC will prompt you for them.
In some cases you can actually work around the restriction. If you want to delete shortcuts from the "all users" start menu without getting prompted, change the ACL so you always have access. To change the system time without a prompt, set group policy so that limited users have the right to change the system time. This isn't possible always though, but I think having to press "allow" to change the DPI settings (let's face it; how often do you do that?) is a small price to pay for the security of running as a non-admin.
Sometimes not enough information is presented for me to be able to make a decision on whether to allow the operation or not. Some of the names are quite obvious (e.g. when doing file operations), but what I'd prefer to see is an "advanced" version of this dialog detailing:
Agreed, unfortunately number two would be very hard to implement. An UAC prompt unfortunately means they can do everything after you permit them. Determining what they're going to do is nigh impossible to determine by static analysis. In order to get around that you would need a system where an application requests only those permissions it needs and will get no more (like CAS in .Net). The only problem is that installing such API level protection on the existing Win32 API would be a massive undertaking (as if Vista wasn't late enough already
The last item from that list is already there; the UAC dialog won't list the publisher's name unless the executable has a valid signature from that publisher. Why it's not a link like on the "are you sure you wish to execute this" box that was introduced with XPSP2 I don't know (probably has something to do with displaying that information while in the secure desktop).
What I would like to see is a "run, but don't elevate" option. As it is, if Windows thinks you need to elevate something, you can either give it full permissions or don't run it at all. Sometimes I'd just like to run something with limited permissions even when Windows thinks I shouldn't.
Well, it should reduce the surface area available for attack. It doesn't make available a comprehensible and comprehensive list of privileges that indicates which ones are enabled/disabled for a given user at any time. It doesn't indicate the proposed change to privileges because that would be technically very difficult to do. It is a glass half full situation. Better than nothing. Decidedly, better than nothing.
I would like to point out that Internet Video Converter http://www.ivcsoft.ca.cx/ doesn't convert videos properly unless it runs as an administrator.
If someone from MS does read this, I would also like Punkbuster (anti cheat service for many games) investigated, so I do not have to run every game as admin to get it to work correctly.
EDIT: I would like to note, I've had friends from school comment on their new computers, saying UAC was annoying. It "asks permission for everything". A few of them have disabled it. UAC in its currrent form I think can't succced. Or maybe developers need to change their apps!
That's because it stores files in 'Program Files', which is something the punkbuster team should address. It should store it's files in the 'Documents' folders.
For PunkBuster, we've been working with them to help them get working well as a standard user. They require the elevation today because of the way they do their checks for hacks/cheats -- there's some great information/explanation on the PunkBuster site at:
http://www.punkbuster.com/index.php?page=faq-bf2.php
Intelman: If you could find out from your friends what they're doing when they see the prompts and let us know, that'd be fantastic. Like I said in the video, it's definitely not expected for folks to see elevation prompts frequently once they've got their applications installed and machine configured. If that's not their experience, we want to hear about it so we can target the scenarios (or talk to the ISVs) that are currently making things painful for them (and other users like them).
It looks like Internet Video Converter has a Vista-compatible version (1.40) coming out next week, based on the announcement at http://www.ivcsoft.ca.cx/.
--Jonathan
JonSchwartz, thanks for the replies. I'll see if I can get a list of what they do....probably mostly gaming and all the anti cheat, autopatch stuff.
Anyways, last time I checked IVC, they didn't have an announcement, but I'm glad they are going to support Vista!
Now once more I have something else to add. Some apps will not set themselves as default unless they are run as admin the first time. Foxit PDF reader and µtorrent exibit this behavior. It took a little while to figure out why Foxit PDF wasn't opening my PDFs by default. So all I did was run it as admin one time, then after that things work. So that might be something to look into.
In most cases what happens is...
1. I update the software on our file server.
2. The user attempts to launch the software executable
3. They are presented with a prompt to update the client software
4. They click install, and the client software is updated
How will UAC help me in the least if I setup users as standard users in Vista? It sounds like I'll have to walk around to each and every users computer and type in admin credentials every single time an update comes out. That's a lot of walking... not that I probably couldn't use it... but it seems like a complete waste of my time. I'd much rather have to reload a computer a couple times a year due problems that arise from users having admin privilages on their local machine, than have to go to each and every computer on a weekly basis to type in administrative credentials.
Personally, I think the whole UAC... while maybe a good idea for a computer noob... is annoying as hell. I've already disabled the annoying popups on my workstation.
Hello. I’m the other UAC team member from the video.
David62277: I can understand your concerns around deployment to Standard Users, in fact, whenever I give a talk about moving an environment to Standard User desktops this is the first issue I mention. Fortunately, there is a solution built into Windows – it’s called Group Policy Software Installation (GPSI).
There is documentation about GPSI available here: http://technet2.microsoft.com/WindowsServer/en/library/b7c2efc1-207e-4089-8490-0d002daf8b6c1033.mspx?mfr=true
GPSI allows an IT Pro to install products on a system by pushing them directly onto the machine, by allowing the users to initiate the installation of specified MSIs, or by automatically installing the products when necessary. This technology also includes facilities for updating the applications without needing to visit each machine.
There are reasons that GPSI may not be perfect for your environment. In those cases, our customers generally acquire a 3rd party product to help solve this problem. While we understand that this isn’t optimal, the cost of these products generally are covered by the reduction of the TCO of the environment.
That’s a very good question. Thanks!
ChrisCorio,
Thanks for the reply. I am aware of how to install software using group policy. It is a great feature that we use now to install the Citrix client to all new domain computers. The problem is that NONE of the software packages that we have here (Accounting Firm) install from a .msi.
I will have to look into some 3rd party apps. Is there any particular package that Microsoft endorses?
Also, would it be possible using GPOs (maybe a custom one?) to allow certain installers in a specific path to automatically install as an admin? Like say... a GPO that allows a specific installer located at \\server\apps\software\install.exe to automatically install as an admin?
Again thank you for your reply
David
Thanks for dropping by.
I showed this thread to a mate, and although he's not convinced that the UAC won't give him problems, he's reassured that MS are looking into issues that come up.
Having a set of deployment exe's is clearly a reason to look for an alternate deployment technology. Unfortunately, we don't offer any particular recommendation for a 3rd party solution.
With respect to elevation through GP, there is no way to use Group Policy to elevate a certain set of executables. However, in Windows Vista we worked to ensure that our installer technologies such as MSI and ActiveX had this ability. To accomplish this we introduced the ActiveX Installer Service and, if you're interested, you can check out a demo here:
http://blogs.msdn.com/uac/archive/2006/09/13/752248.aspx
Thanks for the post!
Chris
Viewing advanced settings requres elevation but i think it should only requre elevation if you change and ok some of the settings.
TIA,
Drew
I mean the way UAC is done in EVERY other OS is better than what is implemented in Vista, so why didn't you do the right thing? Was that not allowed?
For instance, elevations should ALWAYS ask for admin password. Just clicking a button is ludicrous. Now I am sure that asking for a password every time an elevation is done today would drive people crazier, but that leads to the second issue. Why didn't you perform a timeout based elevation.
For instance, if I want to perform some admin tasks, the OS asks for my password, and then for the next 5-10 minutes, I don't get another prompt again because the system knows I am the admin because I entered the password. After that time expires, then I can expect to get prompted for the admin password again, because that's the right way to do it.
Your explanations in the video are very interesting for people who don't have a clue what the problems were with OS's based on DOS, but you fail to address why you implemented UAC in the most annoying and least secure fashion imaginable.
Or does Microsoft not agree that clicking a button is really NOT a security mechanism at all?
Sorry for the slow post/response -- was out of town for a bit.
AJenbo:
Agreed on the environment settings UI -- that's a spot that needs to be refactored, and it's on our list. Obviously, I can't give a specific date or ship vehicle, but it's definitely being investigated and scoped out as I write this.
Raptor3676:
The same applies to the DPI settings -- those are currently done per-machine down inside of the User/GDI infrastructure (win32k.sys) and need to be supported per-user (similar to display resolution).
smalltalk:
The default UAC settings in Vista are actually the result of extensive usability studies and customer feedback over the Vista development cycle. A very good read is Jim Allchin's final blog entry, which digs into some of the tradeoffs that had to be made regarding security and usability:
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/23/security-features-vs-convenience.aspx
That being said, the settings you mentioned can be controlled by policy. To change your prompt policy from "consent" to "credentials," do:
Start
"Local Security Policy" (launches secpol.msc)
Local Policies --> Security Options
Select "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode"
Change the policy to "Prompt for credentials"
Note that you'll need to explicitly launch secpol.msc elevated (via right-click + "Run as administrator...") if you're running as a standard user. The policy change will take effect immediately.
If you want sudo-like behavior, change the policy to "Elevate without prompting" instead -- this allows you to launch items elevated without a prompt until you switch the policy back to "consent" or "credentials." Another option is to launch an elevated instance of CMD (via right-click + "Run as administrator...") and run a batch of commands from there -- it's actually more secure than using the policy since you're still controlling the exact set of commands that you're running elevated, vs. opening the door for anything on the machine to launch arbitrary executables elevated.
Certain MSI's required explicit "run as admin", though I think all MSIs will get a UAC prompt because they are setup programs. Once a user has accepted a UAC prompt brought on by a setup program (MSI or otherwise), it should have full ability to do what it needs to do. IOW, there should be no need to ever run an MSI as admin or run CMD.exe as admin to run the MSI via MSIEXEC.exe.
On a clean install of Vista, WinRAR spawns a UAC prompt when launched directly (.lnk, opening .zip or .rar file). It simply doesn't open at all when right clicking "extract to..." options. I haven't seen either problem on an upgrade install of Vista where WinRARR was installed before the upgrade.
Visual Studio should not need to be run as admin. I can see the argument with some debugging features, but UI and other problems should "just work" whether admin or not. Also, I can't double click to open .sln or .csproj files. Similar to the WinRAR problem, the clicks are just ignored. I can only open them by opening VS. I also can't drag and drop files into VS projects like I could previously. I don't know whether these are UAC related or not, but they are Vista related and very annoying.
Error messages need to be more expressive of the actual problems that are occuring due to UAC. For instance, if you are an administrator and you can't get to something that the Administrators group has access to, rather than saying "Access denied" or similar, the prompt should say "UAC is preventing you from accessing this resource, though your group has access to it". Another option would be to get a UAC prompt. Better yet, if you are in a group that has access to something, you should have access to it with or without UAC.
File permissions, if I want to both change the owner and the permissions on a file, I have to suffer two different UAC prompts. If I haven't devined that though I'm an administrator and the administrator's group has full control on a file (but not me specifically) I'm not supposed to have access to the file, then I might have more UAC prompts to suffer through while troubleshooting the problem.
The security shield icon that appears should be explained clearly somewhere. I'd think would be in a tooltip as well as in properties. It should be explained what it means, when you'll see it, why it's there, etc. Two examples: VS and WinRAR both pretty much require "run as admin", both are set on the compatibility tab to run as admin, yet one has a shield and the other doesn't. So, what does that sheild mean to me? Nothing at all.
UAC appears to be all or nothing. I'd like to have protected mode in IE w/o all the other UAC annoyance. I understand from a coding perspective there is some relationship, but from a user perspective there is not. What does changing a firewall setting have to do with protecting me while surfing in IE? Absolutely nothing.
Downloading a new gadget to the sidebar:
1. From the site, where you find a nice gadget to download, you click it. Microsoft's website then queries that you are about to download another persons code. Click OK. Dialog1.
2. You are now redirected to the download itself. It asks you if you'd like to save/run it. Click Run. Dialog2.
3. The program downloads, but it's a dot-gadget file, so you need to click Open. Dialog3.
4. But the dot-gadget file was from a website. In comes UAC to tell you of the fact, and we answer OK or stick in a password. Dialog4.
The sidebar finally installs it's gadget.
Did you guys get a say in that decision? I assume not since you don't even know it is a missing feature.
Fortunately for the very high tech home users (like grandma) they can simply use RegEdit to change UAC policies. User friendly and very efficient.
Confirms my suspiscions that the "user community" that was asked to review the UAC design was mostly MS marketing managers.
Nice catch -- bad repro steps on my part. Ironically enough, I'm very familiar with the SKU differentiation around secpol.msc -- I just ended up being careless there, since all of my office machines are currently running business SKUs
For those who are looking to modify the policies with RegEdit, the following values map to the policies I mentioned earlier:
Key: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
Values:
ConsentPromptBehaviorAdmin
0 -- elevate without prompting
1 -- prompt for credentials to elevate
2 -- prompt for consent to elevate (default)
PromptOnSecureDesktop
0 -- prompt on user desktop
1 -- prompt on secure desktop (default)
evildictaitor:
Thanks for the heads-up on the Gadget download experience. I'll look into it and make sure the right folks are on it.
Wodei:
The times you've needed to run an MSI from an elevated CMD window are actually bugs in the MSIs themselves. Essentially, each MSI action can be marked as running as the user (i.e., non-elevated) or as the machine (i.e., elevated). Over the course of Vista, we saw quite a few MSIs that had per-machine custom actions mismarked as per-user -- we shimmed them (via MSI transforms, which get installed to %WinDir%\AppPatch\msimain.sdb as part of the OS shim infrastructure), but some obviously managed to fall through the cracks. If you can point me at the problematic MSIs, I can make sure the ISV knows what needs to be done (and potentially get them shimmed for SP1).
Note that not all MSIs require elevation, since MSI packages can be marked as entirely per-user. I expect to see much more of this moving forward (e.g., it would be ideal for a game demo or "try and buy" software).
For WinRAR, version 3.7 should be fully Vista-compliant, including elevation only when necessary (e.g., unpacking to an admin-only folder, vs. your user profile) and fixing the issue with the context menu handler. The Visual Studio team, similarly, has their elevation behavior at the top of their list right now.
In theory, the shield should automatically be appearing on any EXE that's marked to require elevation -- any inconsistency there, like you said, makes the marking nearly valueless. I'll see if we can repro that on-site with the VS and WinRAR settings you described.
That being said, I'm currently chatting with the IE and Sidebar teams to get the experience here improved.
--Jonathan
My proplem with UAC is: When I install an application I have to provide the credentials of an administrator. After doing so, the installer runs as administrator-user.
Why is that? Shouldn't the standard user getting an "admin-token" and run the installation?
The next problem is the little checkbox at the end of the installer saying: "Launch Application now". If this checkbox is set, the first start of the new application runs as admin-user. I did have to configure some software twice because the first time I did it with the wrong user! That's at least annoying.
Maybe I'm getting this completly wrong but after watching the video I find this behaviour strange.
Greetings from Germany,
Stefan
Just have to say- EXCELLENT stuff. Love Channel 9. Keep it up.
FOR JOHN or CHRIS: I started right-clicking a bit to see the different credential windows and I noticed that when I run as elevated against Windows Meeting Space i get a unidentified program prompt saying it's an unrecognized and unsigned app.
Normal?
I may have found another bug. Running Vista Business. I disabled elevation prompts for standard users.
As a standard user, I get the expected dialog box denying my account access and not prompting me except when I try to change Windows Firewall settings. Instead, it just sits there. Specifically, I navigated to CP and selected Windows Firewall. From there, I'm selecting Change Settings. It has the Security shield next to it so I'd expect one of those "you-can't-do-this" window but I get nothing.
FYI . . .
The only thing I would add is the fact that the title of these pop-ups state's that it's an unidentified application. Do you really want Windows not identifying IE or Meeting Place?
For the elevations, we needed to make sure that we didn't end up with users stepping outside of their groups/roles as part of the elevation, since that can lead to vulnerabilities or information disclosure as a result. For example, anything the elevated application (running as "standard user + admin SID") would save in its user profile would be accessible to the standard user later on and could expose data to which they otherwise wouldn't (and shouldn't) have access (e.g., results of a system scan that enumerates other users' files, etc).
JasonY:
You're correct about Windows Meeting Space being in the same bucket as IE. As for why we used the "unidentified" dialog in that case, it's primarily because the description and guidance is almost exactly what we'd want to say for a dialog specific to this category of system EXEs. That said, if we were to get feedback that multiple customers were seeing this dialog as part of a normal use scenario and getting confused/misled as a result, we'd definitely look into a new flavor of the dialog with more specific text.
I just verified that the bug you mentioned is on the Firewall team's radar. Very nice catch -- definitely let me know if you run into other spots like that!
--Jonathan
Hello Jon,
let me get this straight: You are worried that an user who has the credentials of an admin-user, could expose data of other users on the same pc? Hmm, I *think* that user can do that anyway.
I think it's more dangerous to start a newly installed application as an admin user. Why?
The standard-user thinks he has not the right or power to do any real damage to the OS. But the first "playing around" with a new application could possibly kill of the OS or can do real damage because it's the enviroment of an admin-user.
From this point of view, the UAC is not much more than a nicer "run as ..." feature. Why can't the "UAC-Service" sense the end of an installation and the first start of the application?
Stefan
Remember that the case where the standard user actually knows the administrator's credentials is not the norm (except for folks like us
As for application installers that currently launch the application at the end of the setup both elevated and in the wrong context, I agree. We're actively working with the associated ISVs to get that fixed in the next release of their app and have published developer guidance to the same effect.
The design suggestion here is that developers structure their "install + first run" with the autorun (or initial stub) EXE acting like a bootstrapper that launches both the setup EXE (elevated) and then the application itself (in the same context as the autorun/stub) once the setup completes. This keeps things robust to any future changes and also covers any/all edge cases w.r.t. the initial context for the autorun/stub (e.g., running in Protected-Mode IE, running with a custom filtered token, etc).
--Jonathan
Thank you for your replies. It's great to see you take such a proactive, enthusiastic stance with both the technology and your customers.
On another note, I ran into a behavior I'm not so sure is a bug but rather just misleading. I created a folder on the desktop and then later tried to rename it. I received three prompts including a UAC prompt. Finally, the rename failed. I was logged in as admin and had adequate permissions. After a google or two, I realized I had a word doc open that was in the folder. I closed the documents and renamed the folder without any prompts. In other words, the interaction I had with the system gave me the impression it was a security restriction of some kind and nothing about open file or anything of that sort. I know this may not be in your area but the access denied and UAC prompt was confusing. In XP it's real clear: "close down any open programs."
For what it's worth . . .
I dug into this one and it ends up being due to legacy behavior in the filesystem, where it returns ERROR_ACCESS_DENIED from MoveFile(Ex) in this case, rather than ERROR_SHARING_VIOLATION (or something similar). As a result, the Shell thinks that it needs to elevate (which it now has the ability to do via UAC, vs. XP when it could simply fail out), even though it's doomed to failure.
The filesystem folks are currently thinking through some ideas for what we can do here moving forward. It gets tricky since this particular case has existed in the filesystem since (at least) NT4, so simply changing the error code becomes very risky in terms of App Compat.
--Jonathan
I have nothing against UAC, i don't hate it, i don't love it.
I am a network admin for a consulting firm and some of our clients are starting to get Vista machines. We had one the other day tell us that they are unable to save files to the network shares. Tells them Unable to save files, does not matter what file type.
Is this issue caused by UAC? Would turning it off correct this or is this question for a different forum? Many thanks for your assistance.
Justin
jbarklage
How is the error manifesting (e.g., "error dialog through the Shell that says xxxx")?
It's possible that the error is due to lower permissions due to UAC, but it's unlikely. UAC would be affecting things only if all of the following are true:
1. Your users were running as members of the Administrators
group
2. The share is ACLed such that only admins can write to it
3. The file share is also a Vista machine
4. Your users have local accounts, rather than domain accounts
#1 + #2 would be required for a permission problem, since your users wouldn't be running as full admins unless they explicitly elevate. However, #3 + #4 would also be required for the token filtering to propagate on the wire -- by default, filtered admins using domain accounts get their full token on the target (Vista) machine to allow for remote administration.
One last thought -- could it be due to the firewall (either the one shipped in the box or a different one that you install on your client machines)?
--Jonathan
We have a COM based application written in C++, and have difficulty to make it work on Vista. Will you please give guidance?
Our application talks to a COM exe, we also have a MMC snap-in talks to this COM exe, i.e. the application communicate with MMC(snap-in) via this COM exe.
Both the application and MMC(Snap-in) can start an instance of the COM exe if non-existence, and then share between each other.
On Vista, if the COM exe is started by either of them, the other one will fail to connect to the running COM exe, i.e. the code hr = GetActiveObject(...) returns faiure.
Following "Windows Vista Application Development Requirements for User Account Control Compatibility" document, I rebuilt the application embeding a manifest file with "level="requireAdministrator" uiAccess="false", the problem is gone.
However, we do not want to give the application "Administrator" right. so I tried to embed the manifest file to the snap-in DLL. No effect, the problem returns, GetActiveObject(...) gives me failure.
What is the best way to deal with this problem?
Thanks in advance.
sz204:
From the description, the problem hits because MMC is running elevated while your second app is not; as a result, the COM server runs elevated when started from MMC and the non-elevated app can't access its ROT entries.
I asked the COM folks for suggestions, and they mentioned two possible ways to solve this:
1. The COM server can register in the ROT using
ROTFLAGS_ALLOWANYCLIENT -- this is described
towards the end of
http://msdn2.microsoft.com/en-us/library/ms679687.aspx
2. You can configure the COM server to RunAs
"Interactive User" -- note that this solution assumes
that the COM server itself doesn't need any admin
privileges and will always be used in a scenario where
a user is logged on (else it will fail to CoCreate).
--Jonathan
I hope you are still monitoring this forum thread even if it is getting a bit stale.
I just watched your video and absolutley loved it. It is great to be able to get insight into what the developers of such a critical feature were/are thinking. It has refreshed a lot of the random bits I have collected in the past and put them into context quite nicely.
I love what UAC is trying to do, unfortunately I am one of those that isn't a big fan of the cost incurred by me and my company by allowing UAC to run. I totally get Vista trying to compartmentalize things and not letting things run roughshod over the whol OS - a long overdue feature. I understand that once developers are retrained to create applications that are obediant, life will be good. But in the mean time my life is much more difficult and the cost to my organization is likely to be high.
I'd like you to convince me that I am wrong. Here are a few issues I'd love clarified and I have yet to find anyone knowledgeable enough to answer (you look knowledgeable enough
1) I have network admin scripts and tools that are located on network shares which also store logs there. When I try to elevate these tools with my admin account (which they need to run), they fail because the drive mappings disappear. This is because of the mappings being associated with my filtered token and my full token not being able to access them - if I understand things properly. I found KB article 937624 which describes creating the key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections = 1 to allow the mappings to be visible from every priviledge level. BUt I have not found any information to describe what is actually happening technically or if this opens any kind of UAC loopholes. Can you comment?
2) Some of the elevated tools I run must send e-mails via Outlook. I have found that the scripts are only able to interact with Outlook if they first elevate Outlook as well. This obviously scares the hell out of me. Why is it necessary to do this? Why isn't my elevated script allowed to talk to an instance of Outlook operating at a lower level?
3) We have had to give some user accounts local admin priveledges in order to be able to properly install and use some older products that don't obey the new rules yet. The problem is that some of these users like to use domain admin tools that require their seperate domain admin account. However, when they go to elevate these admin tools, they are only given the UAC Consent prompt rather than the UAC Credentials prompt. Obviously Vista sees the full token for the Local admin and thinks that is good enough when clearly it isn't. How do we work around this? Is a better solution coming? (i.e. a button in the corner of the Consent dialog that lets us choose to enter credentials).
4) An extension of number 3) above... UAC is obviously being fooled by the presense of a full token - any full token. Will UAC make the same mistake if a program needs a full admin token, but the best the user has is Print Manager priviledges for his full token? Will UAC notice that the user falls short and ask for Credentials instead of Consent?
Sorry for the long e-mail but it looks like I might finally have someone knowledgeable to answer my questions here.
Sincerely,
Gordon Martin
http://VistaVitals.blogspot.com
Yup -- still monitoring the forum actively
Some great questions there -- here goes:
1) Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping. Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.
2) For COM servers configured as "Activate as Activator," COM does some very strict matching to ensure that the client/caller and the COM server have the same security attributes -- this was actually the case pre-Vista as well (e.g., blocked from clients started with runas.exe, running in a different TS session, running with a filtered token, etc). It's done to prevent attacks against the client both via spoofing (i.e., malware can spoof the class/ROT registration) and COM callbacks (from the lower-privileged server). One possible solution for you would be to route the script to something running as the interactive user, and then to call Outlook from there -- the simplest solution that comes to mind would be to use a Scheduled Task for this (i.e., script passes the information to the task, which invokes Outlook).
3) You can actually configure the UAC policies to change the prompt type from "Consent" to "Credentials" for cases where users have (effectively) multiple admin accounts. Take a look at http://blogs.msdn.com/uac/archive/2006/01/22/516066.aspx for a good walk-through and screenshots with secpol.msc.
4) If the program is marked as "requireAdministrator," we won't accept anything less than a full admin token -- in the example you gave, the user will actually get a credential prompt (rather than consent) since the user's elevated token doesn't contain the "Administrators" SID.
--Jonathan
Thanks for your response Jonathan! Some great detail there.
A quick follow-up on some of the questions:
2) Good details regarding communication with Outlook. But I think creating a script which launches via Scheduled tasks which then picks up message contents via an intermediate INI file or through some kind of listening code is beyond the reach of most administrators. Unless Microsoft provides some guidance/sample code to support this approach, I think most admins will simply end up elevating Outlook. However, if COM is as strict as you say it is, elevation of Outlook may not be the end of the world. I think another valid approach would be to find a third-party e-mail package that isn’t quite so strict. I assume that if I am elevating a tool it would still be able to communicate with any application operating at the user level – such as a third-party e-mail product.
3) Yes, I’ve seen the Consent vs. Credentials security settings before, but that is not a very friendly solution. The problem is that the consent approach is great for 98% of a user’s experience – particularly when they have legacy apps that need local admin rights in order to run. It’s just that remaining 2% where there is no way to elevate to another admin account at all. It wouldn’t be very nice if we make someone suffer 98% of the time by forcing credentials just to make the remaining 2% possible. There are two things that I would like to see change – either of which would greatly improve my situation. One would be to offer a button on the consent prompt such as “enter credentials” so that the user can choose to enter credentials for another account for only the 2% of the time when it is required. I also really miss the “Run As…” option on the context menu. As discussed, the “Run as administrator…” prompt has its limitations.
Currently, most of our administrators have resorted to using the RUN AS command from a CMD window in order to get their work done. It’s funny to have this beautiful OS, but to spend all our time in a black DOS screen. This problem would go away if we could get a RUN AS on the context menu (I just might try to write one).
While I’ve got your ear, I’d love it if you would explain to everyone the behavior of the Windows Explorer (file manager). It clearly doesn’t follow the usual application elevation rules. We now use the “Launch folder windows in a separate process” option to allow us to elevate Explorer, but even with that option it will not allow us to elevate to another admin account. If we travel to a user’s desk, it is not possible to elevate Explorer with an admin account and perform functions reserved for administrators. In fact, Explorer is downright misleading on the whole subject. If we try to manage files in the System32 folder with a user account, Explorer will prompt for all sorts of credentials and things as if it will elevate us, but in the end we don’t get what we need. Either nothing happens or we get messages unrelated to what is really happening. This has been very frustrating and has cost many people time as they scratch their heads trying to figure out what is happening. What is happening? Could you tell us?
At the moment, the only way we have been able to do our jobs has been to perform things like system32 file management from the DOS prompt. Lately we have actually been finding third-party file management programs on administrator PCs. It was surprising, but actually makes sense. Third-party file managers look like normal applications to Vista and therefore elevates normally. It then becomes possible for administrators to do a lot of their work without resorting to a DOS CMD window.
Thanks for your time Jonathan, it is much appreciated,
Gordon Martin
http://VistaVitals.blogspot.com
I am not sure what I am experienced has anything to do with UAC, but I suspect it does.
I am logged in as a regular user ("annius") and I am in the administrators group. When I create a folder in my Documents folder, it is owned by "annius" as I would expect. When I create a folder on the desktop, it ends up owned by "Administrator" (I don't need to answer any prompts to get it owned by Administrator). Subsequently, I can't rename it or put anything inside it.
Could this be because I once "elevated" and as of that moment I my Windows explorer runs as "Administrator"?
This happens regardless of whether I have UAC enabled or disabled.
The only thing that is special is that this happens on a laptop machine that operates inside the windows domain at work when I am at work, then I put it to sleep, and take it out of sleep at home where the domain "is not there". Again, not sure that that has anything to do with the problem.
cygwin$ ls -l ~/Desktop
d---------+ 2 Administrators Domain Users 0 Apr 12 10:19 New folder
cygwin$ ls -lad ~/Desktop/
drwxrwxrwx+ 6 annius Domain Users 12288 Apr 12 10:19 /home/annius/Desktop/
(permissions 777 set on Desktop is probably due to one of my previous attempts to get full ownership of the files on my desktop).
This is actually unrelated to UAC. The system will set the owner of objects created by admin/elevated tokens to the Administrators group; this prevents any non-elevated malware running as you from coming along later on and being able to modify the object (which it would be able to do if your user SID was set to the owner instead).
Since you're a member of the Administrators group, this is the behavior you'll get in the case with UAC turned off (since you're running as a full admin).
With UAC on, my suspicion is that you somehow ended up with Explorer running elevated (e.g., it died and you restarted it from an elevated instance of Task Manager, etc), and that's why you ended up with the unexpected ACL there.
Let me know if I'm reading the config or folder locations incorrectly, in which case I'll go back to the drawing board for the answer
--Jonathan
No I'm not running IE in Administrator mode
Yes my UAC is enabled
Yes I'm using Windows Vista Home Premium SP1 Everything is up to date
No I didn't change anything in my IE setting since this has happened last month only
Yes I did try a full IE Reset
Oh and its IE7
What else ?
Thank you for your help
Whether it can happen on XP or not, we would hope that Vista and beyond would be better
I'm new to Vista/Windows 7 (i.e. UAC), I just installed Windows 7 a few weeks ago on my Wife's computer, and today I took the plunge and installed Windows 2008 R2 on a new computer I bought for myself. I'm a developer.
So far, I must heartily agree with the second post in this thread, that there is something messed up with fileshares. I'm seeing more or less the same behavior as he descirbed.
I've created a user on the Windows 7 computer, and added him to the administrators group and every other group on the computer, and then I gave all of these groups read/write access to a new fileshare.
However, the only way I can access the share is if use the "Administrator" account for the credentials to access the fileshare.
The other account can access the public share, but not the additional shares.
I'm not looking for a solution - this is a home network, I'll just login with the Administrator account and be happy ever after - but I'm just trying to underscore a problem and provide some agreeance with that poster, even if it is 2 years later
Remove this comment
Remove this thread
Close