Aaron Margosis' "Non-Admin" and App-Compat WebLog : Vista/Win7

LUA Buglight 2.1 released

Aaron Margosis — Tue, 03 Nov 2009 21:37:00 GMT

LUA Buglight 2.1, identifies admin-permissions issues ("LUA bugs") in desktop applications. New version supports Windows 7 (x86 and x64), Vista (x86 and x64), XP (x86 only) and corresponding Server OSes.

The download and more information is on this page:

http://blogs.msdn.com/aaron_margosis/pages/LuaBuglight.aspx

Live, on the internet...

Aaron Margosis — Tue, 16 Jun 2009 05:57:00 GMT

Ahoy, all -- Later this week I'll be appearing at a virtual roundtable hosted by Mark Russinovich, streaming live over the web. The topic is Windows 7 application compatibility. Among other things, I'll be demoing the latest (still-unreleased) updates to LUA Buglight (latest released version here).

Here are the details:

Springboard Series Virtual Roundtable

Windows 7 Application Compatibility: Your Questions Answered (Part 1)

Date: Thursday, June 18

Time: 11:00am Pacific Time

https://ms.istreamplanet.com/springboard

Windows 7, is approaching fast and from the application standpoint is very similar to Windows Vista. We’re going to examine Windows 7 application compatibility not only from the perspective of moving from Windows Vista, but also for those coming from Windows XP. Join us to discuss the most common challenges around application compatibility when coming from a legacy operating system, why changes were made along the way, compatibility technologies inside the OS and methods for getting incompatible applications to run on Windows 7. Along the way we share tips and tricks, demonstrate free tools to analyze and fix applications and answer your specific questions about application compatibility live.

In Part 2 of this Virtual Round Table discussion (planned for later this Summer/Fall), we’ll discuss the options and approaches for using virtualization tools In depth to address application incompatibilities – including presentation virtualization, desktop virtualization and application virtualization. We’ll be sending out more details and posting information to www.microsoft.com/springboard for part 2 as the dates are finalized.

As part of the “virtual” experience, you may submit your questions about Windows 7 Application Compatibility to the panel live during the event—or submit questions in advance to vrtable@microsoft.com.

Springboard Series: The resource for Windows desktop IT professionals

FAQ: How do I start a program as the desktop user from an elevated app?

Aaron Margosis — Sat, 06 Jun 2009 07:19:00 GMT

Common Vista/Win7 scenario: the app you’ve written runs with elevated permissions, but then needs to start another program as the non-elevated desktop user. For example, you want to display web content. Now, you could just launch the web browser from your app, and let the web browser run as admin. What could go wrong? (Hint: the correct answer will include the word “catastrophic”)

A very common mistake that programmers make is to grab a copy of the elevated, High Integrity Level access token from the current process and then “dumb it down”. I.e., disable powerful group memberships, remove powerful privileges, and change the integrity level to Medium. They then launch the new process with that “dumbed down” token. This breaks for a number of reasons.

The new “LUA bug” of Vista/Win7

