Rather than having a username and password in plain text you might want to put the password into a file in an unreadable format. This has some pretty clear benefit that you are not fully exposing the password. From time to time of course you want to test with a password in plain text but in production that practice should be avoided if possible. Clearly if someone “bad” acquires the file they could essentially have the password username (if they got this from your automation script) combination. A sysadmin could minimize that threat by limiting who has access to the servers and use file permissions to protect the password text file.
Once you have your script ready for scheduling and automation run this command:
|
1 |
read-host -prompt "Enter password to be encrypted in secstr.txt " -assecurestring | convertfrom-securestring | out-file C:\passFolder\secstr.txt |
This is where I would look at the service account running the script and the permissions on the c:\passFolder location to minimize the treat compromise.
Now inside of your script insert this code in place of the plain text / interactive credentials:
|
1 2 |
$pass = cat C:\passFolder\secstr.txt | convertto-securestring $mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist "USER@domain.com",$pass |
Now in your script whenever you need a Credential you can do something like this (I’m using an Office 365 connection as an example but you could use any command-let that takes a credential) :
|
1 |
Connect-MsolService -Credential $mycred |
Hope this helps keep us all a little safer!