secure channel between the local computer and the domain is broken

Question

Hi, I am running into a situation where all endpoints and VMs have run into this issue with the secure channel between the local computer and the domain being broken. Our users are unable to RDP using IP, we are receiving the message that the Windows Domain controller cannot be contacted to perform Network Level Authentication (NLA). We are oddly enough able to RDP using hostname.

Two DC's are currently live. A third DC was decommissioned a few days ago and this is when the issue started. This old DC was the FMSO role master, but all roles were transferred to one of the current DC more than a year ago. The decommissioning was neglected up until today. The old decommissioned DC has been removed from AD.

Getting the following when running Test-ComputerSecureChannel -Verbose:

VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "<computer>".
False
VERBOSE: The secure channel between the local computer and the domain <domain> is broken.

When I switch a device to a test Workgroup, reboot, and then join the domain again, the secure channel is in good condition; however, if the device is rebooted the secure channel gets broken again.

If I however switch a device to a test Workgroup, reboot, go to AD and delete the device and then join the domain, the secure channel remains in good condition.

Clearly it would be not possible to manually remove - delete and join the domain again for each device. I have to believe that there is a better way.

Please help.

Answer 1

Same output running Dcdiag /v /c /d /e /s:%computername% >c:\dcdiag.log on the second DC also.

If I however replace %computername% with the actual hostname of the DC. The output appears to be rather detailed, almost 400KB+. I have added that output to the OneDrive link if that helps.

Thank you,

Answer 2

These issues are the result of the August update CVE-2020-1472
https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

You can test from the client end
Test-ComputerSecureChannel
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1

Check to ensure that Domain members: Digitally encrypt or sign secure channel data (always) is set to Enabled.
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always

For older OSs that cannot use secure channel you can put them in an OU, then add the OU here on each domain controller.
https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc#theGroupPolicy

--please don't forget to Accept as answer if the reply is helpful--

Answer 3

All VM's including the DC's have been updated and rebooted at least 2 or 3 times since the August update and this issue only surfaced after an old DC was taken offline. Can you please advise what precisely led you to conclude that the issue is because of the August update CVE-2020-1472?

Answer 4

what precisely led you to conclude that the issue is because

The numerous event log messages on domain controller. Also check to ensure that Domain members: Digitally encrypt or sign secure channel data (always) is set to Enabled.
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always

issue only surfaced after an old DC was taken offline

I was going to look again but the files are now all gone.

--please don't forget to Accept as answer if the reply is helpful--

Answer 5

Hi @Dave Patrick ,

The files are back in the OneDrive share, I didn't know if exposing the files with some internal information was a good idea so I had them removed.

The Digitally encrypt or sign secure channel data (Always) is not enabled, but it has never been enabled before. Also, it is my understanding that DC's always communicate with each other using a secure channel, but the secure channel is broken on the secondary DC also. I will enable this policy on some test device and secondary DC and see if that happens to make a difference.

What I am having trouble understanding is why would all these issues start literally the day when the old DC was decommissioned if the problem is with a three-month-old update?

If you can also indulge me and point to 1-2 events that indicate the issue with the update, I would really like to put that in a report.