This might help you to understand how August Patch works
Event ID's 5829-31 Not Visible in Domain Controller logs after August 2020 Patches
Hello, we have applied the August 2020 patches on our Domain Controllers but do not see any logs with Event ID 5829-5831 since the updates. There is at least one Server 2003 machine (i.e. out of support OS) on our domain which I assume is still using insecure Netlogon but I can't confirm this as I don't see it reflected anywhere in the logs.
My suspicion was that we might have to enable and configure the included GPO: "Domain controller: Allow vulnerable Netlogon secure channel connections", but I don't want to enable it and then "allow" vulnerable connections just to test this.
We also have non-Windows devices on our domain and I'm sure some of them are using insecure Netlogon connections to the DC's. Does anyone know how I can get the results I need in event viewer? I would like to be ready for the enforcement phase in February.
Thanks.
6 additional answers
Sort by: Most helpful
-
Anonymous
2020-09-30T18:58:34.93+00:00 This document explains how to manage the changes in netlogon secure channel
https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc--please don't forget to Accept as answer if the reply is helpful--
-
Hannah Xiong 6,276 Reputation points
2020-10-01T03:18:47.78+00:00 Hello,
Thank you so much for posting here.
After the August 11, 2020 updates have been applied to DCs, events can be collected in DC event logs to determine which devices in your environment are using vulnerable Netlogon secure channel connections (referred to as non-compliant devices). Monitor patched DCs for event ID 5829 events. The events will include relevant information for identifying the non-compliant devices. To monitor for events, use available event monitoring software or by using a script to monitor your DCs.
For more information about this, we could refer to the document provided by Dave.
If we only install August 11, 2020 updates, non-compliant machines will be able to get logged on. Event ID 5829 is generated when a vulnerable connection is allowed during the initial deployment phase. These connections will be denied when DCs are in enforcement mode.
Event ID 5830 will be logged when a vulnerable Netlogon secure channel machine account connection is allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
Event ID 5831 will be logged when a vulnerable Netlogon secure channel trust account connection is allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
Otherwise, we actually find some non-compliant devices, and we want "the Netlogon service deny vulnerable Netlogon secure channel connection from a machine account" and we does not set "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy for Domain Controllers, we may receive Event ID 5827 and Event ID 5828.
Event ID 5827 will be logged when a vulnerable Netlogon secure channel connection from a machine account is denied.
Event ID 5828 will be logged when a vulnerable Netlogon secure channel connection from a trust account is denied.If we are sure that some machines are using insecure Netlogon connections, we could use available event monitoring software or by using a script to monitor for events.
For any question, please feel free to contact us.
Best regards,
Hannah Xiong============================================
If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. -
atekkof 21 Reputation points
2020-10-01T15:50:02.207+00:00 Yes, I'm aware of the information in that link and the description of how it is supposed to work, but there are no logs being generated for any of those Event ID's, so I can't tell if any machines on my network are using vulnerable netlogon to communicate. My concern is more for the out of support operating systems such as the Server 2003 machine on my domain which I suspect is using the old protocol, but I can't confirm this because the logging doesn't seem to be working properly. Is there an event ID which would confirm that secure RPC is being used by that machine?
-
Anonymous
2020-10-01T15:52:15.453+00:00 On the suspect machines you can confirm via PowerShell
Test-ComputerSecureChannel
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1As to Server 2003 its unlikely to apply unless it use AES for Secure RPC
https://support.microsoft.com/en-us/help/3050509/improving-cipher-security-in-windows-server-2003-sp2This specific CVE only applies to AES for Secure RPC
--please don't forget to Accept as answer if the reply is helpful--