Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell 4.0 DSC and specifying configuration data.
Microsoft Scripting Guy, Ed Wilson, is here. One of the cool things about Prague is that it is at least as beautiful at night, as it is during the day. Windows PowerShell MVP, David Moravec, and his lovely wife Andrea have been a lot of fun, and they have been terrific hosts to their city. Here is a nighttime picture, that sort of shows what I mean:
Note Today is the third day in a series of blog posts about Desired State Configuration. Portions of these posts are excerpted from my book, Windows PowerShell Best Practices, which is published by Microsoft Press.
To modify the way a configuration runs, it is necessary to specify configuration data. This can take the place of a separate file, or it can be added directly via an array of hash tables. To create a local user, it is necessary to specify PSDscAllowPlainTextPassword = $true in the configuration data. This is a requirement even if you are not directly supplying the password as plain text.
In the DemoUserConfig.ps1configuration script that follows, the user credentials are supplied to the configuration via the Get-Credential cmdlet. This produces a secure string. But the error message that generates from running the configuration states that storing an encrypted password as plaintext is only supported if the configuration permits it. This error message is shown in the image that follows.
The complete DemoUserConfig.ps1 configuration script is shown here:
DemoUserConfig.ps1
#Requires -version 4.0
Configuration DemoUser
{
$Password = Get-Credential
node Server1
{
User EdUser
{
UserName = "ed"
Password = $cred
Description = "local ed account"
Ensure = "Present"
Disabled = $false
PasswordNeverExpires = $true
PasswordChangeRequired = $false
}
}
}
DemoUser
The problem is not the way the password is supplied to the configuration, but rather what happens after the configuration runs. It decrypts the password and stores it in plaintext in the MOF file as shown in the following image:
Because this stores the password in plaintext in the MOF file, the Windows PowerShell team wanted to ensure that you are aware of exactly what you are doing. (By the way, the alternative to storing the password in plaintext is to encrypt the password with a certificate.)
After you create the configuration data, you call the configuration and specify the newly created configuration data as shown here:
$configData = @{
AllNodes = @(
@{
NodeName = "Server1";
PSDscAllowPlainTextPassword = $true
}
)
}
ScriptFolder -ConfigurationData $configData
Creating users with the User provider
To create a local user, call the User provider, and specify the user name. The password is passed to the Password property as a PSCredential object. This is different than a SecureString, which might be expected. This is because the PSCredential object contains the user name and the password (as a SecureString).
Next comes the Description, and choosing whether to enable the user account. It is possible to create disabled user accounts by setting the Disabled property to $True.
The last two things to configure are the PasswordNeverExpires property and the PasswordChangeRequired property. The following portion of the configuration script illustrates this technique:
User EdUser
{
UserName = "ed"
Password = $cred
Description = "local ed account"
Ensure = "Present"
Disabled = $false
PasswordNeverExpires = $true
PasswordChangeRequired = $false
}
DSC Week will continue tomorrow when I will talk about more cool Windows PowerShell DSC stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy