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