UAC: "Run As" like XP from the GUI

It's no secret that basically every enterprise admin is upset that Vista's "Run as Administrator" feature is not a replacement for XP's "Run As" functionality. I've written a few articles that mention the problem: UAC: Local Admin vs. Domain Admin, Welcome back Command Prompt!, UAC: How to elevate anything. In fact I just got off the phone today with a large organization that is taking a pass on Vista - they cited the "Run as Administrator" as one problem that affected their decision.

Well, Mark Russinovich has released a new Microsoft Sysinternals utility called ShellRunAs in an attempt to meet the demand for an XP-like "Run As" command. I've had a chance to play with it so here is my review...

As the name implies, ShellRunAs gets RUN AS to the shell. As a local administrator I am now able to specify other user accounts when running programs - Yay! This is what I need when managing my network but isn't enough when I wish to manage the local Vista machine. The problem is that ShellRunAs is too faithful to the RUN AS paradigm which seems to have been borrowed from the XP days without being updated to reflect the whole Vista reality.

Traditionally under Vista, non-administrators must switch to an administrator account and elevate if they hope to do such things as edit the HKLM registry locations. Naturally Run As Administrator comes into play at this point. But if the non-administrator has any extra rights (like a Power User does), the Run As Administrator command only presents the Consent dialog and offers no opportunity to switch to the desired administrator account. This is the kind of behavior that has lead people to plead for the old RUN AS functionality to be brought back and a place where I now logically tried ShellRunAs. But when I specified to run Regedit as my administrator account it gave me the error "Error launching application: The requested operation requires elevation". Clearly ShellRunAs is allowing me to switch users but is not allowing that user to run elevated. The tool doesn't help me with this particular type of problem.

So I tried another scenario that needs help... Let's pretend that my Power User must maintain or design the Welcome Center. The files for that are stored in C:\Windows\System32\oobe which can only be edited when an administrator is elevated. This time I want to edit a text file by launching Notepad. Run As Administrator still doesn't allow me to specify a different account so I use ShellRunAs and specify the administrator account. It launches with no problems - Yay! I edit the document and attempt to Save. I get the message "You don't have permissions to save in the location - save in Documents instead?" - The same message normal users and unelevated administrators get. Further proof that elevation doesn't occur. There is still no real solution to this kind of problem except to carefully design your environment so that you don't run with multiple tokens on your normal user account (see my past article: UAC: Avoid elevation like the plague!)

For giggles I tried something different. I created a session as my administrator and ran Notepad as a normal user account using ShellRunAs (not a typical scenario - but could happen). I got interesting results - rather than the familiar message about not having rights to save in System32, Vista allowed me to save the document. Even more interesting, Notepad is able to see the file as having been saved but Windows Explorer refuses to show it to me. ShellRunAs is getting Notepad the AppCompat treatment and being redirected to a shadow storage area for System32! How unexpected is that without adequate documentation?

I got other interesting results during my tests. At times I could click Save As repeatedly and get no messages at all - the dialog box would remain as if I had done nothing. It seems ShellRunAs is causing launched applications to receive unexpected messages from the system that it doesn't know how to cope with.

I also had interesting results with my User Profile. Having switched Notepad to another account using ShellRunAs, I was unable to Save As in the new User Files Folder that was shown to me - it just wouldn't allow me into the folder tree. It displayed the entry in the Save As browser but clicking on it got me nowhere. This is because the User Files Folders for my users are redirected to the network. I guess ShellRunAs doesn't ask Vista to make the connection to that redirected location.

Since ShellRunAs is unable to connect to redirected locations and doesn't recognize the Home Folder specified for the user in AD and certainly doesn't map drives defined in a logon script, I see no point in using the product in its default mode. But is has another mode called NetOnly that I quite like. NetOnly seems to give up on the half-hearted attempt of swinging Vista over to a new user profile and just uses the original profile you were already using. This was just fine. It was great for being able to use my network management tools and still have access to the User Profile and mappings of the initial user. I just wish NetOnly had been described in documentation so I didn't have to waste time trying to figure out what it had meant.

This will work well for the scenario where I have a Power User or Local Administrator who needs to switch accounts in order to manage the network with GPMC, etc. (Functionality that Vista did not previously allow.) They can maintain all their existing drive mappings and User File Folder access. They don't even have to expose themselves to the risk of running elevated while doing it either! But don't bother trying to use ShellRunAs for anything local - things just get weird and basically useless. If an administrator wants to do some local over-the-shoulder support for a power user (such as editing the registry), this tool does nothing for them because it is not possible to get an elevated token - there is still no way to do this in Vista without logging the user out or without forcing all users to always enter credentials at every UAC prompt. (It was possible in XP.)

ShellRunAs is one more patch in the patchwork of Vista and there are still many holes in the quilt. We need a proper way to specify the account and token we wish to use when launching a program. We need a solution that works properly with the User Profiles and with the drive mappings. It needs to be easy and exhibit predictable behavior so we don't have to devote our lives to getting the darn thing to work. Keep working Microsoft!

Here are some more observations:

• ShellRunAs continues in the tradition of Run As Administrator and only makes itself available on the context menu for EXE and BAT files. I would still like to have support for files like VBS, HTA, VBA, etc.
• ShellRunAs isn't multilingual - it doesn't display messages in the language of the OS or GUI of the user - only English.
• The NetOnly version of the program doesn't flash up a black CMD window as described, but rather keeps the CMD window open until the called application (such as Notepad) is closed. (This is the clearest indicator that ShellRunAs is a bit of a hack tacked onto the OS rather than a fix to the OS itself - a traditional Sysinternals tool I suppose.)
• The /accepteula parameter is not described on the web page or in the help screen but it is important to know about if the application is to be deployed in an organization. That was almost a deal breaker for me until I found the note at the top of the eula window.
• I have an issue with the right-click context menu... This tool can add one or two entries - giving us a total of three entries - and we still don't have all the functionality we need for specifying accounts and tokens. We need fewer entries - not more. These three and any others to come need to be combined into one command. My XP machine already has such a long context menu that I can't see all of the entries on the screen at once - and it doesn't scroll!
  

One suggestion I've made to Microsoft a couple of times in the past is that Vista's Consent dialog be made more robust. I think it should present the Consent button but also have the fields available in case someone wishes to make a switch to some other account. That seems like the easiest improvement with the biggest benefits while staying true to the original vision of UAC. Although there is currently a great variety of UAC elevation prompts, they are very simplistic and offer very little in the way of flexibility.