Recipe5.1.Running a Task with Alternate Credentials

Recipe 5.1. 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

Open the Start Menu.
Browse to the application you want to open.
For Windows 2000, press the Shift key and right-click on the application.
For Windows Server 2003, right-click on the application.
Select Run As.
You will be prompted to enter the username, password, and domain of the user whose credentials you want use for running the task.

Using a command-line interface

The runas.exe command allows you to run a command with alternate credentials:

> 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 that does not have logon privileges to the local machine, you'll need to specify the /netonly option to the runas command.

Using VBScript

' This code shows how to use alternate credentials using WMI ' ------ SCRIPT CONFIGURATION ------ strServer = "<ServerName>"  ' e.g., fs01 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") ' This code shows how to spawn a new process using alternate creds ' ------ SCRIPT CONFIGURATION ------ strServer = "<ServerName>"  ' e.g., fs01 strUser = "<User>"      ' e.g., AMER\rallen.adm strPasswd = "<Password>" strProcessPath = "<ExecutablePath>" 'e.g., Notepad.exe ' ------ END CONFIGURATION --------- set objLocator = CreateObject("WbemScripting.SWbemLocator") set objWMI = objLocator.ConnectServer(strServer, "root\cimv2", _                                       strUser, strPasswd) set objStartup = objWMI.Get("Win32_ProcessStartup") set objConfig = objStartup.SpawnInstance_ set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process") intRC = objProcess.Create(strProcessPath, null, objConfig, intProcessID) if intRC <> 0 then    WScript.Echo "Error spawning process: " & intRC else    WScript.Echo "Successfully spawned process." end if

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 other than on 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 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 I showed in the solutions. This is also necessary if you want to access a resource on a machine in a different, untrusted domain from the one in which your account resides. For example, 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 using alternate credentials, it can be annoying if you have to follow the graphical or command-line solution for each one. In that case, you'd probably be better off just using a remote desktop client to log on to the machine as the target user.

Another option is to open a cmd.exe session with alternate credentials. Then any programs you open with that session will also be using the alternate credentials. The following is an example:

> runas /user:AMER\rallen.adm cmd.exe

Using a command-line interface

One problem with runas is you cannot specify the password for the user on the command line or even by piping it in. That means runas will 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 very similar to the runas /netonly command, but you can specify the -p option to pass in a password.

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

It 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 from 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 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 4.6.

Using VBScript

Obviously, hard coding passwords within a script is not the most secure practice. There are a few alternatives. 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.