Specifying PowerShell 4.0 DSC Configuration Data

Specifying PowerShell 4.0 DSC Configuration Data

  • Comments 3
  • Likes

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:

Photo of Prague

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.

Image of book

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.

Image of error message

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:

Image of script

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 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • In your example script you try to set Password to $cred in the User EdUser script block, but $cred isn't being set earlier, at least not as presented. It should probably be $password, right?

  • @Jason,

    Nice catch! +1