Running a program in the context of another user account
Perhaps you know about Microsoft’s effective recommendation for safe computing: Always log in as a limited user account (LUA) and run program that require administrative privileges using Run As command in the context of another a user with administrative account. Windows Vista is the first operating system to put this philosophy into practice, making it default behavior.
In Windows XP or Windows Server 2003, running in context of another user account is easy. In Windows Explorer (or anywhere from Windows Shell, like Open/Save dialog boxes) right-click on an executable file, batch file or MMC file and select the “Run As…” command. A dialog box would appear to ask you the username and password. Using this same dialog box, you can run the program in context of the same user account but using restricted privileges.
You may not know this but you can also run control panel applets and shortcuts of program that are installed by Windows Installer. To do so, hold down the Shift key while right-clicking on them and the context menu will reveal a new “Run As…” command.
The command-line tool,
RunAs.exe, also can be used to run a program in context of another user account. However, I prefer running a Command Prompt using “Run As…” command instead of using
RunAs.exe command-line tool. Both methods allow one to invoke administrative privileges.
There are implications on running a program using Run As methods:
- Not every program can be executed using this method. For example Windows Explorer (not to be confused with Internet Explorer) cannot be run using Run As… command. This is partly because Windows Explorer is a part the Windows Shell. (In fact its the heart of Windows Shell)
Update: In Windows XP, it was possible to exploit a hack to make an Explorer window run in context of another user account at the cost of losing automatic refresh (change notification); Microsoft has taken active steps to close this avenue in the next versions of Windows.
- Running a program using a Run As… command may in some rare cases produce a different result than running it by directly logging in a user-account (say, via Fast-User Switching). The reasons are various but mostly involve dependencies on other system services, programs or inter-process communication methods and the fact that Run As… command relies on a technique called token impersonation.
- Windows Installer packages do not have a “Run As…” command in their context menus. This makes installing .MSI and .MSP files difficult. To run a setup program within an .MSI file in context of another user account, one must use
RunAs.exeto run msiexec.exe with /I switch or a Command Prompt with elevated privileges. (You can manually build a “Run As…” command in the context menu of .MSI or .MSP files but it requires knowledge of registry. I might teach how to do this in the future but I won’t promise.)
As a final note, you might find visiting http://nonadmin.editme.com/ useful.
Posted on 14 August 2007, in Windows Administration and tagged .msi, .msp, administrative privileges, administrator, Command Prompt, impersonation, limited user account, Microsoft Management Console, MMC, Run As, RunAs.exe, standard user account, token, Windows Explorer, Windows Installer, Windows Server 2003, Windows Shell, Windows Vista, Windows XP. Bookmark the permalink. 1 Comment.