Jump to content
Software FX Community

Get-Credential (supplying password)


craigmain
 Share

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...