PowerShell Scripting Licensing Best Practices

"TechTarget China original" Windows PowerShell has become a preferred management interface for Microsoft on Windows Server. Because of deep integration into the Windows Server operating system, the PowerShell surface looks like it can do anything without any restrictions. However, there is actually not that much to do. One of the best features of Windows server is the ability to run scripts. PowerShell scripts allow code to be reused and support the running of complex command sequences, which is not possible in other ways. One big issue that the writers of PowerShell scripts must focus on is authorization. PowerShell is a powerful scripting language, but the PowerShell script works correctly only if you have the appropriate permissions. This requirement can sometimes be problematic because administrators are often advised to log in for daily operations using only standard, user-level permissions. The administrator account is usually reserved, and is only enabled when you run a task that explicitly requires permission to elevate PowerShell scripts. The problem with this is that there is no guarantee that the person running the script has administrator privileges and how to know if a PowerShell script has the required permissions to run. There are two ways to handle this type of PowerShell script permission issue. In most cases, a PowerShell script that requires elevated privileges performs a script-level authorization to obtain the required permissions when it runs. How authorization is granted by an administrator when scripting is dependent on whether the script supports interactive operations when it is run. If a script is only called manually by an administrator, the runtime administrator is present, and you can ask the admin to enter the credentials manually, so there is no problem. This approach is more secure in both ways, because administrator-authorized credentials are not stored. Conversely, if a script is called by an automated process, there is no guarantee that the administrator will be present and be able to enter the password. In this case, the script needs to be able to automatically get the password for authorization. PowerShell Interactive Authorization Method Interactive authorization is a more secure one in two ways, because the authorization credential is not stored for use as it is used. Invoke interactive authorization using the Get-credential command. Typically, the results of get-credential are mapped to a variable, so the obtained credentials can be mapped to a command that requires authorization. $c = get-credential get-wmiobject win32_diskdrive-computername server01-credential $c in the above example, the Get-credential command is mapped to a variable $c. Running this script causes Windows to pop up a dialog box asking for inputAdministrator credentials, as shown in 1. Figure 1. The Run get-credential command pops up a dialog box that asks for the administrator credentials to note the second line of the code, the Get-wmiobject command needs to be authorized, the authorization is completed by the –credential conversion that was added at the end of the command, and the credentials required for the authorization are recorded in the $c. The user name and password that you just entered. PowerShell Automatic Authorization method The PowerShell automatic authorization mechanism differs from the interactive authorization. When automatic authorization is performed, the credential information needs to be stored beforehand so that PowerShell can be obtained when needed. The code that stores the voucher is as follows: read-host–assecurestring | convertfrom-securestring | Out-file C:\Scripts\Password.txt Enter the above command, the user enters the password-no password input prompt, the user simply needs to enter the password and press ENTER. Because it is handled in a secure string, the password entered is shown in Mask 2. Once the input is complete, the password is written to a text file, in which case, C:\Scripts\Password.txt, you can also use any other path and file name. The password is stored in the file in an encrypted format, as shown in 3. Figure 2. This command accepts a password and then writes the password to a text file in Figure 3. Text files store passwords in an encrypted format in this case, 3 variables are typically set in a script. The first variable is a user name that is specified directly in the script code. The second variable holds the password read from the file. The third variable stores the credentials for the user name and password as a whole. The code looks 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 store the user name, $Password store the password, $C store the credentials. If you select automatic authorization to complete the configuration for PowerShell script permissions, you must ensure that the password file is saved in a secure location. Otherwise the other PowershELL scripts can simply read the contents of the password file to gain administrator privileges.

TechTarget China original content, original link: http://www.searchsv.com.cn/showcontent_92944.htm
©techtarget China: http://www.techtarget.com.cn

PowerShell Scripting Licensing Best Practices