Powershell DSC uses the incorrect certificate file for encryption where node names partially match?

Question

I think there's a bug in the way that DSC chooses the certificate file that is used for credential encryption, such as with the Service resource and a PSCredential.

The DSC configuration uses the wrong CertificateFile from the AllNodes collection if a node name is contained in a subsequent node name (the node order is significant). This means that the encrypted value sent to the node may be wrong.

Here's a repro including two tests. Both tests should fail but the first succeeds (with the wrong certificate):

$password = ConvertTo-SecureString "password" -AsPlainText -Force
$serviceCredential = New-Object System.Management.Automation.PSCredential ("username", $password)
$currentPath = Split-Path -Parent $MyInvocation.MyCommand.Definition

$thisShouldNotWork = @{
    AllNodes = @(
        @{
            NodeName = "web1"
            CertificateFile = "nonexistentfile"
        },

       @{
            NodeName = "customerweb1"
            CertificateFile = "$currentPath\mycert.cer"
        }
    );
}

$thisDoesNotWork = @{
    AllNodes = @(
        @{
            NodeName = "web1"
            CertificateFile = "nonexistentfile"
        },

       @{
            NodeName = "customerweXb1"
            CertificateFile = "$currentPath\mycert.cer"
        }
    );
}

Configuration DscWebServer
{
  Node $AllNodes.NodeName
  {
    Service "Service Started"
    {
      Name = "MyService"
      State = "Running"
      Credential = $serviceCredential
    }
  }
}

Write-Host "Test 1" -ForegroundColor Blue -BackgroundColor White
DscWebServer -OutputPath .\DSC -ConfigurationData $thisShouldNotWork
Write-Host "Test 2" -ForegroundColor Blue -BackgroundColor White
DscWebServer -OutputPath .\DSC -ConfigurationData $thisDoesNotWork

I've reported this on Connect but wanted to raise it here in case it's helpful or there's something unusual about what I've done. Can anyone explain this behaviour?

UPDATE: Microsoft confirmed this as a bug and fixed it in May 2015. I got this feedback: "This issue has been fixed in WMF5 April Preview. Please let us know if you disagree :)"

Answer 1

This is interesting. Can you confirm what the output is of each test? Does Test 2 actually throw an exception?

I wouldn't say there's something unusual about what you've done, since DSC was designed to handle multiple nodes that way, but there are still only a small number of people using DSC, and an even smaller number using secure credentials.

Additionally, I think a lot of us have been using a single config for each node, which would prevent one from running into this behavior.

That is of course a viable workaround for you as well, but would require changes to your workflow.

To use your existing configuration data, you could work around the issue like this:

foreach($node in $thisShouldNotWork.AllNodes) {
    DscWebServer -OutputPath .\DSC -ConfigurationData @{AllNodes = @($node)}
}

I'm going to try to reproduce this tomorrow if possible so that I can add my vote and repro description to the report on connect.