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 (32)

  1. Gotcha! says:

    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

    — Aaron

  2. rwx---rwx says:

    > 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.

    — Aaron

  3. rwx---rwx says:

    > 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.

    — Aaron

  4. rwx---rwx says:

    > 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.

    — Aaron

  5. rwx---rwx says:

    > No, the reason I said it seemed uncommon is

    > that you’re describing a per-user install

    > that requires admin permissions.

    The installer sets some registry items that a driver uses.

    Is there an alternative?  If we had source code for the driver, we could force the driver to scan HKEY_USERS and figure out which user wants to use the driver.  A user would be able to put garbage in their own keys without even needing an administrative password, and we’d have to add checks to the driver so it wouldn’t obey that garbage.

    As it is now, a user with administrative privileges is able to put garbage in the part of the registry that the driver uses.  I feel more comfortable this way, only administrators can trick the driver.  I’d like if we we could advise users to make themselves admins just for long enough to install the app.  MakeMeAdmin would still be as convenient as it ever was.

    > being and running as a member of the admins

    > group on Vista is really no different from

    > running as a standard user

    Then I guess you aren’t troubled by the result of the scenario, which my previous comment mentioned.  The product was re-spec’ed as requiring users to be in the administrators group.  Maybe this would be OK for every product — every user being and running as members of the admins group on Vista is really no different from every user running as standard user, until they choose to elevate.  OK, I’m weird, I’m the only one who wishes things could be different.

    @rwx (I hope you don’t mind me calling you by just your first name 🙂

    This installation has both machine-wide and per-user parts.  They need to be factored out, and executed in the appropriate contexts.  If an installation requires MakeMeAdmin (which requires giving the admin password to a standard user) then that’s a bug in the installation program.  Office is one example of the right way to do it:  it’s a machine-wide install, installing to %programfiles%, registering system-wide COM components, etc.  That needs to be done as admin (or via a publishing mechanism like AD or SMS).  When the user runs an Office app for the first time, the remaining per-user parts of the install execute in the user’s context (hence you see the installer dialog).

    Please don’t take what I said out of context:  being a standard user is not the same as being a member of administrators.  Enterprise users should be standard users, and elevation for standard users should be disabled (per the Vista Security Guide).  But if the user is trusted with the admin account, and would be allowed to run MakeMeAdmin on an XP system, then much of the difference goes away.

    — Aaron

  6. rwx---rwx says:

    > This installation has both machine-wide and

    > per-user parts.

    I agree.

    > They need to be factored out

    I don’t think anyone’s going to accept the idea of requiring users to invoke two installers instead of one.

    > If an installation requires MakeMeAdmin

    > (which requires giving the admin password to

    > a standard user) then that’s a bug in the

    > installation program.

    So you want part of the installation step to be done by something other than the installation program.  I suppose theoretically the user could do a RunAs invocation of regedit and manually type the machine-wide settings into the part of the registry that the driver uses.  I don’t think this theoretical possibility is going to be given any practical consideration.

    You describe Office as having a two-step install where the user doesn’t have to perform any specific action to get the per-user part installed, it’s done automatically, only the administrator had to act to perform the original installation.

    Let’s try transplanting that idea.  For the single-user app that I’ve been talking about, the user would still have to do a RunAs, and instead of giving the installer the machine-wide and per-user parts, we want to make the installer entirely machine-wide.  However, we still want to avoid disturbing other users, we just want the delayed automatic per-user bits to occur for this user.  Theoretically, part of the automatic per-user bits can be done in the user’s context.  But part of it is that some of the information that gets written to the machine-wide part of the registry tells the driver something about the user.  So the delayed automatic per-user part would still have to prompt for administrative credentials and then while running as administrator we’d still have to ask the user what their real login username was.

    Remember, the reason why RunAs doesn’t substitute for MakeMeAdmin is that the RunningAs program gets its per-user stuff in the context of the administrative user instead of the original user.  The desired per-user part of the installation is desired to still target the original user.

    > I hope you don’t mind me calling you by just

    > your first name 🙂

    You’re calling me by my other name.  rwx is my other name.  On the other hand, my own name is rwx.  My group name is —.  I’ve been denied posting the facts about what was asserted to be the topic in a famous place.

    @rwx:

    Any program installation that insists on the use of RunAs or alternate credentials is most likely not taking advantage of what the platform offers.  I am not an expert in MSInstaller technology, but I’m pretty certain that it offers a way to factor out per-machine and per-user installation components, and to set up the per-user part to execute the first time the user runs the application.  The user doesn’t have to manually invoke two installation programs.

    If the per-user part requires writing data to a machine-wide location, then perhaps one way to achieve that is for the per-machine install to create the location and set the permissions on it so that the user can write to it.

    — Aaron

    Another option is to do all the machine-wide stuff in the installer, and then have the application itself do the per-user installation parts on first run, since it shouldn’t need elevated permissions to do that (assuming the perms on the HKLM key have already been made user-writable).

  7. Ajay says:

    Thanks for finally addressing Vista.

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

  9. rwx---rwx says:

    > Any program installation that insists on the

    > use of RunAs or alternate credentials is most

    > likely not taking advantage of what the

    > platform offers.

    I sure hope not.  I think it should be enough to assign powerful authorizations to a program once (during installation) but I don’t think it should be enough to do so zero times.  If a program installation can write registry keys in an area used by a kernel-mode driver, without obtaining administrative credentials once during installation, then there’s no point wondering about security.

    > […] [……] (assuming the perms on the HKLM

    > key have already been made user-writable).

    He!! no.  We need the ability to write the appropriate subkeys of HKLM (once during installation) so that the driver can be told about the relevant user, but we sure don’t want every joe blow on the system to overwrite them at will.

    > per-machine install to create the location

    > and set the permissions on it so that the

    > user can write to it.

    OK, that would work IF:  if the privileged part of the installation puts permissions on the relevant keys to enable that one user to write to them.  But which user?  The installer will be running as an administrative account and that isn’t the user to whom we need to set permissions to write the keys.  The installer would still have to ask the user "hey what was your name again" and set permissions for the real, standard, user.  In other words, the problem is still essentially the same.  It doesn’t matter if we’re talking about setting permissions on the keys or writing the values in the keys themselves, we want to write stuff that concerns the real, standard, user, the one who’s really going to use the thing, even though they temporarily typed an administrative password to run the installer.

  10. Hofi says:

    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.

  11. Norman Diamond says:

    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".

  12. Matt says:

    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.

  13. The hidden trick to stopping explorer.exe on Windows Vista cleanly, without terminating it abruptly.

  14. This is the first time I have blogged here about something other than running with least privilege. It&#39;s

  15. Nick says:

    "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."

    And it only took about 10-12 years for MS to work out this was a good thing and they’d been doing it (increasingly) horribly wrong from the start.

    Makes a nonsense of all Billy’s old "seamless integration" drivel, the derived marketing dross, and a bunch of related BS that became the basis of the "DoJ defense".

  16. Yuhong Bao says:

    Well indeed finally removing IE from Windows is getting easier thanks to this.

  17. Yuhong Bao says:

    "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."

    How about using that as the elevation prompt when RunLegacyCplApplet.exe is elevated?

  18. Patrick Rynhart says:

    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

  19. Simon says:

    Just one thought – I’ve dabbled with Vista but haven’t made the switch yet. I have to admit that even though I insist on not using Admin account for day-to-day on XP, the Elevation dialogue in Vista irritates the **** out of me.

    Why does the box have to dim the whole screen and interrupt whatever you’re doing? I habitually do 4/5 things at the same time on a windows PC (I’m currently waiting for an update in SQL to complete as well as downloading some updates, etc…) and I don’t get why a process at the back has to stop *EVERYTHING* to elt me know something ahs tried to change my home page. I’d love a little unobtrusive window that appears (small+topmost or larger and eye-catching) to ask me about elevation.

    Maybe it’s something to do with the way the dialogue is invoked?

    [Aaron Margosis] UAC and a desktop switch does not get invoked for changing a home page — that’s a per-user setting.

    Info on the desktop switch can be found here.

    Note that a task running in the background that wants elevation will not steal focus for the elevation prompt, and instead flash a notification in the taskbar.  More info on that is discussed in this post.

    HTH.

  20. TheJag says:

    One of the things i use RunAs extensively for is completely unrelated to admin previledges.

    Our company does not allow users to run as administrators so we never get the passwords nor do our accounts get added to the administrators list.

    the runas option was very helpful in accessing network resources or accessing email in outlook as another user.

    Our systems were woefully slow so logging off and logging in just to check an email was a pain especially so if you were logging into a system for the first time ( and with bloated desktops getting reimaged regularly your profile would go for a toss after a few weeks anyway).

    I know what you are all thinking. it is easy enough to create a profile in outlook and access another account. the problem arose when we had to get to our network drives (since my network drive is tied to my Login i can access it only when logged into my AD account) it may be to access files or just our PSTs.

    So i right click on the Outlook exe file > run as and choose the second option > type in my login and password (which is a limited user mind you). when outlook launches i need not create any extra profiles on it, just configure my account and i can open my PST from my network drive by just typin in the direct path to it in the file open dialog box.

    This is also useful in accessing several intranet apps that are directly dependent on the logged in account to authenticate. Launch IE using different credentials and quickly type in the address in the address bar an access what ever we need to.

    We used this only really to save the hassle involved in logging off and logging on in a different profile to access stuff just for a few minutes and we could do this only if the logged in person was cooperative but it still saved time. the Run as admin is just plain not viable as we dont have admin passwords.

    and the switch user in domain environment is also not really that much faster but it reduces hassles for the person from whom we borrow the system as his account is left intact.

    This may be really insignificant but i just wanted to add this as a response to aarons comment that the main reason for runas to be used was to run an app with admin permissions.

    Runas is a great way to overcome permissions on network resources in a jiffy. I have used it in some tight situations as well. in one situation, Two teams had assembled for a quality calibration session. One of the auditors logged into the system connected to the projector and started opening the apps and configuring the system, when it was time to open the audio files that were to be audited we realised that the person that was loggedin did not have access to the location where the files were stored. Just a simple runas with another auditors credentials provided us access to the files. no calls to help desk, no permissions to be changed, no hassles. unfortunately i havent found a way to do this in vista(if it is there i havent looked or our systems are not configured to show this option. when we choose run as admin in vista it still evaluates the account for admin rights which fails in our (me and my colleagues) case.

    Oh and if anyone is gonna suggest using a command line utility or some command please remember: no access to an elevated command prompt as we dont have admin rights and also most systems are configured to block the cmd executable.

  21. TheJag says:

    Sorry jumped the gun in posting a reply… I missed that bit about IE and explorer entertaining multiple accounts on the same desktop. switch user helps but you gotta open up everything once again…

  22. Gordon says:

    Great post Aaron,

    I’ve been doing a lot of work trying to design a Vista environment that is useable for our users while still trying to keep UAC enabled.  I have to say that it has been a challenge.  I’m not certain that it will be possible to keep it enabled in the end.

    For our administrative type users, the inability for Explorer.exe to run with the elevated token has caused a lot of heart-ache.  It’s been fun teaching some of the younger chaps how to work in an elevated DOS CMD prompt since that is about the only place they can actually get any of their work done when UAC is doing its thing.  Forcing our admin scripts to launch HTML and VBS files by first opening an elevated CMD window instead of an elevated Explorer window has made things very ugly indeed.

    Currently my answer for everything is "run it from an elevated CMD window".  I wish I had a better answer.  I was hoping to use your tricks published above to get an Explorer window to elevate, but to no avail.  I guess those loopholes have been closed.  Since a few months have passed, I was wondering if you have found any other ways of getting Explorer to go?

    At the moment I’m thinking it might be time to go back to those old 3rd party explorer tools we used in the Win NT days since I should be able to spawn them in their own process.  They should let me copy files and open html type extensions.

  23. Jack says:

    “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.”

  24. Kyle Hamilton says:

    Okay.  I’m on Vista Home Premium.  I need to run chkdsk on my drive, and I’m most comfortable doing that from the command prompt.

    How can I do this?  runas /showtrustlevels shows me that:

    0x20000 (Basic User)

    is the only trust level that is available on my system.

    I’m the computer owner account, I can set things to run with high integrity, I can run things with high integrity, I can get the UAC prompt and just click ‘accept’.

    So what do I do?  How do I do this?

    And what can I do so that I don’t need to upgrade to Business just to be able to do my machine maintenance the way I’m used to?

    [Aaron Margosis]  RunAs.exe will let you run things at the same integrity level, but not higher.  Can’t you just elevate a command prompt and run it from there?

  25. Vince Mancini says:

    I’ve been running Vista Home Premium as a Standard User, and it seems to be perfectly usable.  My initial thought was that the only difference between a standard user account and an administrator account (the regular admin account, not the hidden admin account) is that when it is necessary to elevate the rights for the task at hand, the standard account needs to input an admin username and password, while the regular admin account only needs to click Continue in the UAC dialog. But then I started to notice a few other subtle differences, so I decided to run a few limited tests of my own.  I’ve found that an unelevated standard user account is definitely NOT the same as an unelevated (regular) administrator account.

    This can be seen if you open either regedit or services.msc.  The admin is presented with the UAC elevation prompt, and can then make changes.  On the other hand, the standard user is NOT presented with a UAC prompt, and the standard user is only able to view the settings, and is unable to change them.  If the standard user instead right clicks and selects Run As Administrator, then he is able to make changes.

    So since it is clear that this difference exists, I am wondering what other differences there are between an unelevated standard user and an unelevated administrator.  Of particular interest is whether malware that gets installed on a standard account (whether when elevated or not) is limited in the harm it can do.

    Are there any pages from Microsoft that detail the differences, or can you share what you know?

    Thanks

    [Aaron Margosis]  Great observations and questions.  So, first of all… there are various mechanisms that determine whether an app prompts for elevation when it starts.  The vast majority of apps will be either “runAsInvoker” (app run in the same context as the app that started it), or “requireAdministrator” (prompt for elevation if the app that started it wasn’t already elevated).  There is one more marking, “highestAvailable”, which acts like “runAsInvoker” for standard user and “requireAdministrator” for admin accounts.  Both regedit.exe and mmc.exe are marked “highestAvailable”.  It’s not ideal, and it’s a rare app where such a marking can even be considered appropriate.  Note that they aren’t strictly read-only for std user — anything that the std user is allowed to change can still be changed.  For regedit that would mostly be HKCU; for services.msc (which is actually run by mmc.exe) the user would be able to start/stop any services that granted the user those rights.  (Off the top of my head I don’t remember any.)

    Other main differences between Vista std user and admin, particularly as pertains to security and defense against malware…  As long as you never run anything elevated, risk of unauthorized elevation of privilege through your user session is about the same.  The risk is probably higher for admin than for std user, because the admin’s profile information (preferences etc) is generally writable before elevation and may be consumed by apps that are elevated.  When using a std user account, the elevated app is looking at a different user profile.

    That said, as Mark Russinovich has pointed out, UAC/elevation is not a watertight security boundary, so there is always some risk regardless of whether you’re using a std user or admin account.

  26. Vince Mancini says:

    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.

  27. Vince Mancini says:

    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?

    Thanks

  28. Patrick Rynhart says:

    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,

    Patrick

  29. Bob L says:

    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!

  30. 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, Bill

  31. Frustrated Jonny says:

    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.

  32. Kathryn says:

    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?