Home / server / Questions / 271609
Accepted
Chadddada
Asked: 2011-05-20 10:02:24 +0800 CST

Encrypt powershell Credentials (creds) files

  • 772

I have started to play around with PowerCLI and therefore created a credentials file to use when I connect to vCenter. The purpose for this will be to run scheduled tasks, such as running the vCheck daily script. I will probably setup a service account for this, that will be a vCenter sever local admin, so I am concerned about the password being in this file.

If you just view the file the password looks encrypted:

AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAF6urzz6JcEKjSIAFn/FxnQAAAAACAAAAAAADZgAAwAAAABAAAACtzPSK0kUeCGX71HGYFXhBAAAAAASAAACgAAAAEAAAAECR1XvUy3U2YgSMrr1bQ tQIAAAAzWWCyBUxfA0UAAAAAsM9vPr/nr+VP1MAekPXKp/wNgw=

After you associate the credentials with a variable ($creds) you can then just view the variable and see the password:

$creds | fl *

Host : test User : test Password : really showing your password here File : your creds file

Is there a way to encrypt this whole file and/or stop this password from being viewed?

powershell vmware-vcenter vmware-esxi powercli

2 Answers

  1. Best Answer

    No there is no (easy) way to stop the password from being viewed but that's not as bad as it looks. The decryption only works under the following circumstances:

    1. The encrypted file must be opened by the same user which created it.

    2. The encrypted file must be opened on the same computer on which it was created.

    As long as you're using a strong password for the user account which need to read the credentials it should be save to use the credential file.

    I'm using the credential files for many scheduled tasks (non-interacive shell). The shell is automatically closed after the scheduled tasks is finished and the $cred variable is deleted.

    In interactive shells I dont use the credential files because I'm able to specify username and password manually.

    Hope this helps. Have a nice day.

    Greetings

    grub

    • 1

  2. Grub gave a great answer. I would like to add that instead of creating a local admin account, create a normal domain account and then give this user only the specific, Read-only user, permissions it needs from within vCenter. This way, if the account does get compromised, only minimal damage can be done.

    • 1