First and foremost, that approach makes the invalid assumption that the elevated app is running under the same user identity as the desktop user who originally logged on. This is the new “LUA bug” of Vista and Win7. (Refresher: “LUA” = “limited user account”; “LUA bug” = failure that occurs when running as LUA and not administrator. #1 cause of LUA bugs: assumption that the end user will be an administrator.) In Vista/Win7, everything runs as “LUA” by default, unless you specifically allow something to run elevated. If you’re a member of the Administrators group, by default this involves a simple “consent” prompt. The resulting app still runs as you, but with full admin rights. If you’re not a member of Administrators, the elevation prompt requires the credentials of another account that is a member of Administrators. The resulting app then runs as a different user. A number of apps fail to take this second scenario into consideration. “Dumbing down” the current process token is one example of that kind of failure. The new program runs with reduced permissions, but not as the intended user.

There are at least a couple of other failures in that approach too, that are more obscure. Let’s say you are a member of Administrators. When you log on, the Windows LSA (Local Security Authority) generates two access tokens in two separate LSA-managed logon sessions. One is the fully privileged, full-admin token; the other is the standard-user version, which is marked as linked to the full-admin token. When you create a “dumbed-down” copy of the elevated one, the new token is still associated with the elevated session, and marked as being the “high half” of a split token. As a result, if you start Internet Explorer with that token, Protected Mode will be disabled. Also, if your “dumbed-down” process tries to launch an elevated app, it will simply launch the new process with the “dumbed-down” token, since it’s already marked as “elevated.”

“Enough nerditude. Tell me what I need to do.”

So here’s one sequence that works well:

Enable the SeIncreaseQuotaPrivilege in your current token (sample)
Get an HWND representing the desktop shell (GetShellWindow)
Get the Process ID (PID) of the process associated with that window (GetWindowThreadProcessId)
Open that process (OpenProcess)
Get the access token from that process (OpenProcessToken)
Make a primary token with that token (DuplicateTokenEx)
Start the new process with that primary token (CreateProcessWithTokenW)

I’ve attached an example C++ project, built with VS2008 and the MFC AppWizard, and tested with x86 and x64 builds. The meat of the sample is in RunAsDesktopUser_Implementation.cpp. I’m sure it can be done in managed code, but that will be someone else’s project, not mine.

Caveats

Please note that there are a bunch of caveats about this approach:

This runs the new program in the same context as the desktop shell. If the desktop shell process is not running (crashed or intentionally terminated), GetShellWindow fails, and there is no process token to do anything with. Also, GetShellWindow fails if the default shell (Explorer) has been replaced with a custom shell.
If you have terminated the desktop shell and restarted it elevated (strongly discouraged), then the new process will also run elevated – as will pretty much everything else you start.
This code assumes that it is running already elevated. If you’re not running elevated, then there is no need for this code. If you’re not running as admin, then the necessary step of enabling SeIncreaseQuotaPrivilege won’t work anyway.
CreateProcessWithTokenW requires Vista or newer. So: this approach won’t work on pre-Vista (e.g., XP with runas); and if you want to incorporate this code in a program that can run on XP/2003, you need to use LoadLibrary/GetProcAddress to get the CreateProcessWithTokenW entry point.

The Return of PrivBar (x86 and x64)

Aaron Margosis — Fri, 15 Aug 2008 09:17:00 GMT

I recently switched internet service providers, not realizing when I did that PrivBar and MakeMeAdmin would suddenly disappear from the internet when they un-provisioned my space on their servers. Oops.

To try to compensate you for the inconvenience, PrivBar is now available once again, now in x86 and x64 versions. So if you are running an x64 version of Windows (XP or higher), you can now use PrivBar in all Explorer and Internet Explorer windows. (It will also tell you whether that particular instance is running 32-bit or 64-bit code.)

Note that by default on x64, Explorer.exe is 64-bit, but IE is 32-bit; but there are, in fact, 32-bit and 64-bit versions of both programs. A 32-bit process can load only 32-bit DLLs, and a 64-bit process can load only 64-bit DLLs. The main IE icons you see point to the 32-bit versions, because the vast majority of IE add-ons, ActiveX controls, etc., are 32-bit: the 64-bit version of IE cannot load those ActiveX controls, so sites like youtube don't do much.

Click here for the PrivBar binaries; click here if you want the slightly-updated source code and Visual Studio 2008 project files.

Instructions:

Extract PrivBar.dll from the zip file and put it somewhere where all users have Read access to it. If you're running an x64 version of Windows, extract PrivBarX64.dll to the same location.
At a command prompt running as admin, run
regsvr32 path\PrivBar.dll
where path is the folder location to which you extracted PrivBar.dll. If you're running x64, do the same with PrivBarX64.dll. Note that you have to be running as (fully-elevated) admin in order to do this, and that trying to register the x64 version on 32-bit Windows will fail.

No need for the extra .reg file anymore. You can now enable the bar in Explorer or in IE by choosing View / Toolbars / PrivBar, as before.

(BTW -- MakeMeAdmin is back online, too.)

LUA Buglight 2.0 - preview

Aaron Margosis — Fri, 13 Jun 2008 07:04:00 GMT

Attached to this blog post is a PREVIEW VERSION of LUA Buglight 2.0. LUA Buglight is a utility that helps identify "LUA bugs" in desktop applications -- the bugs that appear when the application is run as a standard user instead of as an administrator.

Some of the improvements in LUA Buglight 2.0 over its predecessor:

Much better Vista support
Streamlined UI and improved flow
Identifies more bugs
On XP, not restricted to using a local account to create the admin context
On Vista, prompts for elevation just one time per session instead of for each test
User options saved to the registry

There are more improvements and refinements that I want to make, but I think you'll find it is quite usable now. And I promised some audiences here at Tech*Ed that I would post a preview version here prior to my Friday morning session introducing LUA Buglight 2.0. :-)

Note that I haven't written up new documentation yet, and that these binaries have not been signed yet.

Update, June 14: Yes - meant to mention - LUA Buglight is designed only for x86. I'll add a processor check on startup.

Update, November 6: Removing the attachment, because the Second Preview version is now available here.

How to cleanly stop Explorer.exe on Windows Vista

Aaron Margosis — Wed, 18 Jul 2007 00:08:00 GMT

This is the first time I have blogged here about something other than running with least privilege. It's about a neat trick, though, that can be useful for some people.

If you need to shut down the main Explorer process, you could just kill it from Task Manager or Process Explorer. But undesirable and unpredictable things can happen when you abruptly kill any process, particularly one as central as Explorer.

In Windows XP, you can get Explorer to exit cleanly by getting to the shutdown dialog (e.g., Start / Turn Off Computer, or Start/Shutdown), then hold down the Ctrl+Alt+Shift keys and click the "Cancel" button. (Ref: JeffDav's blog.)

In Windows Vista with its standard Start Menu, click on the Start button. Hold down Ctrl+Shift and right-click on any empty area of the menu or on the power/lock buttons at the bottom of the right half of the menu. One of the context menu choices is "Exit Explorer". Choose this and the main Explorer process will cleanly shut itself down. (Thanks to Mike Sheldon and Raymond Chen for this tip.)

If you are using the "Classic Start Menu" option in Vista, the XP Ctrl+Alt+Shift+Cancel method still works.

OK, so chances are right now you're looking at nothing but wallpaper and the Sidebar and wondering, "What do I do now?" There's no Start menu anymore, and Win+R doesn't display the Run dialog. Answer: press Ctrl+Shift+Esc. This starts Task Manager. In Task Manager, choose "File / New Task (Run)", type "Explorer" and click OK. The shell will come back to life.

Note that on both Windows XP and Windows Vista, only the "main" Explorer process exits – that is, the process that manages the Start menu, taskbar, and desktop. With default settings, all Explorer folder windows are managed by that process as well, and so they will close too. However, if you have configured Explorer to "launch folder windows in a separate process", then those folder windows will not close when you apply this trick. Furthermore, when I tried this on Windows XP, I needed to manually close all those folder windows before running a new instance of Explorer would display the taskbar, etc., instead of just displaying yet another folder window.

Why is this hidden nugget even there? Its purpose is to help developers and testers who work on shell extensions to be able to stop and restart Explorer quickly and cleanly without having to log out.

Obviously, though, this trick can also be used to launch Explorer elevated. If you've exited the shell process and start Explorer from an elevated context, the entire desktop shell will run elevated. I cannot say this without adding caveats. If you do this, everything you start from this point on will run elevated. Shell extensions will run elevated, including the ones with serious security flaws. If you shut down Explorer again, any child processes that were launched will continue to run elevated, including browsers, IM clients, etc., with all the risk that incurs. IE Protected Mode does not operate when IE is running elevated. Less important but also significant is that any processes running at Medium IL will not be able to interact with the elevated shell – for example, to display taskbar notification icons. In general, because Explorer was neither designed for nor tested with this kind of elevated execution, you should not assume that anything will work correctly, including something as fundamental as user logoff. If you really need an elevated Explorer window on Vista, you can try the unsupported trick I described in this post instead of elevating the entire shell.

Scripting Elevation on Vista

Aaron Margosis — Sun, 01 Jul 2007 08:29:00 GMT

[Added 2007-07-02, 16:41 Eastern Time: I was thoroughly and inexcusably remiss in failing to include a reference to Michael Murgolo's excellent TechNet Magazine article, Script Elevation PowerToys for Windows Vista. I'm rectifying that now.]

As I mentioned recently, although the RunAs.exe console utility still exists on Windows Vista and will let you run a program as another user, it will not run that program with elevated privileges. So if you use RunAs.exe to start a program with an administrator account, the program will run with that account's profile and settings, but with standard user privileges only, not with the power to do computer administration. You can't get an application to run with elevated privileges unless you go through the UAC elevation prompt. And RunAs.exe on Windows Vista (RTM, anyway) will not invoke that prompt.

What if you have batch files for XP or Server 2003 that called RunAs when administrative tasks needed to be performed? E.g., say there's a line in your batch file to start CMD.EXE with elevated permissions that looks like this:

runas /u:Administrator "cmd.exe /t:fc /k cd /d c:\ && title *** Admin console *** "

Is there another way to script the "run this program with elevated permissions" that RunAs gave you on XP/2003? Yes. First, create a small script file called "elevate.js" and put it in a folder in your PATH. (*) The contents of elevate.js should look like this:

// elevate.js -- runs target command line elevated
if (WScript.Arguments.Length >= 1) {
    Application = WScript.Arguments(0);
    Arguments = "";
    for (Index = 1; Index < WScript.Arguments.Length; Index += 1) {
        if (Index > 1) {
            Arguments += " ";
        }
        Arguments += WScript.Arguments(Index);
    }
    new ActiveXObject("Shell.Application").ShellExecute(Application, Arguments, "", "runas");
} else {
    WScript.Echo("Usage:");
    WScript.Echo("elevate Application Arguments");
}

Then replace "runas /u:Administrator" with "elevate": (**)

elevate cmd.exe "/t:fc /k cd /d c:\ && title *** Admin console *** "

Important note: the elevate.js script invokes the UAC prompt, but it will not let you bypass it. User interaction is still required.

With the default settings, the elevation prompt will prompt you for simple consent (click "continue") if you are a member of the Administrators group, and prompt you for admin credentials if you are running as a standard user. If you are a member of the Administrators group, but would like to use a different account for the elevated task, you can change the computer's security policy for the behavior of the elevation prompt for admins to "Prompt for credentials". When the prompt appears, you can enter the credentials of a different administrative account.

Thanks to John Stephens of the Windows team for this script.

(*) I highly recommend that scripts and other programs that may be used by elevated apps or are part of elevation sequences be kept in a folder that standard users cannot write to. I have a Utilities folder under %ProgramFiles% for this purpose.

(**) Note that the quoting in this case needed to be rearranged a little as well: the first item passed to the script is the application to elevate; everything after that forms the rest of the command line for that application. If the quoting had been kept as-is, Windows would have tried to elevate an application called "cmd.exe /t:fc /k …", which doesn't exist. The quotes are still needed here so that the "&&" and everything after it remain on the command line to the elevated application. Otherwise the current command shell will parse it as part of the command it is running.

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

Aaron Margosis — Sat, 30 Jun 2007 06:20:00 GMT

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

"We want our application to run elevated automatically without prompting the user."
"I don't get why I can't authorize an application ONCE and be done with it."
"Unix has setuid root which lets you run privileged programs securely."

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

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

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

The "standard user by default" vision would become impossible and ultimately never happen;
Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.

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

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

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

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

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

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

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

Nitpicker's corner (***)

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

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

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

And so this is Vista…

Aaron Margosis — Thu, 28 Jun 2007 21:28:00 GMT

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.

Follow-up on "Setting color for all CMD shells based on admin/elevation status"

Aaron Margosis — Thu, 28 Jun 2007 04:49:00 GMT

[Updated, 2007-06-27]

This is the (overdue) follow-up to my earlier blog post about setting the color and title of all CMD windows based on the admin/elevation status of that window.

First of all, as some commenters noted -- and as I had discovered as well -- having the COLOR command run in the CMD autorun causes strange build failures in Visual Studio (at least in C++ projects) when it invokes commands via CMD. My workaround is to specify the COLOR command only in the branch that I don't run Visual Studio in. E.g., I always run Visual Studio as a non-admin, so I keep the "COLOR FC" statement in the admin branch, and don't run any COLOR statement in the non-admin branch. If you always build as an elevated/admin, then you should reverse that so that the COLOR statement runs in the non-admin branch -- or don't use COLOR to differentiate and instead just use TITLE.

[Added 2007-06-27] It turns out that following COLOR with a single ampersand and another command makes the build problem go away!

Second, Pavel suggested a more portable test than bootcfg/bcdedit: cacls.exe %windir%\system32\config\systemprofile. That folder grants access only to Administrators and the SYSTEM account; cacls.exe fails with "access denied" unless you're running as elevated/admin. I don't know whether that folder exists on Windows 2000, but the test definitely works on XP, 2003, and Vista.

[Added 2007-06-27] But as "anonymous" points out in the comments below, FSUTIL works, too, and is a lot easier to type.

Third: CMD on Vista already prepends the word "Administrator" in the window title if it's running with an enabled Administrators SID in its token, so it's redundant for the autorun to append it. (Not true on XP/2003, of course.)

Fourth: why not put the current username into the title as well? Good idea! I've added that to my current config.

So, now my current CMD autorun looks like this: [Updated 2007-07-05 with full path to FSUTIL]

%windir%\system32\FSUTIL.exe > nul 2> nul && (color FC & title %USERDOMAIN%\%USERNAME%) || (color 07 & title NONADMIN - %USERDOMAIN%\%USERNAME%)

One minor point is that unlike the CMD /T option, COLOR sets only the current color -- not the default color -- for the current window. If you run the COLOR command in that window, it will revert to the default color for the window -- either the user account's default setting or that set by a /T option when the CMD was started.

So... let me go on record by saying that while Microsoft has made a lot of fine products, Windows PowerShell is the coolest and most revolutionary technology we have shipped in a very long time. (But that's as off-topic as I'm going to get on the subject.) PowerShell is gradually becoming my default command shell, so naturally I'd like to be able to distinguish between elevated and non-elevated instances, both with color and with the window title. Starting with what commenters wrote on my previous post, here's what's in my $profile now:

function Get-AdminStatus
{
    $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
    $p = New-Object System.Security.Principal.WindowsPrincipal($id)
    return $p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
}

$AmIAdmin = Get-AdminStatus
if ( $AmIAdmin )
{
    cmd.exe /c COLOR FC
}

# Make the window title follow the current directory
function prompt
{
    'PS ' + $(Get-Location) + $(if ($nestedpromptlevel -ge 1) { '>>' }) + '> '
    if ( $AmIAdmin )
    {
        $host.UI.RawUI.WindowTitle = "Administrator: " + $(Get-Location)
    }
    else
    {
        $host.UI.RawUI.WindowTitle = $(Get-Location)
    }
}

Setting color for all CMD shells based on admin/elevation status

Aaron Margosis — Fri, 23 Feb 2007 07:44:00 GMT

In my RunAs... and MakeMeAdmin posts, I recommend making your admin command shells visually different to set them apart from non-admin ones. You can change the default console window color on a per-account basis, but that doesn't help when the same account may be used in both admin and non-admin contexts (such as with Vista's UAC admin-approval mode). You can use the cmd.exe /T command-line option, or its built-in COLOR command, but it works only if you remember to use it each and every time.

Here's a way to make the differentiation happen with a one-time, one-line configuration change on your system, that will work on all CMD.EXE shells you run. The idea is to run a non-destructive command that requires admin privileges from a CMD autorun location, test for success and set the console's color accordingly. You can also change the title at the same time.

This can probably use some refinement. For the non-destructive admin operation on Windows XP/2003, I suggest "bootcfg /query"; on Windows Vista, I suggest "bcdedit /enum". The autorun location I've been playing with is:

    [HKLM\Software\Microsoft\Command Processor]
    "AutoRun" (REG_SZ)

The command syntax you can set the "AutoRun" value to for Windows XP/2003 is:

    bootcfg /query >nul 2>nul && (color FC && title ADMIN) || (color 07 && title NONADMIN)

and for Windows Vista, set it to:

    bcdedit /enum >nul 2>nul && (color FC && title ADMIN) || (color 07 && title NONADMIN)

Any output or error message is redirected to "nul" so you don't see it. If the command succeeds (&&), you're running with admin/elevated privileges; the console color will change to bright-red-on-white (FC) and the title changed to "ADMIN". If the command fails (||), the console color will be white-on-black (07) and the title changed to "NONADMIN". Feel free to change the colors or titles to suit your taste.

All that stuff works only for CMD.EXE. For Windows PowerShell, take a look at these:

http://www.interact-sw.co.uk/iangblog/2007/02/09/pshdetectelevation
http://www.leastprivilege.com/AdminTitleBarForPowerShell.aspx

Also for PowerShell -- Staffan Gustafsson converted MakeMeAdmin to a PowerShell script:

http://groups.archivesat.com/Windows_PowerShell/thread246430.htm

[2007-06-25: Update posted here.]