Using Secure credentials for PS script

This topic contains 5 replies, has 4 voices, and was last updated by Profile photo of Dave Wyatt Dave Wyatt 8 months ago.

  • Author
    Posts
  • #37282
    Profile photo of Mark Prior
    Mark Prior
    Participant

    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.

  • #37285

    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

  • #37286
    Profile photo of Richard Diphoorn
    Richard Diphoorn
    Participant

    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/
  • #37287
    Profile photo of Richard Diphoorn
    Richard Diphoorn
    Participant

    @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.

  • #37288
    Profile photo of Mark Prior
    Mark Prior
    Participant

    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

  • #37306
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    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/

You must be logged in to reply to this topic.