Alternate Credentials | Internet Forensics

Whenever you start a new instance of the PowerShell shell, it runs under your security context. This means that PowerShell uses your logon credentials to run whatever scripts and commands you need to run. If your credentials do not have permissions to perform a particular command, such as retrieving a WMI object from a remote computer, then PowerShell will not be able to perform that task. One way to run PowerShell under alternate credentials is to use the Windows RunAs command. In this case, PowerShell will run under whatever credentials you provide to RunAs. However, sometimes this option might not work for what you need to do. For example, suppose you want to retrieve a WMI object from a computer on which you're not a local administrator. By default, WMI only permits local administrators to access WMI remotely. You could launch PowerShell using RunAs, if you can provide RunAs with credentials such as a domain administrator account that is a local administrator on the computer in question. However, if that computer is not a domain member, there is no way to provide RunAs with the credentials of another computer's local accounts. If this situation arises, it appears that you're stuck.

However, it may only seem that way. Many PowerShell cmdlets support an optional parameter named -credential, which allows you to specify an alternate username and password that this one cmdlet will use to execute. For example, the Get-Wmiobject cmdlet has a -credential parameter. Running Help Get-Wmiobject indicates that the -credential parameter takes a value of the type PSCredential. This means you'll need to learn how to make one of those credentials.

The task, then, is to use PowerShell to get something called a security principal, which in English is a user or security group. PowerShell provides a cmdlet named Get-Credential that does just that. The cmdlet prompts you for the appropriate password, and returns a PSCredential object that you can store in a variable. For example:

 PS:> $cred = get-credential MYDOMAIN\Administrator

Note that the username is specified in the DOMAIN\USER format. For a local computer, use COMPUTER\USER instead. Always specify the short (NetBIOS) domain or computer name rather than the longer DNS domain name. If you prefer, you can also enter the username in the user@domain format, in which case you'll use the complete DNS domain name.

If you try this, there are two really important things to note:

A dialog box will pop up, prompting you for the specified user's password.
PowerShell does not check the user. Instead it prompts you for a password. Keep in mind that it doesn't see if it's correct, and it doesn't check to see if the specified user exists. That's your responsibility.

Now you can run a command such as:

 PS:> Get-wmiobject -class Win32_Process -Namespace root\cimv2  -computername Client32 -credential $cred

This script first utilizes the credential stored in the variable $cred to connect to a machine named Client32, and then attempts to retrieve all instances of the WMI Win32_Process class. Note that not all cmdlets support the --credential parameter as shown here. Run Help cmdlet-name to view a particular cmdlet's help file to see if it offers this functionality. In many cases, the ability to utilize alternate credentials isn't dependent on whether or not the cmdlets can accomplish this. Instead, it depends on whether or not the underlying Windows functionality, which the cmdlet is calling upon, can pass along alternate credentials.