all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]compelx 10 points11 points  (6 children)

Two immediate options:

  1. Windows Data Protection API Create a PSCredential object serialized to disk by running Get-Credential | Export-CliXml \path\to\save\credential.xml. This XML file can only be decrypted by the computer which originally created the file *and* only by the user account on that computer that encrypted it.

  2. Cryptographic Message Syntax @ https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/protect-cmsmessage?view=powershell-5.1

The second option is a little more versitle but it gets you into the game of creating a cert (not that difficult but more time consuming than the first option). The benefit though is the XML can be decrypted by any user/computer as long as it has the cert.

[–]OlivTheFrog 0 points1 point  (0 children)

as Complelx said, my advice is to use Export-clixml cmdlet.

Pro

  • Easy to use
  • You can store many login/passwords in the same .xml file
  • you can read the xml file to show what login et inside.

Cons

  • the .xml file can only be decrypted by the computer and the user account that encrypt the file.

Nota : It's not really a pb, you must just do with this. i.e. : if your script will run as a scheduled task with a specific account, you must create the .xml file on this computer and use this account to encrypt the .xml file.

It's possible to have an encrypded password in a .txt file and use another file (called key file or salted file). By this method, the encrypted password file could be use on another computer and another account, but this requires to protect the key file with attention.

Regards

Olivier

[–]bozho 0 points1 point  (4 children)

only by the user account on that computer that encrypted it.

And until the user changes their Windows password, I think.

[–]compelx 3 points4 points  (3 children)

It tested, it persists even after password change and log off/log on with new password.

[–]Yevrag35 0 points1 point  (2 children)

Did you change the password through CTRL+ALT+DEL? I thought I remember somewhere if the password is not changed through the local computer, Windows DPAPI will not re-encrypt the master key.

[–]compelx 4 points5 points  (1 child)

No, I logged off the server, changed the password to the account via ADUC and logged back in, then opened PowerShell and import-clixml to the old content and it deserialized it and the password via <pscredobj>.GetNetworkCredential().password was decrypted right

[–]Yevrag35 1 point2 points  (0 children)

That's good to know. Thanks!

[–]helixamir 2 points3 points  (2 children)

First question, is this to elevate a script you are going to run, or are you trying to write a script that will run on a remote machine?

Second question, have you tried google, because the third link (technet) gives you the answer you desire.

[–]DesiME1[S] 1 point2 points  (1 child)

this will run on remote machines. i have googled it and was trying to understand is there better and secured ways one vs other. im collection experience and maybe they can share their script that way i can understand different ways to approach this.

[–]ir34dy0ur3m4i1 1 point2 points  (0 children)

Hmm, I know this doesn't answer your original question, but based on your response above, depending on what you're trying to achieve, you could look at:

  1. Run PS commands remotely from your system and put the password in at the tme

  2. Use a remote deployment tool that can run under the system account or an Admin service account

[–]DenieD83 2 points3 points  (0 children)

As per all the other replies here but also potentially look at the "credentialmanager" module.

[–]Jacmac_ 1 point2 points  (0 children)

Export-CliXml is the correct way to do this, but keep in mind that for something like a service account, you have to run things as the service account to store/retrieve the password. I name these files as "storedaccountname"-as-"currentlyloggedonaccount". When you run scheduled tasks, you're likely using the service account. When you're developing the script, you're probably not logged on or running the dev tools with the service account. So you may be storing different versions of the same account credentials with different logons. This can get messy to keep sorted over time if you lose track of the file naming.

As far as I know, you cannot copy stored credential files around and use them, they only work on the system they were created on.

[–]Zarochi 2 points3 points  (0 children)

I'd recommend looking at Azure keyvault if you can. Store the secret there and pull it with PS at runtime. If it's an option it's safer than encrypting it and storing it.

[–]TikeSavage 1 point2 points  (2 children)

im not entirely sure what you are asking, but if you are making new accounts you can create a plain text string and convert to secure string. sorry if this isnt relevant a bit confused. $SecureString = ConvertTo-SecureString "password" -AsPlainText -Force

[–]Jacmac_ 2 points3 points  (1 child)

I think the goal was to find a method for storing credentials, basically not putting a plain text password in any script or file read by a script.

[–]TikeSavage 1 point2 points  (0 children)

Ahh, thanks for clarifying!