TLS 1.0 Required for HTTPS Pull Server

DSC
#1

We have an HTTPS pull server that was configured with the xDscWebService resource. The LCM on our nodes are set up to use configuration names with a registration key. After making registry changes to disable TLS on the nodes, they are unable to send report info or pull configs. Is there a way to get HTTPS Pull to work without enabling TLS 1.0?

The registry path to configure TLS 1.0 and other protocols:
HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\

Example of log from Microsoft-Windows-DSC/Operations:
Http Client AgentID failed for WebReportManager for configuration The attempt to send status report to the server https://pullserver.example.net:8080/PSDSCPullServer.svc/Nodes(AgentId=‘AgentID’)/SendReport returned unexpected response code NotFound…

Thanks! If I need to provide more info or code example please let me know.

#2

Hi Alfano,
Couple of questions that might help with investigation

  1. Before making registry changes to disable TLS, were you able to do pull configurations and send reports?
  2. Can you get the logs from the pull server? They can be found by running the command
    Get-WinEvent “Microsoft-Windows-PowerShell-DesiredStateConfiguration-PullServer/Operational”
#3

Yes, nodes were able to pull configs and send reports prior to disabling TLS 1. In fact, for most of our nodes, disabling TLS 1 was part of the initial config (we are disabling TLS and other protocols with the registry resource). Here is the scenario I have observed:

The LCM is initially set on nodes A and B to pull a configuration which will disable TLS. Both nodes are able to register, pull the config, apply it, and send report data. However, if I later try to set the LCM on node A again, it fails to register with the pull server. Consequently, node A is unable to send report data and the pull server does not recognize it as a registered node.

I’ve determined that TLS 1 is the culprit by re-enabling it. Once enabled, I am able to set the LCM again. For the nodes like A where I tried to set the LCM after the initial instance, I do not see any logs in “Microsoft-Windows-PowerShell-DesiredStateConfiguration-PullServer/Operational” or there is this event ID 4137:
“AgentId sd07ewevd-dcdf-11e5-8731-e4aa5cad9320 is not found in list of registered agents.”

I hope this paints a clearer picture to my situation.

Thanks for your help!

#4

Thank you for your response Alfano. I have some more follow up questions.

  1. After the nodes were able to register, pull the config and apply it, why are you trying to set the LCM on node A again and trying to register again? Are you changing the configuration that the node has to pull from the pull server?

  2. The Pull server logs will be on the machine where the Pull Server is (Sorry if I was not clear in my previous message).

  3. Where are you seeing this event - “AgentId sd07ewevd-dcdf-11e5-8731-e4aa5cad9320 is not found in list of registered agents.”

#5

  1. Yes, there have been a few instances where I needed to set the LCM again. In one instance, I had to set a node’s LCM to a completely different configuration. In another, I had added a second partial configuration to a node. Is there a way to modify a node’s LCM without it having to register with the Pull Server?

  2. I was seeing that particular event on the Pull Server,

#6

Thank you Alfano. I will investigate this on our side. If it is possible, can you please share the configuration that you used to disable TLS and other protocols?

You can modify a node’s LCM without having to register with Pull Server. But it depends on what you change in the node’s LCM. Some LCM properties can be changed. But to make changes in ConfigurationNames property, you will have to re-register with the Pull Server. There are 2 reasons for requiring this

  1. We would like the Pull Server to be in control of deciding which node gets assigned to which configuration. This keeps the management in a centralized manner. The pull server / Azure Automation DSC Service is far more intelligent and should be the authority to make this decision.
  2. Additionally, it is more secure. Otherwise, someone could take over the machine and start asking for malicious configurations that could mess with the machine.

Having said that, we should have had an API on the Enterprise Pull Server (not Azure Automation DSC service) to update this assignment. This is in our backlog and I need to look into our plans for this.

#7

Thanks for that info about setting the LCM. Is the ConfigurationNames property the only one that requires re-registration?

Here is a Gist URL with the configuration I have been using to apply the crypto-related registry settings: https://gist.github.com/anonymous/f756c18d6c1630c70dcdfab2d61f2ac9

#8

Alfano, I tried this on a Windows Server machine and was not able to repro it. I am able to disable TLS 1.0, re-register to get a new configuration and update that one as well.
Some more questions that might help with investigation

  1. Are you running this on a Windows Server 2012 R2 machine with WMF 5.0
  2. What is the SKU, version of both your target node and Pull Server?
#9

Are you disabling TLS 1.0 on the Pull Server, target nodes, or both? Were you disabling any of the other protocols listed in the configuration within my previous post?

My Pull Server and all target nodes are on 2012 R2 with WMF 5.0. I am also testing on a workstation with Windows 10 that has WMF 5.0.

#10

I am able to reproduce your issue and have a workaround that may work for you. If you enable local policy to use FIPS complaint algorithms for encryption then you will be able to get past this issue. Steps to enable this setting:
1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.

2.In Local Security Settings, expand Local Policies, and then click Security Options.

3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.

Keep in mind that you may need to either restart or kill wmiprvse.exe process before trying out your DSC scenario again.