James Thew - Fotolia


Best practices for authenticating PowerShell script permissions

PowerShell scripts can only run when they have the proper permissions, but an administrator may need to authenticate the script so it has the right privileges.

Windows PowerShell has become Microsoft's preferred management interface for Windows Server. PowerShell is so deeply...

integrated into the Windows Server operating system that there are seemingly no limits to what can be done using PowerShell; however, there are some, but not many.

One of the best things about Windows PowerShell is that commands can be scripted. PowerShell scripts allow code to be used repeatedly. They also make it possible to run complex command sequences that would otherwise be impractical.

One big issue a creator of PowerShell scripts must address is authentication. PowerShell is a powerful scripting language, but PowerShell scripts can only work if they have the proper permissions. This requirement can sometimes be problematic, because administrators are encouraged to log in using an account that has been granted only standard, user level privileges. Administrative accounts are typically reserved for performing tasks that explicitly require elevated PowerShell script permissions. The question therefore becomes a matter of how to make sure that a PowerShell script has the permissions it needs when there is no guarantee that the person who is running the script will have administrative privileges.

PowerShell is indeed a very powerful scripting language, but PowerShell scripts can only work if they have the proper permissions.

There are two ways to deal with these types of PowerShell script permissions issues. Typically, however, a PowerShell script that requires elevated permissions will perform script level authentication to get the required permissions.

The method an administrator would use to code this authentication process into a script varies depending on whether the script is going to be run interactively. If a script is going to be manually launched by an administrator, then it is no problem for the script to ask the administrator to enter their credentials. This is the more secure of the two methods because it does not require the administrative credentials to be stored. Conversely, if an automated process will launch a script, then one cannot assume that an administrator will be available to enter a password. In these types of situations, the script needs to be able to retrieve a password that it can use for authentication.

Interactive PowerShell authentication

Interactive authentication is the more secure of the two methods, because it does not require a password to be stored. Interactive authentication is handled by using the Get-Credential cmdlet. Typically, Get-Credential is mapped to a variable. This allows the credentials to be mapped to a command.

$c = Get-Credential

Get-WmiObject Win32_DiskDrive -ComputerName Server01 -Credential $c

In this case, the Get-Credential cmdlet is being mapped to a variable named C$. This script causes Windows to display a dialog box, which asks for a set of administrative credentials, as shown in Figure A.

Windows PowerShell administrative credentials prompt
Figure A. The Get-Credential cmdlet causes Windows to prompt the user for his credentials.

Notice in the second line of code that the Get-WmiObject cmdlet requires authentication. The authentication is handled by the –Credential switch, which is appended to the command, and the $c variable, which contains the username and password.

Automated PowerShell authentication

Automated authentication works a little bit differently. To perform automated authentication, it is necessary to store the credentials so PowerShell can retrieve them when required. The command for capturing the credentials is:

Read-Host –AsSecureString | ConvertFrom-SecureString | Out-File C:\Scripts\Password.txt

After entering this command, the user types a password -- no password prompt is displayed, the user merely types a password and presses Enter. The password is masked as it is typed because it is being treated as a secure string, as shown in Figure B. Once entered, the password is written to a text file. In this case, the text file is C:\Scripts\Password.txt, but you can use any path or filename. The password is stored within the file in an encrypted format, as shown in Figure C.

PowerShell command to store user password
Caption: Figure B. This command accepts a password and then writes the password to a text file.
Password stored in text file
Figure C. The text file stores the password in an encrypted format.

In this case, we would typically set up three variables. One variable would contain a hard-coded username. A second variable would store the password, as read from the file. The third variable would store the credential set as a whole. The code would look like this:

$Username = "poseydemo\Administrator"

$Password = Get-Content c:\scripts\cred.txt | ConvertTo-SecureString

$C = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

Get-WmiObject Win32_DiskDrive -ComputerName Server01 -Credential $c

As you can see, $Username stores the user name, $Password stores the password, and once again, $C stores the credential set.

If you choose to use automated authentication for PowerShell script permissions, it is very important to place the password file into a secure location. Otherwise, it is possible for other PowerShell scripts to obtain administrative permissions simply by reading the contents of the password file.

For more information about the Get-Credential cmdlet, Microsoft provides an example on TechNet.

Next Steps

How to automate tasks with PowerShell

Prevent script changes with PowerShell variables

Upload and download files with a PowerShell FTP script

Dig Deeper on Windows administration tools