Author Posts

April 6, 2016 at 12:24 am

Hi All
bit of a new area for me here, in summary i would like to have a PS script to perform and action under a different set of AD credentials (i can do this if i include the creds in script as below

$Username = "contoso\USERID"
$Password = ConvertTo-SecureString "Password" -AsPlainText -Force
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

$session = New-PSSession -Credential $cred
Import-PsSession $session

{Bunch of script here that does stuff....}

)

not really looking to hide the user ID but i am looking for someway to mask / hide the password from within the script.

April 6, 2016 at 12:44 am

I write my password to an external file:

read-host -assecurestring | convertfrom-securestring | out-file .\securestring.txt

then I import my password when necessary:

$username = 'rj@xxxxxxx.yyy'
$password = cat .\securestring.txt | convertto-securestring
$credential = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

April 6, 2016 at 12:46 am

You're a bit out of luck here. There's not really a convenient way to do this.

You have a few options:

    Use a packager functionality like the one included in Sapien's PowerShell Studio
    Store the password in a textfile and read it in at time of executing the script. How to do this is explained here: https://4sysops.com/archives/powershell-credentials-how-to-encrypt-a-password/
    If I interpret right, you want to that someone else is able to run this script, true? If that's the case, then you can consider constrained endpoints. MVP Boe Prox goes in great details about this topic: https://blogs.technet.microsoft.com/heyscriptingguy/2014/03/31/introduction-to-powershell-endpoints/

April 6, 2016 at 12:49 am

@Robert-Jan: that will only work if the file is located on the same machine, under the user account that is used to create the file.

April 6, 2016 at 12:50 am

Thanks both, will start reading and trying what you suggest

Richard, yes the end game is to give the script to someone else to run

April 6, 2016 at 4:42 am

Constrained endpoints are definitely the way to go, then, for what you're trying to do.

To be clear: No matter how much encryption or compilation or whatever you use, if your script uses credentials on the client's computer, then they can read those credentials in plain text. They might have to jump through hoops to do it, but they absolutely can get the username / password from your script no matter what.

By using an endpoint, you keep the credentials somewhere else, and they're never exposed directly to the user. (You also get the benefit of being able to have the users authenticate as themselves to your endpoint, giving you some Authentication / Authorization control over who can execute your commands.)

Boe Prox did a great series of "Hey, Scripting Guy!" blog posts about this topic a while back: https://blogs.technet.microsoft.com/heyscriptingguy/2014/03/31/introduction-to-powershell-endpoints/