Secure use of credentials in PowerShell with ScriptRunner

PSCredential objects with the New-Object-Cmdlet

The easiest way to create a PSCredential object is a code like this:

$user = "Max_Mustermann" $pwd = "Passwort123" $secure_pwd = $password | ConvertTo-SecureString -AsPlainText -Force $creds = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $secure_pwd

The username and password are entered as plain text in the PowerShell script. The password is converted to a SecureString because it can only be passed in this form. The PSCredential object is then created. This approach is extremely critical from a safety point of view. The username and password are entered as plain text in the script and are therefore visible to everyone.

The following code offers more security:

$user = "Max_Mustermann" $secure_pwd = Read-Host -AsSecureString $cred = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $secure_pwd

Only the user name is entered as plain text in the PowerShell script, the password is created directly as SecureString. However, there are security holes in this method as well, since you can make a reference to the username in the script. In addition, neither automation nor delegation of scripts is possible, since the password must be entered interactively each time a new script is executed.

The password can also be stored in an external file:

Read-Host -AsSecureString |  ConvertFrom-SecureString | Out-File "C:passwort.txt" $user = "Max_Mustermann" $pwd = "C:Password.txt" $cred = New-Object -TypeName System.Management.Automation.PSCredential $User, (Get-Content $pwd | ConvertTo-SecureString)

With this method, the password is encrypted and stored in an external text file. This is read back into the script and converted into a SecureString. This allows scripts to be automated since user names and passwords no longer have to be entered interactively. However, this procedure is not completely secure either, as SecureStrings can also be converted back in order to obtain the password. Another disadvantage is that the text file must be accessible during execution, which makes it impossible to delegate scripts. The user name is also entered as plain text in the script here.

Creating PSCredential objects with the Get-Credential cmdlet

One very popular way to create a PSCredential object is to use the Get-Credential cmdlet:

$cred = Get-Credential -Message "Bitte geben Sie Nutzername und Passwort ein"

That way, the user can use an input box to enter the username and password (Figure 1). The entered password is stored as SecureString.

Fig. 1: Dialog box for entering username and password, based on a PSCredential object

Although this method has no security vulnerabilities, it must be entered interactively in the PowerShell Console each time the script is run. This prevents both automation and delegation of scripts.

Use PSCredential objects with ScriptRunner

ScriptRunner allows you to safely store credentials and fully automate your scripts. Under the menu item “User Accounts” all Privileged Accounts with password are stored, which ScriptRunner should use to execute scripts on other systems. Passwords and usernames are stored in the Windows Credential Manager on the local system of the ScriptRunner host. The username is replaced by a randomly generated number as an additional security precaution. Since the information is stored on the local system, a normal Windows user cannot access it.

Figure 2: All privileged accounts and passwords that ScriptRunner needs to use to run scripts on other systems are stored locally on the ScriptRunner host

In the PowerShell script, the required credentials are simply inserted as variables, without any reference to the username or password used in the script.

Param ( [PSCredential] $PSCred1, [PSCredential] $PSCred1 )

Actions are always started from the ScriptRunner host with the credentials stored there. The required credentials are configured in the action/policy and are only introduced into the PowerShell process at runtime.

Since there is no interactive input of the username and password at runtime, Service Desk users of delegated scripts do not need to know the name or password of an administrative account to perform an action.