"RunAs" basic (and intermediate) topics
In this posting:
- What is RunAs?
- How to use RunAs from the GUI (even if you can’t see it)
- Using RunAs from the command line
- When RunAs won’t work
- Useful RunAs shortcuts and related tips for the non-admin
Did you know that millions of people run as non-administrator every day? It’s true! What do they do when they come to a point where something requires administrator privileges? Simple: they call their helpdesk. And if they ask really nice, a sysadmin makes a note to stop by sometime within the next month. When he arrives, he logs in as administrator and performs some magical administrative tweak that renders the user’s computer unbootable. “Oops!” Of course, that’s not really true. The sysadmin can now log in remotely to render the user’s computer unbootable, without even leaving his desk! (I’m sure there’s research going on somewhere about how remote administration is contributing to increased sysadmin obesity.)
If you are your own helpdesk (i.e., you administer your own machine), how do you run something with admin privileges? Fast User Switching is the best option (see previous blog entry), but it isn’t available in Windows XP if your computer is joined to a domain. You can log out, shutting down all your apps, and log back in as administrator. Sometimes that will be necessary (I needed to do that when installing the beta of Microsoft Office 2003), but most of the time logoff is more disruption than necessary. At these times, the Secondary Logon service is your friend, typically exposed through RunAs.
The Secondary Logon service was first introduced in Windows 2000, and is in Windows XP and Server 2003. When you start a new process through RunAs, you provide credentials for the account you want the process to run under – for example, the local Administrator account. Assuming the credentials are valid, the Secondary Logon service then causes several things to happen:
- creates a new logon session for the specified account, with a new token;
- ensures that the new process’ token is granted appropriate access to the current window station and desktop (the specifics change somewhat for XP SP2, but aren’t important here);
- creates a new job in which the new process and any child processes it starts will run, to ensure that the processes are terminated when the shell’s logon session ends (correcting a problem with the NT4 Resource Kit’s SU utility).
Is this description too nerdy? The net is that it lets you run programs as a different user on the same desktop with your other running programs. The new process and (generally) any programs it starts will run under this new account.
The “How to develop code as a non-admin” item in Keith Brown’s upcoming book, A .NET Developer's Guide to Windows Security, covers some of the same ground I’m covering here. We cover the details differently and offer different tips, though, so you should read us both!
RunAs GUI, in Windows XP and Server 2003:
In Windows Explorer or the Start menu, right-click on any Application (.exe) or Microsoft Common Console Document (.msc) file or shortcut, and choose “Run As…” from the context menu. In the “Run As” dialog, choose the 2nd radio button (“the following user”) enter the user name and password for the account, and click OK. (I’ll discuss the first radio button and the “protect my computer and data…” option in a future post.)
I said “any”, but that’s not quite true. If the shortcut is a “special Microsoft Windows Installer link”, you’ll need to hold down the Shift key while right-clicking to get Run As on the menu. (Don’t ask me why. It’s better than in Windows 2000, where you never saw Run As on the right-click menu unless you pressed Shift.) On my Start menu, these “special” shortcuts include Adobe Reader 6.0, MSN and Windows Messenger, and MapPoint 2004.
The “hold down Shift” trick is also needed to get Run As on the context menu for most Control Panel shortcuts – specifically those that link to a .cpl file. RunAs doesn’t work for all Control Panel items, though. Some of them, such as Folder Options, Fonts, Network Connections, and Scheduled Tasks, actually run within Windows Explorer, which by default doesn’t play well with Run As. More on that in a future post.
There’s also a little problem with the Power Options applet. According to Keith Brown’s analysis (no longer online? I can’t find it), when you click OK or Apply, it writes both per-machine and per-user settings. If you are a normal User, it quietly fails when writing the per-machine settings and never writes the per-user settings. (As of XP SP2 RC1, this is “fixed” in that it at least tells you that it failed to save the settings.) If you use RunAs to run it as the local administrator, the per-user settings it writes are those of the administrator account, not your user account. Sadly, to change your own power settings, you need to be an admin. (This is addressed by my MakeMeAdmin script, which I’ll describe in an upcoming post. Stay tuned!)
You can avoid the right-click context menu and make “Run as…” the default action for a particular .exe or .msc shortcut by opening its Properties dialog, clicking Advanced, and checking “Run with different credentials”. When you invoke the shortcut, you’ll get the RunAs dialog, and the shortcut’s target will run under the account you specify.
RunAs from the command line:
RUNAS.EXE is a console (a.k.a., “text mode”) application that prompts for alternate account credentials and starts a new process under that account. Console applications are often started from a cmd.exe command prompt, but they can also be started from the Start/Run dialog or from an Explorer shortcut.
RUNAS.EXE offers more flexibility than the GUI, including the ability to authenticate with a smart card, to use the account only for network authentication but continue to use your current account locally, and to control which profile and environment to use. Type “RUNAS” without parameters at a command prompt to see its command line options. Look up “runas” in Windows XP Help and Support for more info and examples.
When RunAs won’t work:
A common source of frustration and confusion is to start an application with RunAs, only to find that it is continuing to run in your original logon session. (First, how do you tell? My favorite tool here is Process Explorer from SysInternals. Add “User name” to the displayed columns. Starting with v8.30, ProcExp no longer requires admin privs – thanks, Mark! Also look for my PrivBar utility in another upcoming post.)
The problem is that when started, many applications – such as MS Word and Windows Explorer – look on the current desktop for an already running instance of itself. If found, the new process will send a message to the previous instance to handle the request and then exit. That previous instance will often be running under the account you originally logged on with, not that of your alternate credentials. A similar effect occurs when a new app is not started directly by the parent app, but is instead started through the shell, via ShellExecute[Ex] or through DDE. The new process then inherits the security context of the shell, and not of your alternate account. The cmd.exe start command will do this in certain circumstances.
I promise to discuss how to get Windows Explorer to play nicer with RunAs in a future post. In the meantime, Keith Brown’s “How to develop code as a non-admin” describes how you can use Internet Explorer to achieve some of the same results (search the item for “But I hate the command prompt!”).
Some tips and tricks:
I really like Keith’s recommendation to change the background bitmap for your admin IE, but there’s an easier way to do it: the TweakUI Power Toy. Run it as admin and navigate to Internet Explorer \ Toolbar Background. And here’s a bitmap I like to use.
Many people like to keep a cmd.exe shell running as local admin. To reduce the possibility of mistakes, I strongly advise making it obviously different from your normal command shells. The easiest, one-time setup is to click on the admin shell’s system menu, choose “Defaults” and change the colors. This is a per-user setting, so all future console windows running as local admin will appear in the colors you choose.
Another way is to specify distinguishing characteristics in the cmd.exe command line. For example:
cmd.exe /k cd c:\ && color fc && title ***** Admin console *****
The /k option says to run the commands that follow, and not exit after running them. (FYI, /c runs the commands and then exits.) The commands that are executed change the current directory to the root of C: (somewhat safer than being in the system32 folder), the color command changes the console’s color to light red on bright white (run “color /?” to see other choices), and the title command changes the window title to something distinctive. I keep a shortcut in my Quick Launch bar that invokes runas with that command line.
Yet another way, suggested by MS employee John Lambert (NT), is to associate a custom icon with the shortcut. The icon will appear in the Alt-Tab window, the taskbar, and of course the upper-left corner of the cmd window itself. Note that this works only with a cmd.exe target, and you need to use the GUI RunAs option, not the runas.exe console app. Here is an icon you can use.
The admin command shell is a popular way to start apps with elevated privileges. You don’t have to be a total nerd to enjoy its power, though. Examples:
Windows Installer Packages (.msi files) don’t offer a RunAs context menu option. You might be able to get away with hacking the registry to add that option, or you can just run the .msi file directly on the command line of your admin shell.
In general, the command shell recognizes file associations, so you can invoke a data file on the command line and it will start the associated application.
You can start Control Panel applets from the command line just by typing the name of the .cpl file. Some examples:
Start “Date and Time Properties”:
C:\>timedate.cpl
Start “Add or Remove Programs”:
C:\>appwiz.cpl
Start “System Properties”:
C:\>sysdm.cpl
To start Internet Explorer from the command shell, you can type the full path ("C:\Program Files\Internet Explorer\iexplore.exe" – rather a PITA even with command completion). I just keep an ie.cmd file in a folder in my path (posted here as a .txt – just rename it to .cmd). It starts IE, and takes an optional URL parameter. E.g.,
C:\>ie blogs.msdn.com
That will have to do for now. Please continue to post comments, and I’ll try to get everything addressed.
