Powershell Tip - Storing and Using Password Credentials
from:http://blogs.technet.com/b/robcost/archive/2008/05/01/powershell-tip-storing-and-using-password-credentials.aspx
So I've been doing quite a bit of Powershell scripting lately, and this little tid-bit came in very handy, so I thought I'd share it with you all.
In Powershell you can use the Get-Credential cmdlet to get alternate logon credentials when you need to perform a task from the shell. But the Get-Credential cmdlet won't accept a hardcoded password in a script. So, how do you write a script that needs to run without user intervention and needs to use credentials other than those of the account used to run it?
Well, here is the answer.
First, we need to get our password, then pump it into a file. Doing this encodes the password and stores it in our output file so no-one can read it.
PS C:\> read-host -assecurestring | convertfrom-securestring | out-file C:\cred.txt
Once we have our password safely stored away, we can draw it back into our scripts..
PS C:\> $password = get-content C:\cred.txt | convertto-securestring
Then finally, we can create our credential object, which we pump into other cmdlets.
PS C:\> $credentials = new-object -typename System.Management.Automation.PSCredential -argumentlist "myusername",$pass
There you have it, storing a password in an external file, then accessing it from your scripts.
===========================================================
from:https://technet.microsoft.com/en-us/magazine/ff714574.aspx
Create Windows PowerShell Scripts that Accept Credentials
Follow Our Daily Tips
Twitter | Blog | RSS | Facebook
One question that comes up fairly often when dealing with Windows PowerShell scripts is how to properly handle user names and passwords. The solution is to use the Get-Credential cmdlet to create a PSCredential object. APSCredential object ensures that your password stays protected in memory, unlike cmdlets that accept a straight user name/password combination.
If a parameter accepts a PSCredential object, Windows PowerShell supports several types of input, such as the following:
Empty If you supply no input to a mandatory �Ccredential parameter, Windows PowerShell prompts you for the user name and password.
String If you supply a string to the �Ccredential parameter, Windows PowerShell treats it as a user name and prompts you for the password.
Credential If you supply a credential object to the �Ccredential parameter, Windows PowerShell accepts it as is.
This is great for interactive use, but what if you want to write an automated script for a cmdlet that accepts a �Ccredential parameter? The solution lies in passing a preconstructed PSCredential object. This solution is covered by recipe 16.9 in the Windows PowerShell Cookbook, which is excerpted here.
The first step for storing a password on disk is usually a manual one. Given a credential that you have stored in the $credential variable, you can safely export its password to password.txt using the following command:
PS >$credential.Password | ConvertFrom-SecureString | Set-Content c:\temp\password.txt
In the script that you want to run automatically, add the following commands:
$password = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PSCredential "CachedUser",$password
These commands create a new credential object (for the CachedUser user) and store that object in the $credential variable. When reading the solution, you might at first be wary of storing a password on disk. While it is natural (and prudent) to be cautious of littering your hard drive with sensitive information, the ConvertFrom-SecureString cmdlet encrypts this data using the Windows standard Data Protection API. This ensures that only your user account can properly decrypt its contents. While keeping a password secure is an important security feature, you may some-times want to store a password (or other sensitive information) on disk so that other accounts have access to it anyway. This is often the case with scripts run by service accounts or scripts that are designed to be transferred between computers. The ConvertFrom-SecureString and ConvertTo-SecureString cmdlets support this scenario by allowing you to specify an encryption key. Keep in mind that when used with a hard-coded encryption key, this technique no longer acts as a security measure. If a user can access the content of your automated script, that user has access to the encryption key. And if the user has access to the encryption key, that user has access to the data you were trying to protect.
Although the solution stores the password in a specific named file, it is more common to store the file in a more generic location―such as the directory that contains the script or the directory that contains your profile, like so:
$passwordFile = Join-Path (Split-Path $profile) password.txt
$password = Get-Content $passwordFile | ConvertTo-SecureString
Tip provided by Lee Holmes, Senior Software Developer Engineer and Author of Windows PowerShell Cookbook. From the Microsoft Press book Windows PowerShell 2.0 Best Practices by Ed Wilson with the Windows PowerShell Teams at Microsoft.
my test
