Use Run As to protect your administrator workstation from Trojans and other nasties.
If you're lazy, like I am, you probably use the default administrator account on your desktop workstation for browsing the Web, checking your email, and managing the servers on your company's network.
Not a good idea.
What if you unknowingly visited a web page that executed a script that downloaded a Trojan to your machine? Your administrator account would be compromised, and the attacker would have total access to your workstation and possibly to your whole network! To avoid such dangers, administrators should always have two user accounts: a regular (user-level) account for ordinary activities, such as web browsing and messaging, and an administrator-level account, used only for performing administrative tasks. This way, when you are reading your email and suddenly remember you have to reschedule a backup, you can simply log off, log back on using your administrator account, perform the task, log off again, and log on again as a regular user.
Who am I kidding? That's too much to expect of a lazy system administrator.
The Run As service (called Secondary Logon service in Windows Server 2003 and Windows XP) is a hack designed to enable you to run programs by using alternate credentials while you're logged on using another account. For example, if you are an administrator and are logged on to your desktop using your regular user account, you won't be able to run administrative tools such as Computer Management, because they require administrator credentials to run properly. (Actually, you can open Computer Management as an ordinary user; you just can't do much with it.) Using Run As, however, you can run Computer Management as an administrator while remaining logged on as an ordinary user.
There are two ways to use Run As: using the GUI or from the command line. To use the GUI method, first find the program you want to run in Windows Explorer or My Computer. Then, for executables (*.exe files), hold down the Shift key, right-click the program's icon, and select Run to open the Run As Other User dialog box shown in Figure 1-1. For MMC consoles (*.msc files) and Control Panel utilities (*.cpl files), you do the same thing but don't need to hold down the Shift key.
Once you specify the appropriate alternate credentials and click OK, the program you selected runs in the security context of those alternate credentials until you close or terminate the program. If you prefer, the alternative credentials can also be entered as domain\user or user@domain, which in Figure 1-1 would be MTIT\Administrator or Administrator@mtit.com for an example domain named mtit.com (replace these credentials with the name of your own domain). The advantage of doing it the way shown in Figure 1-1 is that, if your computer is a member server, you can specify a local user account by entering the name of the computer in the Domain field.
Using Run As from the command line is just as easy, but you need to know the path to the program (unless the program file is located within the system path). For example, the Computer Management console file compmgmt.msc is located in the \system32 directory. To run it as Administrator in the MTIT domain, simply type the following at a command prompt:
runas /user:MTIT\Administrator "mmc %windir\system32\compmgnt.msc"
You'll be prompted for a password for the account, after which Computer Management will open. Note that you can also type this command directly into the Run box (accessed by StartRun).
While Run As is useful, it has some limitations. First, the alternate credentials you specify must have the Log On Locally user right on the computer. Since Run As is usually used with administrator credentials (which have that right by default), this is usually an issue only in certain circumstances. For example, say you grant a few knowledgeable users a second user account that belongs to the Power Users group, to allow them to update device drivers and perform other minor maintenance on their desktop computers. If you try to reduce the attack surface of your network by removing the right to Log On Locally from the Power Users group using Group Policy, then these users won't be able to perform such tasks.
Also, there are certain tasks you can't perform directly using Run As, such as opening the Printers folder to administer a printer that is connected to your machine. The reason for this is that the special folders such as Printers and Network and Dial-up Connections are opened indirectly by the operating system, not by a command. You also can't use Run As to open Windows Explorer and access the filesystem on your computer as administrator, because the Windows shell explorer.exe is already running as your current desktop environment and Windows allows only one GUI shell to run at a time.
Finally, Run As also might not work if the program you are trying to run is located on a network share, because the credentials used to access the share might be different than the credentials used to run the program.
Most limitations have workarounds of some sort, if you try hard enough to find them. So, let's see if we can figure out ways to get around these limitations (except for the Log On Locally limitation, which is absolute).
Say you want to change some settings for the Local Area Connection in the Network and Dial-up Connections folder. If you try doing this as an ordinary user, you'll get a message saying "The controls on this properties sheet are disabled because you do not have sufficient privileges to access them." Here's how to access these settings as an administrator without logging out of your regular account. Right-click on the task bar and open Task Manager. Then, switch to the Processes tab, select explorer.exe, and click End Process to kill the desktop but leave Task Manager running. Now, switch to the Applications tab, click New Task, type runas /user:MTIT\Administrator explorer.exe to run the Windows Explorer shell in an administrator context, and click OK. Finally, move Task Manager out of the way and type your password into the command-prompt window.
A new desktop will now appear, running in the security context of your administrator account. You can now change the settings of your Local Area Connection, modify the properties of a printer in the Printers folder, browse the filesystem, or do anything you want to do as administrator. But be sure to leave Task Manager running, because it is your only connection to your original desktop! You can minimize it so it won't be in the way.
Once you're finished performing your administrative tasks, you can return to your original desktop (the one running under the security context of your regular account) as follows. Maximize Task Manager so that you'll have access to it when your desktop disappears again. Then, to log off of your administrator session, click StartShut Down and select Log Off.
Your administrator desktop has now disappeared, but Task Manager is still running (in the security context of your regular account), so switch to the Applications tab, click New Task, type runas /user:MTIT\Administrator explorer.exe, and click OK. Your desktop has returned.
At this point, you might ask, "Why should I go to all that trouble? It would be faster just to log off as a regular user and log on as an administrator." True, but any applications you have running as a regular user would then have to be terminated. Doing it the way shown here, however, leaves all your desktop applications running in the background.
Here's how to get around the limitation of running programs from network shares with appropriate credentials. To run a program named test.exe found in the TOOLS share on server SRV230, use StartRun to open a command-prompt window as administrator, type runas /user:MTIT\Administrator cmd to open a command shell in administrator context, and then map a drive to the shared folder by typing net use Z:\\SRV230\TOOLS. Now, switch to the Z: drive and run the program as desired. This lets you connect to the shared folder using domain administrator credentials and run the program under the same credentials. This approach is also useful for installing applications from a network distribution point.
To make your life easier, instead of having to type stuff at the command line, you can use Run As to create a shortcut that will run a program under alternate credentials. For example, to run the Computer Management console from a Run As shortcut, right-click on your desktop, select NewShortcut, and type %windir%\system32\compmgmt.msc as the command string. Name your shortcut Computer Management and click OK. Then, right-click on the shortcut, select Properties to open its properties sheet, and on the Shortcut tab select the checkbox labeled "Run program as other user" (on Windows Server 2003, click the Advanced button on the Shortcut tab to configure this). Now, whenever you double-click on the shortcut to run Computer Management, the Run As Other User dialog box (see Figure 1-1) will appear. Just type in your administrator password to run Computer Management in administrator context.
There's another way to create Run As shortcuts that you might find even easier to use. Just right-click on your desktop, select NewShortcut, and type the following command string:
%windir%\system32\runas.exe /user:MTIT\Administrator "mmc %windir%\system32\compmgmt.msc"
Save the shortcut with the name Computer Management. Now, when you double-click the shortcut, a command-prompt window opens, prompting you for the password for the MTIT\Administrator account. Type the password, press Enter, and Computer Management starts in administrator context.
What if you get tired of typing your administrator password each time you want to run a Run As shortcut? On Windows Server 2003, there's a way to get around that. Just create a new shortcut with this command string:
%windir%\system32\runas.exe /user:MTIT\Administrator /savecred "mmc %windir%\ system32\compmgmt.msc"
Notice the /savecred switch in this string. This option first appeared in Windows XP. The first time you double-click on the shortcut, a command-prompt window opens to prompt you for the password for the alternate credentials, just like before. The next time you double-click on the shortcut, however, you are not prompted for the password; it was stored on your machine the first time you ran the shortcut. Now you no longer have to type a password each time you use your Run As shortcut. Time-saver, right? Yes, but it's also a possible security hole: once the credentials for your administrator account are stored locally on the machine, they can be used to run any command-line program using administrator credentials.
Here's a scenario to illustrate what I mean. Let's say you need to run an administrative tool on a user's desktop machine without logging the user off the machine. You ask the user to take a coffee break. Then, you open a command-prompt window and use runas with /savecred to start the tool (you use /savecred because you might have to run several administrative tools and you don't want to have to type your complex 24-character password repeatedly). When you're finished, you close all the tools you started and walk away. When the user returns to her desktop, she opens a command prompt and types runas /user:MTIT\Administrator /savecred cmd. A command-prompt window opens, displaying administrator credentials in the title bar. The user now knows that she can use this approach to run any program on her machine using administrator credentials.
What did you do wrong as administrator in this scenario? Two things: you used /savecred on a user's desktop machine, which saved your administrator password locally on the machine, and you haven't renamed the default administrator account. If you had changed the name of this account to something complex and unknown to ordinary users, the runas /user:MTIT\Administrator /savecred cmd command the user typed wouldn't work.
What do you do if you have used /savecred on an unsecured machine without thinking about the consequences? Just delete your stored credentials on the machine by opening Stored User Names and Passwords in the Control Panel.