WMF5, DSC, and “DSC-OaaS” Certificates

This post is a little more “informal”, as it catalogs some discoveries while upgrading the QA/Lab to WMF5 and the impact it had on my DSC environment. It’s more of a recording of steps to demonstrate some “odd” behavior in WMF5 so I can upload details to well … anyone who cares to listen (UserVoice, PowerShell.org, etc.)

What am I recording?  Why the oddity that is the “DSC-OaaS” self-signed certificate, which seems to get created when attempting to use ConfigurationNames, despite settings defined.  It’s kind of causing a little chaos with some of the certificate refresh work I’ve done.

The Baseline

It should be mentioned that the Pull-Server is already “up and running” on WMF5.  Therefore it’s upgrade process will be skipped.  Also, as this is a lab, the GUIDs and public thumbprints aren’t critical to me, so for completeness I’m not going to bother blurring much detail.

To start things off, we need a baseline.  I picked my fileserver out of the lab.  It’s a currently patched 2012R2 server, using WMF4.  The exact PS version and existing DSC settings can be seen in the below screenshot:

image

You can see the ConfigurationID and certificates are set, and that the major version is 4.0.  As it’s a fileserver there is very little on this box, though it is worth mentioning I _do_ have .Net3.5 installed, as it seems so many things need it that it’s installed by default on my images.

image

Installing WMF5 and configuring DSC to use ConfigurationID

Now it’s worth noting that simply upgrading WMF5 “over the top” of WMF4 may or may not actually maintain the original DSC pull settings.  Regardless, I actually like the new module folder format (each module is placed in a folder after it’s version number), so I actually take two distinct steps in the upgrade:

  1. Erase the contents of C:\Program Files\WindowsPowerShell\Modules.  I’d like to see them re-download in the new format.
  2. run Win8.1AndW2K12R2-KB3134758-x64, in order to install the new re-released WMF5 package.  This install, will force a reboot of the host.  A little annoying, but meh.

image

So that should be pretty straight forward, right?  First thing to do is to look at the version table and DSC configuration … just to see what things look like:

image

So right away we see our PSVersion has incremented to 5.0.10586.117, which is good.  And the settings appear to be retained …. also good.  Now let’s take a closer look at the CertificateID.  At first glance it’s the same …. and if we can test it with update-dscconfiguration as well.

image

Well that’s a bit of a bummer.  I see it fetch the configuration, but the modules never download and nothing else seems to happen.  This is probably because, if we look back on the LCM configuration, there’s no ConfigurationRepositoryWeb configured, only the legacy DownloadManagerCustomData.  If we go back to microsoft’s msdn here, creating a new configuration is easy enough.  In fact, I can get a little clever and just pop in the variables I need off the existing configuration pretty easily:

[DSCLocalConfigurationManager()]
configuration PullClientConfigID
{
    param(
            [string]$ConfigID = (Get-DscLocalConfigurationManager).ConfigurationID,
            [string]$CertID = (Get-DscLocalConfigurationManager).CertificateID,
            [string]$PullServer = ((Get-DscLocalConfigurationManager).DownloadManagerCustomData).Value
        )
   
    If (!$ConfigID -or !$CertID -or !$PullServer) {
        write-error -Message “Some of the parameters are not defined, please manually input to continue”
        break
        }

    Node localhost
    {
        Settings
        {
            RefreshMode = ‘Pull’
            ConfigurationID = $ConfigID
            CertificateID = $CertID
            RefreshFrequencyMins = 30
            RebootNodeIfNeeded = $true
        }
        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL = $PullServer

        }     
    }
}

PullClientConfigID

Set-DscLocalConfigurationManager -Path “.\PullClientConfigID” -verbose

So I save it in the test directory and take another look.

image

This looks a little better.  But we still not downloading the modules … it claims it can’t find them:

image

Well this is no fun.  So lets reach into the known limitations blog where there’s this little gem that fixes problems when upgrading from production preview to RTM:

mofcomp $env:windir\system32\wbem\DscCoreConfProv.mof

Again … sitting quietly.  OK that’s it, time to wipe out the current configuration:

remove-dsconfigurationdocument –state current

Bingo!  Modules download and things apply!  Weird I had to clear the old config … but whos complaining?

Important Notes on Configuration

So why did I walk through all of this?  Mostly to demonstrate the way DSC nodes function in a ConfigurationID scenario.  If we look at the configuration, The server has “ConfigurationID”  set as part of the settings, but NOT as part of ConfigurationRepositoryWeb:

image

Now the “2nd” CertificateID, according to Microsoft, is used as an authentication certificate, and should not be needed in this scenario.  Despite this: the node connects to the pull server then downloads the configuration mof and all needed and stores it in the C:\windows\system32\configuration fully encrypted.  That’s a nice improvement:

image

Next observation:  I also post meta configurations …. that doesn’t appear to get downloaded.  Different post for a different time I suppose.  But the key takeaways are that for the most part things are doing what they should:  configurations are being downloaded and applied along with their module.

