Recipe 10.6. Running a Task with Alternate Credentials

Problem

You want to run a task using a username and password other than the one you are currently logged in with.

Solution

Using a graphical user interface

1. Open the Start Menu.

2. Browse to the application you want to open and right-click it.

3. Select Run As.

4. When prompted, enter the username, password, and domain of the user being authenticated.

Using a command-line interface

The runas.exe command allows you to run a command as an alternate user:

> runas /user:<User> "<ExectuablePath>"

Here is an example:

> runas /user:AMER\rallen.adm "mmc.exe"

If you want to authenticate using credentials of a user who does not have logon privileges to the local machine, you'll also need to specify the /netonly option.

Using VBScript

' This code shows how to use alternate credentials using WMI ' Note that you cannot use this to connect to the local machine. ' ------ SCRIPT CONFIGURATION ------ strServer = "<HostName>"  ' e.g. wks01 strUser = "<User>"      ' e.g. AMER\rallen.adm strPasswd = "<Password>" ' ------ END CONFIGURATION --------- on error resume next set objLocator = CreateObject("WbemScripting.SWbemLocator") set objWMI = objLocator.ConnectServer(strServer, "root\cimv2", _                                       strUser, strPasswd) if Err.Number <> 0 then    WScript.Echo "Authentication failed: " & Err.Description end if ' Now you can use the objWMI object to get an instance of a class ' or perform a WQL query.  Here is an example: colDisks = objWMI.InstancesOf("Win32_LogicalDisk")

Discussion

A best practice system administrators should follow is to log on to desktop systems using a normal user account that has no administrator level privileges outside of that system. This has three distinct advantages:

• It reduces the impact a virus can have on your network if your machine becomes infected.

• It reduces the chance of accidentally deleting important files and folders or making administrative changes unknowingly.

• It ensures that the network remains secure even if someone gains physical access to your workstation while you are logged in.

If you need to access a network resource with administrator privileges, you should do so using alternate credentials as we showed in the solutions. This is also necessary if you want to access a resource on a machine in an untrusted domain, different from the one your account resides in. If you have some test systems in a lab that are not part of your domain, you'll have to use alternate credentials to access them.

Using a graphical user interface

If you need to run several different programs at the same time as an alternate user, it can be annoying to have to follow the graphical or command-line solution for each one. In this case, you'd probably be better off just using a remote desktop client to log on to the machine as the target user.

Using a command-line interface

One problem with runas is that you cannot specify the password for the user on the command line, even by piping it in. That means runas must always prompt you to enter a password. Some may argue that this is intentional because it is insecure to specify passwords on the command line; however, passing a password on the command line can be useful in situations where you need runas capability in a batch file. Fortunately, an alternative exists in the form of the Joeware cpau.exe utility. It works like the runas /netonly command, but you can specify the -p option to pass in a password:

> cpau -u <User> -p <Password> -ex "<ExectuablePath>"

This utility also has a more secure option. You can create an encrypted "job" file that contains the command to run and the password to use. If you open a job file, all you'll see is a string of letters and numbers. This prevents people from casually reading a password in a batch file.

To use this feature, you must first create the job file:

> cpau -u <User> -p <Password> -ex "<ExecutablePath>" -enc -file <JobFile>

Then to execute a job file, use the following command:

> cpau -dec -file <JobFile>

If you don't want to have to type a runas or cpau command every time you open a certain tool, consider creating a shortcut that automatically does this for you. For more on creating shortcuts, see Recipe 8.6.

Using VBScript

Obviously, hardcoding passwords within a script is not the most secure practice. There are a few alternatives, however. You can invoke a script as you would any other command-line tool using runas or cpau. Also, if you want to schedule the script to run periodically, you can specify credentials when you create the scheduled task.

See Also

MS KB 225035, "Secondary Logon (Run As): Starting Programs and Tools in Local Administrative Context"