WMF 5.0 lets you create DSC Resources using Powershell Classes like so:

[DscResource()]
class MyDSCResource
{
...
}

But right now it will only look in the .psm1 file. If you try to dot source a class based DSC resource into the .psm1 file then Get-DSCResource can't find it and it can't be used in DSC configurations.

We have many DSC resources combined into a single module, and our .psm1 file is getting difficult to manage. If two people are working on different resources they are likely to have a git merge conflict.

We would prefer to have the resources defined in separate files and then dot source them into the .psm1 file, similar to how other modules are designed.

If a Node is configured using a RegistrationKey so that ConfigurationNames can be used, then the CertificateID attribute is ignored under the ConfigurationRepositoryWeb block, and instead a self-signed certificate is generated called "DSC-OaaS".

This certificate is used for both client authentication to the pull server as well as encrypting configuration Mofs at rest on the server host.

The problem is two fold:

1. Becuase the CertificateID gets ignored when using CONfigurationNames, admins cannot control the key length or encryption of the files.




2. The certificate generated is a SHA-1 1024bit length. This is completely unacceptable as 1024 went out of use years ago, and SHA-1 is getting retired this year as an encryption standard.

Please allow administrators to select the certificate for use and NOT force a weak self-signed certificate.

So, it seems as though in WMF 5.0 there is a regression in functionality. In WMF 4.0, you could set up a DSCFileDownloadManager and Credential to have a Target Node contact a Pull Server SMB Share and download new mof files and resources. Everything worked perfectly including Certificate based encryption of the credentials. However, in WMF 5, it seems as though the LCM of the Target Node attempts to contact the SMB Share Anonymously, even in credentials are provided. Now, in a Non domain joined environment, you can just provide EVERYONE full control and then change Local Security Policy such that Anonymous=Everyone (even though this is a massive security risk in an enterprise environment). However, even worse, in a Domain Joined environment, there is no workaround. As the LCM cannot contact the LCM anonymously anymore (at least with no settings I saw), it instead attempts to contact the SMB share as the Computer Account, which of course will fail. This also makes it untenable to provide EVERYONE access because they will still get denied. I haven't found a workaround to get SMB Share working at all in a domain joined environment. Obviously, all of this worked in 4.0 including Certificate encryption with DSCFileDownloadManager. With 8.1 and beyond now offering SMB Encryption as well, the DSCFileDownloadManager is still a viable enterprise solution, and thus a potentially major issue.

If there are any workaround in the mean time, I'd love to hear them. Also, if I have misunderstood/misimplemented the issue, I'd love to hear that too. I did a wireshark capture of the traffic and it appears pretty cut and dry.

Thanks

Votes from Connect: 3

Original Date Submitted: 9/25/2015 5:21:10 PM

Description:
Contact Information
Handle: Jan Egil Ring
Site Name: PowerShell
Feedback ID: 1833443

Frequency: Desired State Configuration (DSC)
Regression: Update-DscConfiguration -ComputerName demohyper01 -Credential $TargetNodeCred -Wait -ErrorAction Stop

Problem Description:
Version: WMF 4 with 2014 November Update on Windows Server 2012 R2

I`ve run into access denied errors when using alternate credentials on Update-DscConfiguration:

PS C:> Update-DscConfiguration -ComputerName demohyper01 -Credential $TargetNodeCred -Wait -ErrorAction Stop
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = PerformRequiredConfigurationChecks,'className' = MSFT_DSCLocalConfigurationManager,'namesp
aceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer DEMORD01 with user sid S-1-5-21-2767021495-2328722188-4181787393-1106.
VERBOSE: Executing Get-Action with checksum: 2A4C8088BAE5F3220EA51E9B2B3F72829D3AEA6184863D96C857EBC461EDE3ED.
VERBOSE: Executing Get-Action returned result status: Ok.
VERBOSE: [DEMOHYPER01]: [] Updated configuration not found on pull server so no action taken. Ensure that a configuration with a different checksum exis
ts on the pull server for this node.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 0.205 seconds

The user sid S-1-5-21-2767021495-2328722188-4181787393-1106 is the SID of the currently logged on user, not the user specified in $TargetNodeCred.

It`s working fine when using PS Remoting to run the command (this is my current workaround):

Update-DscConfiguration -ComputerName $VMHost.Hostname -Credential $using:TargetNodeCred -Wait -ErrorAction Stop

Invoke-Command -ComputerName $VMHost.Hostname -Credential $using:TargetNodeCred -ScriptBlock {
Write-Output -InputObject "Successfully connected using PS Remoting"
Update-DscConfiguration -Wait
}

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1833443 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1833443).

Repro Steps:
Update-DscConfiguration -ComputerName demohyper01 -Credential $TargetNodeCred -Wait -ErrorAction Stop

Expected Results:
The specified credentials should be used to invoke the DSC Configuration update, not the credentials of the currently logged on user.

Internal BugId: 15847