The examples throughout this chapter show local administrators going about their daily work while logged on using their Administrative accounts. This is generally not a good practice. Quite a few bad things can happen when logged on with full admin permissions. Viruses can get activated and make sweeping changes. Innocent mistakes can cause serious damage. Leaving your workstation open gives access to nefarious users. The list goes on and on.
Windows Server 2003 comes with a
Secondary Logon Service (SLS) that makes it possible to log on as a standard user and then launch applications with alternative credentials to perform administrative tasks. This is philosophically similar to the su (superuser) command in UNIX, but is implemented somewhat differently.
The Secondary Logon Service is installed by default and starts at boot time. The service is hosted by Services.exe. The code is contained in Seclogon.dll.
One of the easiest ways to use SLS is to open a command console window and launch an application using the RunAs command. Here is the syntax:
runas /u:administrator@company.com executable_name runas /u:company\administrator executable_name
You can open a console in another security context by entering
cmd as the executable name. You are prompted for a password and a second console window opens with a title bar that shows the alternate name you used. Applications launched from this console retain the alternate security context. For example, you can launch AD Users and Computers by typing
dsa.msc . The console opens with your admin credentials so you can perform privileged operations.
If you prefer using the Explorer shell, you can specify alternate credentials by holding down the Shift key then right-clicking the icon for an executable or its shortcut. This adds a RUNAS option to the flyout menu. Selecting this option opens a RunAs window where you can enter the alternate credentials. Figure 13.14 shows an example.
By default, RunAs opens an application with the profile of the user specified by the /u: switch. This differs from Windows 2000, which uses the Default User profile unless told otherwise. Opening the user's own profile ensures that applications making calls to standard shell elements such as My Documents open the user's elements, not the Default User elements.
There is a /noprofile switch that loads the Default User profile rather than the user's profile. This speeds up an application launch if the designated user has no local profile on the machine, but can cause unexpected behavior if an application calls standard shell elements. Watch where you put your documents if you use the /noprofile switch.
The RunAs command has several other useful switches:
/env. Uses the current environment variables rather than the variables for the alternate user. This helps troubleshooting application troubles at a local user's desktop.
/savecred. Opens the window with the specified user's saved credentials, if any. This option helps when you are on a laptop that is not connected to the network and you need to launch a console using an Admin account with locally cached credentials.
/smartcard. Uses smart card authentication instead of standard Kerberos or NTLMv2. This is a new feature in Windows Server 2003 that greatly simplifies network administration in organizations that use smart cards for logon authentication.
/netonly. Uses the same credentials as those used to log on to the desktop. This helps avoid problems when running applications across the network using different credentials than those used to create the connection.
If you initiate a network connection from the console, you can access the connection through the console but not through the shell. For example, you can map a drive to an admin share at another server while you are at elevated permissions by entering net use * \\server_name.company.com\c$. The connection succeeds because you have sufficient credentials. If you go to a My Computer window and look at the drive you just mapped, however, it shows an X and denies access if you try to use it because the shell is still running with your logon permissions.
Use caution when launching interfaces that tie directly to the Explorer shell from a command console using RunAs. For example, if I'm working at a console prompt and I want to get a graphical view of the folder contents, I enter start. (start followed by a dot) on the command line. This opens the My Computer view of the current folder in Explorer. If I do this from RunAs, the window opens but the underlying security context is the same as my logon account.
If you want to run the shell at elevated permissions, too, you can shut down Explorer and then restart it using RunAs from the Task Manager. To do this, follow Procedure 13.6.
Procedure 13.6 Starting Explorer Shell Using RunAs
Open Task Manager by pressing Ctrl+Alt+Del and then clicking Task Manager.
Select the Processes tab.
Highlight Explorer and click End Process. Confirm when prompted.
When Explorer shuts down, select File, Run from the Task Manager menu and start Explorer as follows:
runas /u:administrator@company.com explorer.exe
After Explorer opens, some components such as the status bar and System Tray continue to run in the original logon context and are therefore unavailable to Explorer.