2

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 :)"

Improve this question

1 Answer 1

Reset to default
0

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.

Improve this answer
1
  • Test 1 creates two mof files. Test 2 throws an exception: ConvertTo-MOFInstance : System.InvalidOperationException error processing property 'Password' OF TYPE 'MSFT_Credential': Error Reading certificate file nonexistentfile. I've worked around this issue by splitting node configuration files. I'm actually using grouping related nodes (web/app/sql/etc) into node configuration files but I chose a different grouping to work around this issue. Commented Feb 17, 2015 at 10:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.