Dell Command | PowerShell Provider Secure Password feature

Dell Command | PowerShell Provider Secure Password feature


The concept behind secure passwords is that in production scripts we should not pass important passwords as plain view. This is serious lack of security. So using PowerShell we can secure a password or atleast reduce password visibility. We will first discuss general aspects of secure string and then discuss how Dell Command PowerShell Provider(DCPP) leverages the innate feature of PowerShell to secure password.

Consider that we want to read User Name and Password from the user at the console. We are aware that User Name generally does not require any security and it can be visible to all. But for password we should not let strangers know the user’s password. We can facilitate this requirement with the commands as below:

$user = Read-Host "Enter Username"

$pass = Read-Host "Enter Password" -AsSecureString

A screen shot is shown below:

The above is just an overview of how we can add more security when we need to secure critical information like password. In the example above the variable $pass will be of type System.Security.SecureString. We will just get an introduction to two other widely used cmdlets PowerShell provides to facilitate secure fields before touching upon aspects of DCPP.

The two commands are ConvertTo-SecureString and ConvertFrom-SecureString. ConvertTo-SecureString converts a plain text to type System.Security.SecureString. An example is shown below:

"P@ssword1" | ConvertTo-SecureString -AsPlainText -Force

In the above example, the plain text "P@assword1" is converted to type System.Security.SecureString. This is more of an information and may or may not be widely used.

The next cmdlet "ConvertFrom-SecureString" is a more widely used cmdlet which is used to convert secure strings into encrypted standard strings. The main limitation of "ConvertTo-SecureString" is that its output cannot be directly written into a file for future use. To overcome this limitation we have to use "ConvertFrom-SecureString" which converts System.Security.SecureString into an encrypted standard string which can be conveniently saved to a file. An example is shown below:

As seen in the above example, we are converting plain text "P@ssword1" to secure string and then piping its output to ConvertFrom-SecureString to get encrypted string which can safely and conveniently be saved into a file.

As an example lets say on a system if Admin password has been set and we need to save this to a file. We can do this using:
Read-Host "Enter Admin Password" -AsSecureString |
ConvertFrom-SecureString | Out-File "C:\Scripts\AdminPassword.txt"

We can retrieve back this admin password into a variable as a secure object as :
$pass = Get-Content "C:\Scripts\AdminPassword.txt" | ConvertTo-SecureString

Now to consider how to leverage secure password for DCPP. In DCPP if the user’s system has either System or Admin password set then for all ‘set’ commands we have to pass the respective password. So providing this password as plain text breaches security. So we have to pass the password as System.Security.SecureString. Also when we pass SecureString password we have to pass it with a ‘-PasswordSecure’ switch and not the normal –Password switch. An example is shown below where the user is trying to set ‘AdvancedBatteryChargeCfg’ to ‘Disabled’ and passing SecureString password:

Set-item AdvancedBatteryChargeCfg disabled –PasswordSecure $pass

Here $pass holds the system/admin password and is of type System.Security.SecureString. Similar to above discussion we can read $pass as:

$pass = Read-Host "Enter system/admin password" –AsSecureString

Or from file as :

$pass = Get-Content "C:\Scripts\AdminPassword.txt" | ConvertTo-SecureString

We can save $pass to a file,if required, as:

$pass| ConvertFrom-SecureString | Out-File "C:\Scripts\AdminPassword.txt




Article ID: SLN312558

Last Date Modified: 08/13/2018 11:22 PM


Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
Yes No
Send us feedback
Comments cannot contain these special characters: <>()\
Sorry, our feedback system is currently down. Please try again later.

Thank you for your feedback.