And so this is Vista…
What becomes of all my earlier non-admin tips, tricks and recommendations vis-à-vis RunAs, MakeMeAdmin, PrivBar and their interactions with IE and Explorer? The short answer is that Vista changes just about everything with respect to running with least privilege.
Windows Vista makes running as a standard user (non-admin) much more pleasant, feasible and secure than it was on XP. I'm not going to drill into all those improvements here. Instead, the focus of this post is to update my earlier posts about running on XP as a standard user (the "Running as Admin Only When Required" posts in the Table of Contents) as they pertain to Windows Vista. To save some space, I'll assume you've spent at least a little time running Vista.
MakeMeAdmin
Let's start with MakeMeAdmin. Vista renders MakeMeAdmin obsolete. On XP/2003, MakeMeAdmin lets you run as a standard user, and temporarily elevate your standard account to run a selected program with administrative privileges. Vista gives you the same ability, but with more convenience and more safety than MakeMeAdmin could provide.
If you are a member of the Administrators group on Vista, it's effectively the same as being a standard user, as long as you never run anything elevated: all your admin rights and privileges are disabled. Elevating an application does essentially the same thing that MakeMeAdmin did, but more conveniently, and more securely. Here's why:
- The convenience is that by default it's a simple one-click confirmation in a "consent" dialog, rather than having to enter two passwords in two console windows.
- Elevating an application using "consent" requires non-spoofable user interaction. By non-spoofable, I mean that malware with normal user privileges can make a UI look like the consent prompt, but it can't elevate anything. Further, the consent prompt appears on the secure "winlogon" desktop, which cannot be seen or manipulated by unprivileged code. Even if low-privileged malware steals your password, it can't get anything to run elevated without the interactive user going through the elevation UI. On XP, malware that obtained the password for an admin account could run programs with full admin privileges at any time.
- "Elevated" applications on Windows XP running on the same desktop with lower-privileged programs were subject to "shatter attacks" – the lower-privileged programs sending window messages to the windows of higher-privileged applications and driving them programmatically, or exploiting buffer overflows to run arbitrary code in the "elevated" context. With Windows Vista's Mandatory Integrity Control (MIC) and User Interface Privilege Isolation (UIPI), this becomes more difficult. (See Mark Russinovich's recent TechNet Magazine article for more information.)
You have to be careful about what you choose to elevate, but the same was true with MakeMeAdmin, too.
RunAs
Windows XP provided two interfaces for "RunAs" – the "right-click" dialog version, and the runas.exe console application. The dialog version has been replaced by the "Run as administrator" option. The console utility is still there, but it has limitations.
The Windows Shell team probably knows for sure, but I'm willing to guess that the main reason people used the "Run As" dialog on XP (probably only a tiny percentage ever used it anyway) was to run a program with admin permissions, and that for this purpose, "Run as administrator" serves as a superior substitute. With the default settings, a member of Administrators can use it as a MakeMeAdmin replacement (see above); a standard user gets a dialog that lets them enter the credentials of any admin account and run the target program with those credentials, also gaining the security improvements of UIPI as well as the secure desktop UI. One complaint I have seen in my blog's comments is that a member of Administrators can't choose to run as a different admin user, such as a Domain Admin account. This can be addressed by changing the elevation behavior for administrators from "prompt for consent" to "prompt for credentials".
The runas.exe console utility still exists, and it will let you run a program as a different user, but not with elevated permissions. If you specify an admin account, for example, you get the "filtered token" for that account, with admin groups and privileges disabled. As mentioned earlier, you'd need to go through the elevation UI to get the "full token".
Runas.exe is not as secure as the elevation UI. Runas.exe runs and collects credentials in the security context of the logged-on user, and so any malware running as that user can take control of that process, monitor the keystrokes going into it, changing the target program, etc. By contrast, the elevation UI collects credentials on the secure "winlogon" desktop (by default), which is accessible only to code running as System.
One thing that hasn't changed with runas.exe is that it still requires credential entry at the keyboard – you can't pipe in a password through stdin or in the command line. This is to help discourage the insecure practice of putting plain-text passwords in script files. (Answering one of the most commonly-asked questions in my blog's comments.)
Browsing the file system with Internet Explorer, and running IE and Windows Explorer as a different user
Internet Explorer used to be able to browse the file system. Beginning with IE7, that became history, both on XP and Vista. If you enter a file system path into the IE7 address bar, it will open a new Windows Explorer window to that path. From a security perspective, it seems like a pretty good idea not to allow the main program that interacts with that hostile world known as the Internet to also interact with your file system in the same way.
This change broke scenarios for a number of people who had found IE to be more "RunAs-friendly" than Windows Explorer for browsing the file system with elevated privileges. Windows Explorer on XP can be made more RunAs-friendly – see the SeparateProcess advice I posted here.
On Vista, however, there are more changes. Neither Internet Explorer nor Windows Explorer is willing to entertain multiple accounts on the same desktop. If you try to run IE under a different user account from that of the desktop, it will display an error message: "The RUNAS command is not supported." As I understand it, the primary reason is that with Protected Mode Internet Explorer, which runs at Low Integrity Level, IE also launches a Medium IL broker process (ieuser.exe) which runs as the desktop user and which gates selected Medium IL operations for the Low IL process. Allowing multiple identities into that mix would have introduced significant complexity best avoided. If you try to run Windows Explorer as a different user, you'll see nothing – the new process starts but exits without displaying a window.
However, I have found that it is possible for a member of the Administrators group to run both IE and Explorer with elevated privileges. With IE, right-click its icon in the QuickLaunch or in the All Programs menu (not at the top of the Start Menu) and choose "Run as administrator". One thing you'll (hopefully) notice is that the UAC elevation prompt for Internet Explorer shows it as "an unidentified program" from an "unidentified publisher", rather than as a Windows component or other signed program from a trusted publisher. As I understand it, the reason for this is because systems will quite often have IE plug-ins that are not signed and which may introduce more risk than the user may be aware of. Hence, the "unsigned" prompt is intended to discourage running IE with full admin privileges.
Explorer is a little trickier. Directly applying "Run as administrator" won't do it, but running it from an elevated command shell often will. I find that a command line like "explorer /e,c:\" will work, while just running "explorer" might not. But as before: if it works at all, it is an unintentional side effect of the current implementation, and is subject to change at any time.
How can you tell whether it worked? PrivBar still works on Vista, both for Internet Explorer and Windows Explorer.
Comments
Anonymous
June 28, 2007
I've heard of Windows XP & how to "RUN SAFELY AS AN ADMINISTRATOR" but what is this "thing" called "WINDOWS VISTA"!!!*** @Gotcha: ??? I have no idea what to make of your comment. But here's a URL: http://www.microsoft.com/windows/products/windowsvista/default.mspx HTH -- AaronAnonymous
June 28, 2007
> On XP/2003, MakeMeAdmin lets you run as a > standard user, and temporarily elevate your > standard account to run a selected program > with administrative privileges. Right. It doesn't mean temporarily elevating your administrative account to run elevated, it means temporarily elevating your standard account to run a selected program with administrative privileges in the context of your account. > Vista gives you the same ability It does not. Here's what Vista gives: > If you are a member of the Administrators > group on Vista Exactly. It means temporarily elevating your administrative account to run elevated. It doesn't help your standard account at all. > "Run as administrator" serves as a superior > substitute. With the default settings, a > member of Administrators can use it as a > MakeMeAdmin replacement No, it is not a substitute, it's different. A member of Administrators can use it to temporarily switch context to an administrative account and run elevated in the administrative account. If the administrator does this to install an application for all users then there's no real problem, the application gets installed for all users just as it did in XP. But if the administrator wanted to do this to install an application for the standard user, they can't do it. The administrator gets to install the application for one user's account, which is going to be the administrator's account, it's not going to be the standard user's account. The standard user doesn't get the benefit that MakeMeAdmin provided. Standard users in Vista still need a MakeMeAdmin tool. @rwx: It's not identical, but it's very similar. If you use MakeMeAdmin on XP, then the difference between your standard user token on XP and the corresponding "filtered admin" token on Vista is that in the former, the Administrators group is not present in the token at all, while on Vista it's present, but marked disabled/deny-only, which (for the Administrators group, at least) is practically the same as not present. The tokens in the respective "elevated" cases are very similar. (Remember that MakeMeAdmin works by temporarily adding your standard user account to the Administrators group.) I don't understand the point you're trying to make about using admin privileges to install a program for a single user. If you're using admin privileges to install the app, presumably you're doing so because it's a machine-wide install, not a per-user install. A true single-user install should be doable by a user without elevated privileges. Please feel free to respond to clarify anything I didn't understand. -- AaronAnonymous
June 28, 2007
> Remember that MakeMeAdmin works by > temporarily adding your standard user account > to the Administrators group. Exactly. That is the reason why a MakeMeAdmin user can use administrative privileges to install a single-user program for use by their own account. In Vista, doing a run elevated, a standard user can input the password of an administrative account, and install a single-user program for use by the selected administrative account. They don't get to install the single-user program for use by their own account. When they try to use the program themselves, it isn't there for them. > If you're using admin privileges to install > the app, presumably Got it. Unfortunately, the user who got really confused by the results and caused several of us to spend a day or two figuring out what's going on, didn't share your presumption. Several of us who spent a day or two also didn't share your presumption, but we did eventually figure out what was happening. > A true single-user install should be doable > by a user without elevated privileges. Personally I favour that opinion. However, depending on the interaction between the application's installer and a driver, the installer might still need elevation. (The driver was already installed machine-wide using administrative privileges; that's not an issue here.) @rwx: What you're describing sounds like a pretty uncommon scenario. You could always add the user to the admins group, log out and log the user back in, do the consent elevation and the install, log back out and remove the user from the admins group. I know that seems like a lot more effort, but as I said this sounds like an unusual scenario. -- AaronAnonymous
June 28, 2007
> What you're describing sounds like a pretty > uncommon scenario. You won't like this answer. I agree that the scenario is uncommon, and the reason is that it is uncommon on any Windows system anywhere in the world for any user to be other than an administrator. > You could always Yes, of course. But you wrote the MakeMeAdmin tool in order to automate exactly that procedure, right? Your blog posting here seemed to be saying that MakeMeAdmin is no longer necessary in Vista, but the fact is exactly the opposite. MakeMeAdmin is still necessary (or should I say convenient) for the exact same reason that it was necessary (or should I say convenient) before. Since I personally favour the idea of users running standard accounts as much as possible, I was sad to see the result of the scenario. The product was re-spec'ed as requiring users to be in the administrators group. If Vista's RunAs would work the way MakeMeAdmin used to work, I think this re-spec'ing would have been avoided. @rwx: No, the reason I said it seemed uncommon is that you're describing a per-user install that requires admin permissions. That doesn't make sense. If the problem is that the installer is prompting for elevation when it doesn't really need it, then that's the problem that should be addressed. And as I said (or should have): there's a big difference between XP and Vista regarding membership in the administrators group. As long as the user is trusted to administer the system, being and running as a member of the admins group on Vista is really no different from running as a standard user -- until the point at which you choose to elevate a program. At that point, elevating an application and using your full admin privileges is almost the same as running MakeMeAdmin on XP -- except that Vista does it better. -- AaronAnonymous
June 28, 2007
The comment has been removedAnonymous
June 28, 2007
The comment has been removedAnonymous
June 29, 2007
Thanks for finally addressing Vista.Anonymous
June 30, 2007
Since RunAs.exe won't run a program elevated, is there a way to trigger an elevation prompt from a script?Anonymous
July 02, 2007
The comment has been removedAnonymous
July 05, 2007
I agree totally with you about using tools on vista like MakeMeAdmin has drawbacks compared to UAC, especially in the 2nd and 3rd of the 3 hings you mentioned at the beginning of the article. I agree but I can tell you one of the first thing i turned off was UAC. Simply why, because it's annoying. And it might be the biggest disadvantage of UAC. Instead of being a good help for a normal user who do not know to much about elevated processes and difference between admin and non-admin usage, it makes the user angry and makes them ask what you wrote about <a href="http://blogs.msdn.com/aaron_margosis/archive/2007/06/29/faq-why-can-t-i-bypass-the-uac-prompt.aspx">here (FAQ: Why can’t I bypass the UAC prompt?)</a> I do not tell anyone to turn off UAC, but I can offer them an alternative when they ask me 'How to turn off UAC'. We have now RunAsAdmin run on Vista. Although not all features are supported on Vista and the program is still in beta but I believe it could be a good choice on vista also. By the way, are you sure PrivBar works on Vista? I think it works only on the 'Classic theme' not on 'Aero', am i right!? Bests, Hofi.Anonymous
July 05, 2007
I've read about others getting angry at the UAC prompts, but we need to try to educate them instead of letting them turn it off. Yes OF COURSE they were the ones who clicked on whatever they clicked on, but that's because they know they clicked on it. Just wait until one of those prompts comes up when OF COURSE they weren't the ones who clicked on whatever some malware clicked on, because they know they didn't click on it. Then they should be really glad they can answer "No" to a prompt instead of letting malware have its way. There's also an unintended benefit. I've alread had occasion to say "hey, I didn't want my fat fingers to do that" and a UAC prompt let me say "No".Anonymous
July 15, 2007
Aaron, thanks for finally addressign Vista. I have looked to your blog for a while now for tips on making my non-admin life easier. The biggest problem I still have is not being able to run explorer as a different user. I don't care about not being able to run explorer as a local admin, I want to run it as a domain account. Since most things I would use this for are on remote machines, local admin rights are a non-issue. The only workarounds I have found are to use an alternative to explorer, or to connect to the c$ share of the machine, which causes a prompt for alternate creds.Anonymous
July 17, 2007
The hidden trick to stopping explorer.exe on Windows Vista cleanly, without terminating it abruptly.Anonymous
July 17, 2007
This is the first time I have blogged here about something other than running with least privilege. It'sAnonymous
August 12, 2007
The comment has been removedAnonymous
August 13, 2007
Well indeed finally removing IE from Windows is getting easier thanks to this.Anonymous
August 13, 2007
The comment has been removedAnonymous
September 08, 2007
Dear rwx and Aaron, > @rwx: What you're describing sounds like a pretty uncommon scenario. You could always > add the user to the admins group, log out and log the user back in, do the consent > elevation and the install, log back out and remove the user from the admins group. I > know that seems like a lot more effort, but as I said this sounds like an unusual > scenario. I have discovered that it is possible to modify MakeMeAdmin for use with Windows Vista. Firstly, as an administrator, create elevate.js and add it to your PATH (see the post "Scripting Elevation on Vista"). Then add the modified version of makemeadmin.bat (posted below) to your to your system (change Admin as required). Log on as a Standard user (i.e. non-administrator) and invoke MakeMeAdmin as on Windows XP; with UAC enabled, three elevation prompts will occur (2 to add/remove your user account from the administrators group and 1 for the elevated runas (i.e. runas used in conjunction with elevate.js)). In the resulting command prompt, type "whoami /all" to confirm that you have an unfiltered admin token (alternatively drop "elevate.js cmd.exe" from Prog to obtain a filtered token). From there, you can type "explorer /separate", as on XP, to obtain an admin instance of explorer. Note that since explorer inherits the unfiltered token, UAC prompts will not occur. On Vista, you can drag and drop between admin/non-admin instances of explorer (this was not the case on XP), and you also don't need to press F5 to refresh the admin instances of explorer. Regards, Patrick
makemeadmin.bat @echo off setlocal set Admin=%COMPUTERNAME%admin set Group=Administrators set Prog="cmd.exe /c elevate.js cmd.exe" set User=%USERDOMAIN%%USERNAME% if "%1"=="" ( runas /u:%Admin% "%~s0 %User%" if ERRORLEVEL 1 echo. && pause ) else ( echo Adding user %* to group %Group%... elevate net localgroup %Group% "%" /ADD if ERRORLEVEL 1 echo. && pause echo. echo Starting program in new logon session... runas /u:"%" %Prog% if ERRORLEVEL 1 echo. && pause echo. echo Removing user %* from group %Group%... elevate net localgroup %Group% "%*" /DELETE if ERRORLEVEL 1 echo. && pause ) endlocal
Anonymous
October 01, 2007
The comment has been removedAnonymous
October 01, 2007
The comment has been removedAnonymous
October 01, 2007
The comment has been removedAnonymous
October 19, 2007
The comment has been removedAnonymous
January 02, 2008
"This can be addressed by changing the elevation behavior for administrators from "prompt for consent" to "prompt for credentials". " How do I do this? [Aaron Margosis] Administrative Tools, Local Security Policy (secpol.msc): Local Policies, Security Options, "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode."Anonymous
March 20, 2008
The comment has been removedAnonymous
September 11, 2008
The comment has been removedAnonymous
September 12, 2008
OK thanks for the info. In my reading I've come across references to file system and registry virtualization in the standard user accounts. Does this do anything to increase security/block malware for the standard user? Thanks [Aaron Margosis] No -- file/registry virtualization is an application compatibility technology. What file/registry virtualization do is that when a "legacy" app tries to write to protected areas (e.g., %ProgramFiles%, %windir%, HKLMSoftware), Windows silently redirects that access to a "virtual store" in the user's profile, where the user has permission to write. The modifications are then visible to that user but not to others on the same machine.Anonymous
September 13, 2008
OK thank you again. Since there is no security boundary between a low process and an elevated one on the same desktop, it’s clear that the safest way to run is to not elevate the standard user account, but instead to use Fast User Switching to open an admin account to do admin tasks when they come up. But sometimes the user has gone through 3 or 4 steps in a process and then is presented with the elevation prompt. If the user then switches to the admin account he must go through all those steps again to reach the same point where admin rights were necessary. Or is there a way to switch to the admin account and have it continue from the point where the standard account left off? ThanksAnonymous
December 23, 2008
Hi Aaron, I think that Vista actually encourages people to add their account to the "Administrators" group - albeit constrained by UAC - because (AFAIK) it is not possible to obtain an elevated instance of Windows explorer from a Standard user account. I am aware that OTS authentication is built in to Windows explorer, when logged on as a Standard user, but for users such as myself this is not practical (as it results in entering the credentials of an administrator repeatedly with every system-wide change). What is needed is an administrative instance of explorer that "sticks" (when required) for a Standard user. I am aware that an elevated instance of a Command prompt can be started from a Standard user account but an elevated instance of explorer cannot be started from this prompt (because it is running under the credentials of a different user which is not supported under Vista). From this point of view, therefore, true Limited User accounts are actually "better" under Windows XP than in Windows Vista because, with Windows XP, a Limited User can use runas or MakeMeAdmin to invoke an Administrative instance of explorer. I'm not convinced that the approach taken with UAC was the best, i.e. "constraining administrators" as opposed to getting people to be members of only the Users group (i.e. a true Standard User). I note that your post above includes the statement: "If you are a member of the Administrators group on Vista, it's effectively the same as being a standard user...." This reinforces my point. Windows Vista encourages people into the Administrators group. This should be turned around, i.e. "If you're a Standard User you can escalate to an Administrative context when required by..." I thought that the point of "least privilege" was to get users out of the Administrators group. In this sense, IMHO, UAC has become an enormous "tangent" on the road of least privilege for Windows users. Regards, PatrickAnonymous
September 05, 2009
Unfortunately Windows 7 seems to have changed the rules a bit. Nothing I have found and tried so far seems to get Windows Explorer to run with administrator rights turned on. Has anyone figured out a way to get Windows Explorer in Windows 7 to run with admin rights? Thanks!Anonymous
April 08, 2010
It is not currently possible to run Windows Explorer elevated in Windows 7. See: http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/1798a1a7-bd2e-4e42-8e98-0bc715e7f641/ My answer is to use Explorer++ (http://www.explorerplusplus.com/) -- it even has a privilege level display option. HTH, BillAnonymous
September 19, 2013
I just want to be able to ctrl+shift+esc and load task manger showing all processes. Apparently I need to disable user access control to achieve this. Bit silly. [Aaron Margosis] Don't disable UAC. A couple options: 1) just click "Show processes from all users" when TaskMgr appears. 2) Use Process Explorer instead. You can even make it the TaskMgr replacement so that when you press Ctrl+Shift+Esc, Procexp appears instead.Anonymous
March 20, 2014
In Windows 8.1 I frequently get the error message that "[Application] won't run under File Explorer with Administrator privileges. Please close and reopen File Explorer properly." I have not done anything to change administrator privileges or File Explorer. Can you tell me what is going on and how to fix it? [Aaron Margosis] I can't find any reference to that text anywhere. Are you sure that's the exact message? Also, have you disabled UAC?