Share via

Not seeing event 5829 since August's updates

MISAdmin 381 Reputation points
2020-09-16T16:43:48.41+00:00

In reference to August's changes with "How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472",

https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

I am not seeing any 5829 events in the System logs on my DCs. The DC's are Server 2012 and I have Windows 7 clients out there so I thought I would start seeing these events, logging that a vulnerable Netlogon secure channel connection was allowed. Am I missing something?

Windows Server Infrastructure
Windows Server Infrastructure
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Infrastructure: A Microsoft solution area focused on providing organizations with a cloud solution that supports their real-world needs and meets evolving regulatory requirements.
551 questions

12 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Daisy Zhou 24,981 Reputation points Microsoft Vendor
    2020-09-22T07:30:26.147+00:00

    Hello @MISAdmin ,

    Thank you for your update.

    If we do not see the 5829 event related to Windows 7 SP1 clients on any domain controller currently, then Windows 7 SP1 clients should not be affected. I have seen in other forums that some people have mentioned that the lower version of the clients are not affected currently, too.

    However, Windows 7 SP1 clients are no longer supported by Microsoft. It is recommended that you consider replacing Windows 7 SP1 clients with Windows 10 clients.

    Thank you for your understanding and support.

    Best Regards,
    Daisy Zhou

    0 comments
  2. MOD Administrator 1 Reputation point
    2020-09-25T06:47:43.207+00:00

    Hello Guys,

    I've the same problem, after installing August's update. There is no events in the system logs between 5827-5831. Even if I try to exploit the DC. Is it correct? I think no. Is there any other audit level prerequisites to see these events in the logs?

    Thanks,

    Andrew

  3. A, Yosi 1 Reputation point
    2020-09-29T19:57:45.823+00:00

    same issue here on Windows 2019 DCs. Not seeing anything, although the registry key is there for me to enable it when ready...

    0 comments
  4. atekkof 21 Reputation points
    2020-09-30T17:35:29.863+00:00

    Is it possible that the "Allow Vulnerable Netlogon Secure Channel Connections" GPO needs to be configured for these events to show up? Based on the details around the August patches, I assumed the event viewer would log those incidents automatically after they were installed, but maybe the GPO needs to be enabled and configured first?

    29448-image.png

    0 comments
  5. A, Yosi 1 Reputation point
    2020-09-30T17:40:33.427+00:00

    Please correct me if I'm wrong: (I think BSPatrick had the real answer)

    Based on some investigation. It seems like the answer is, it is a normal behavior.

    Most current Clients (not sure yet the scope of current, but I tested Windows 10 & Windows 7) are already capable & are using secured RPC without any recent published patches… In other words, we can “Assume” that all our current connections are using Secured RPC already…

    this page describes the way to test it via PowerShell:
    https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1

    pretty much: from the suspected client run the PowerShell cmd: Test-ComputerSecureChannel

    If you want to delve in the “fun” of RPC background, feel free to read:
    https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/ff8f970f-3e37-40f7-bd4b-af7336e4792f

    so in summary, I believe we are patched, & should visit the Event Log\System every few week/s and search for event 5827-5831 (most likely 5829)

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.