Authentication via credentials is the most common form of access identification in PowerShell.
This article has been translated automatically.
This is done using the Credential parameter, to which the combination of user name and password is passed in the form of a PSCredential object. Since these are sensitive data from privileged accounts, the security of these accounts must enjoy the highest priority. However, the most common methods of dealing with credentials have significant security gaps, as shown below.
PSCredential objects with the New-Object-Cmdlet
The easiest way to create a PSCredential object is a code like this:
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.
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:
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.
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.
Learn more about the secure use of PowerShell
Download the free PowerShell Security-Guide and learn about
PowerShell as hacking-tool
How to disarm PowerShell with integrated mechanisms
Frank Kresse is Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.