Reconfiguring for ConfigurationNames

Now here’s the payoff for all this mundane base lining:  watch what happens when we switch the node over to use ConfigurationNames.  In order to do this we are going to wipe the ConfigurationID and replace it with the RegistrationKey.  In order to let things “just work”, I’m also going to just give it a ConfigurationName equal to it’s old ConfigurationID.  I’m too lazy to bother to rename files right now Winking smile.  When configured … weirdness happens.

First we need to tweak that configuration script.  Here we go, we just pull out ConfigurationID and update the PullServerURL to point at the “new” spot, then dump the configurationID as the configname so the same file pulls:

[DSCLocalConfigurationManager()]
configuration PullClientConfigID
{
    param(
            [string]$ConfigName = (Get-DscLocalConfigurationManager).ConfigurationID,
            [string]$CertID = (Get-DscLocalConfigurationManager).CertificateID,
            [string]$PullServer = (Get-DscLocalConfigurationManager).ConfigurationDownloadManagers.ServerUrl
        )
   
    If (!$CertID -or !$PullServer) {
        write-error -Message “Some of the parameters are not defined, please manually input to continue”
        break
        }

    Node localhost
    {
        Settings
        {
            RefreshMode = ‘Pull’
            CertificateID = $CertID
            RefreshFrequencyMins = 30
            RebootNodeIfNeeded = $true
        }
        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL = $PullServer
            RegistrationKey = ‘****’
            ConfigurationNames = @($ConfigName)

        }     
    }
}

PullClientConfigID

Set-DscLocalConfigurationManager -Path “.\PullClientConfigID” -verbose

Now here’s where it gets fun?  As soon as I switch over to using ConfigurationNames the eventlog will start spitting out that it’s using a _new_ certificiate to authenticate against the pull server with.  Ill also find this brand new cert called “DSC-OaaS”:

image

Notice it’s only 1024 SHA-1?  So what is it used for?  Well the certificate properties say it’s for digital signature and authentication only.  Like a generated password.  Well, that’s what the CertfificateID attribute is supposed to be for in the ConfigurationRepositoryWeb block if we go by Microsoft. So in theory if we set that … the self-signed cert should cease to be used.  SO lets give it a go!

image

Apparently the property doesn’t exist.  At least not when using ConfigurationNames.  Let’s see what happens if I use ConfigurationID (remove registrationkey and configurationnames):

image

Well now the variable works … what’s more the specified cert is used by the node to authenticate, just as anticipated.

image

Conclusion

Kind of confusing actually.  It appears that whenever you configure your node to use “ConfigurationNames” it will create a brand new DSC-OaaS certificate.  This certificate is used by the system to authenticate, and you can’t select a new one to use.  The entire property is locked out.  If you use the ConfigurationID, however, then you are free to specify the certificate of your choice, or omit the entry entirely … both are perfectly valid.

The end result:  if you want to use ConfigurationNames you need to authenticate with a 1024-SHA1 certificate.  :/

Advertisements

4 thoughts on “WMF5, DSC, and “DSC-OaaS” Certificates

    1. Sadly you’re right. I’ve written a formal complaint on the user voice about it, only response I’ve gotten however is that they are upping the standard to 2048/SHA256RSA. It’s still self-signed (bad), it still lacks any means of being set/controlled by the admin in “configurationames” mode (bad), and the WMF5 LCM doesn’t download meta-configs anymore which makes it harder to cycle and control certificates even if you use ConfigurationIDs (bad).

      It seems at this point, the framework is evolving in a way that they are fine letting security be a problem of 3rd tooling (AADSC/Puppet/Chef) at this time. Doubt its a permanent problem, but clearly not a priority 1 issue and thus a tough pill for me to swallow personally. I hope I’m reading the tea leaves wrong, but secure DSC with a pull server is tougher right now than it was in wmf4. 😦

      Like

  1. Are you using the thumbprint of the certificate installed on the Pull server as the CertificateID on the nodes? I’ve been trying to set up a Pull environment but can’t get my node to grab the configuration. I’m using HTTPS and ConfigurationID’s as opposed to ConfigurationNames.

    Like

    1. No, the CertificateID thumbprint is _not_ the thumbprint on the pullserver. It’s purpose kind of depends on where it’s defined.

      When defined under the Settings block, the CertificateID tells the LCM which locally installed certificate to use in order to try to decrypt credentials stored within the Mof. So it has to be locally installed, and have the appropriate private key.

      When defined under ConfigurationRepositoryWeb or similar block (like the reportingweb, etc), then the certificate thumbprint tells the LCM which cert to authenticate to the pull server with for that specific service. It does _not_ have to be the same certificate as which is used for credential decryption. Also, as demonstrated above, it’s simply ignored in favor of DSC-OaaS locally generated certificates when setup to use ConfigurationNames.

      In both cases, defining the CertificateID is optional. If your MOFs will never contain encrypted passwords, or you don’t want to specify a specific thumbprint for agent authentication, you don’t have to define either.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s