Get-Credential (supplying password)

[craigmain]

Hi,

 I need to use Get-WmiObject -computerName 192.168.0.1 -Credential $(GetCredential DOMAIN\User)

My problem is that I also need to supply the password. I have tried GetCredential DOMAIN\User,$pwd, where $pwd is a secure-string, but I get a transformation argument error.

 Is there any way to feed a password to Get-Credential, either as plain text (I know) or as a secure string.

I cannot seem to get it to work.

 

Regards

Craig

[SAPIENScripter]

I take it you don't want to be prompted to enter a password or that you're trying to do something in an unattended fashion. Theoretically what you are trying to do is manually create a PSCredential object.  However, (probably for security), I think the only way you can do that is with the Get-Credential cmdlet.  If you try using New-Object and specifying PSCredential or even System.Management.Automation.PSCredential as the type, you'll get an error about constructor not found which leads me to believe the PowerShell team didn't want you to be able to do this, at least easily.

[SAPIENScripter]

Ok, maybe I figured this out.  I think I was able to manually create a PSCredential object. I think you need to pass it the parameters when you create it.

$pwd=read-host -assecurestring

$cred=new-object  -typename System.Management.Automation.PSCredential -argumentlist "domain\username",$pwd

When you pipe $cred to Get-Member you should see this:

TypeName: System.Management.Automation.PSCredentialName MemberType Definition---- ---------- ----------Equals Method System.Boolean Equals(Object obj)GetHashCode   Method System.Int32 GetHashCode()GetNetworkCredential Method System.Net.NetworkCredential GetNetworkCrede.GetType   Method System.Type GetType()get_Password Method System.Security.SecureString get_Password()get_UserName Method System.String get_UserName()ToString Method System.String ToString()Password Property System.Security.SecureString Password {get;}UserName Property System.String UserName {get;}

I created a bogus credential and tried it with Get-WMI and got access denied so I think it works.  You still have to create the securestring, but there are several ways to handle that. 

[JuanC]

I have used a technique discussed in a couple of blogs such as

http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!273.entry

Generate an encrypted version of your password
read-host -assecurestring | convertfrom-securestring| out-file Encrypted.txt

Get a secure string
$secret = cat Encrypted.txt | convertto-securestring

Translate to a "clear-text" representation if needed
$Ptr=[system.Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($secret)
$str=[system.Runtime.InteropServices.Marshal]::PtrToStringUni($Ptr)

Use $str here

Clean-up the clear text string
[system.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($ptr)

I have not tested the constructor suggested by SapienScripter but if they support a secure string you could pass $secret instead of $str and remove all the Runtime.Interop calls. This would give you more security as the password would always be handled as a secure string.

AFAIK, the call to convert the password to a secure string uses DPAPI so it uses some user/machine info. Because of this you probably would have to repeat the read-host part if you want to use this script in multiple computers.

JuanC

[JuanC]

One more thing, we have done some recent work on our cmdlets (out-chart, out-gauge, out-map) in order to support credentials when refreshing. If you are planning to use -refresh or manually refresh using right-click you will need our current build. We are still doing some tests but we can certainly make it available to anyone interested.

Our current build will also prompt for the credentials password once more, this is a little complicated to explain in detail in this thread but we are planning to fix this in future builds.

JuanC

[SAPIENScripter]

The main point is that you have to supply a password at some point, ideally interactively. If the original post was intended to arrive at an "unattended" solution, then creating secure string and storing it in a file is probably the only way to go.  But even this, from a security perspective, is dangerous.  In essence you've still hard coded a password which is a security no-no.  Granted it is encrypted and I might not know what account it goes with, but if I do, then I can use that credential in my own PowerShell session to do just about anything I want.  I know it sounds cliche, but just because you can do something doesn't mean you should. Merely pointing out the risks.

 

Jeff