In Microsoft-oriented networking infrastructures, your Active Directory Domain Controllers may suddenly experience high number of Warning events in the System log in Event Viewer (eventvwr.exe) with EventID 5829.
Microsoft has added this event by design to warn Active Directory administrators of vulnerable Netlogon connections, in terms of CVE-2020-1472. The eventID was added with the August 11, 2020 cumulative update, rollup update and security-only updates for all supported versions of Windows Server.
A critical elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to an Active Directory Domain Controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network. To exploit the vulnerability, an unauthenticated attacker would be required to use MS-NRPC to connect to a Domain Controller to obtain domain administrator access.
The vulnerability applies to all supported versions of Windows Server:
- Windows Server 2008 R2
- Windows Serer 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server, version 1903
- Windows Server, version 1909
- Windows Server, version 2004
Both Full Installations and Server Core installations of Windows Server are affected by CVE-2020-1472.
The vulnerability was responsibly disclosed to Microsoft by Tom Tervoort of Secura.
About EventID 5829
In the August 11th, 2020 cumulative update for Windows Server, Microsoft has added five new EventIDs to notify Active Directory administrators of vulnerable Netlogon connections:
- EventID 5827 and EventID 5828
These EventIDs signal denied Netlogon connections. These EventID trigger if vulnerable Netlogon connections are denied.
- EventID 5829
EventID 5829 triggers whenever a vulnerable Netlogon secure channel connection is allowed in the timeframe between applying the August 11th, 2020 cumulative update and applying the February 9th, 2021 cumulative update.
- EventID 5830 and EventID 5831
EventID 5830 and EventID 5831 are triggered when vulnerable Netlogon connections are allowed by the "Domain controller: Allow vulnerable Netlogon secure channel connections" Group Policy setting.
Microsoft is addressing the vulnerability in a phased two-part rollout. The August 11th, 2020 update and the February 9th, 2021 update address the CVE-2020-1472 vulnerability by modifying how Netlogon handles the usage of Netlogon secure channels.
How to solve events with EventID 5829
There are two ways to solve the events in the System Log with EventID 5829:
- Update the device, service and/or appliance that sets up the vulnerable Netlogon connection to support secure RPC with Netlogon secure channel. For Windows-based devices, this means updating them with the latest Windows Updates.
Check to ensure that the Domain member: Digitally encrypt or sign secure channel data (always) Group Policy setting is set to Enabled.
- Use the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy to add non-compliant accounts. This should only be considered a short-term remedy until non-compliant devices are addressed as described above.
The deadline for solving events with EventID 5829 is February 9th, 2021, as the February 9th, 2021 cumulative update will deny the vulnerable Netlogon connections associated with the Warnings with EventID 5829.
CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability
How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472
[MS-NRPC]: Netlogon Remote Protocol
So how do we fix the 5830 error, not just bypassing it with the GPO edit?
This patch shut down my entire office this weekend when it was applied, and now I've got 22,000+ 5830 events logged since Sunday.
EventID 5830 indicates that you:
Events with Event ID 5830 include the sAMAccountName of the machine initiating the insecure, but allowed, connection and information on the Operating System. To address the events with Event ID 5830, upgrade Windows- and Windows Server-based Operating Systems to versions that support Netlogon secure channel connections. For other Operating Systems, contact the device manufacturer (OEM) or software vendors to determine if their software is compatible with the latest Netlogon Remote Protocol (MS-NRPC).
If you cannot remediate the connecting systems, but want to enforce the use of secure RPC with Netlogon secure channels on systems that support it, perform these actions to isolate the insecure systems (temporarily):
Once the systems, services and/or applications connecting to the NetLogon shares that do not use secure RPC with Netlogon secure channels or do not support MS-NRPC have been remediated, delete their /32 subnet from Active Directory Sites and Services. These systems should flow back into the Active Directory site where they existed before. If they do not flow automatically, reboot them or manually point them to Domain Controllers that enforce secure connections (if they don't support DCLocator).
I am a bit confused about the event IDs and the behavior explained in the initial deployment phase.
Will all the insecure connections be denied and events 5827 and 5828 be raised.
Or all of them will be allowed and only event 5829 will be raised.
Isn't (5827, 5828) and (5829) mutually exclusive events ?
Indeed, Event IDs 5829 and 5827/5828 are mutually exclusive.
The behavior of the Domain Controller and the specific Event IDs shown depend on the "Domain controller: Allow vulnerable Netlogon secure channel connections" Group Policy setting.
Why do we see these events 5827 and 5828 before Feb 2021? Are we good to ignore these events after the installation of August patch?
I was asking this question since MSFT mentioned the remediation only needed for 5829.
You are seeing these events, because you've installed the August 11th, 2020 cumulative update.
The events signal dropped connections in your current environment from devices that do not support secure channel connections.
By default, supported versions of Windows that have been fully updated should not be causing these events. If the event is logged for a Windows device, then confirm that the device is running a supported versions of Windows and ensure the device is fully updated.
For non-Windows devices, work with the device manufacturer (OEM) or software vendor to get support for secure RPC with Netlogon secure channel.
Thanks for Quick Response Sander.
I presume you're referring to FullSecureChannelProtection Registry key, but this hasn't been modified after being introduced by August 11th Patch
Yes, the FullSecureChannelProtection registry key refers to the 'Domain controller: Allow vulnerable Netlogon secure channel connections' group policy setting. More info.
If it is enabled on your Domain Controllers, event IDs 5830 or event IDs 5831 will be triggered.
If it is not (yet) enabled on your Domain Controllers, event IDs 5829 is triggered.
In case we see a Windows device with event ID 5827 and if we add that device to Active directory group that we create for excluding the devices that are making vulnerable connection. Will that let the windows device make the connection without any issue.
OR is the Active directory group to define exclusion machines concept is solely for non windows devices?
The ability to connect to Domain Controllers is governed by the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy setting on Domain Controllers.
If this setting is enabled, then any device can make non-secure connections, but trigger event ID 5830 or Event ID 5831 (depending on the connection type).
If this setting is disabled (as it will be by default per February), then no devices are allowed to make non-secure connections.
The Group Policy setting does not allow you to create exceptions on groups.
If you need exceptions, you'll need to create an additional Active Directory site.
If shared my instructions in one of my earlier comments.
Thanks for the swift response. We have applied the patch to all our domain controllers and we see 5827 events being generated from the machines in our domain.
Now, these are windows machines and all of these are at same patch and OS level. Yet, some machines are generating the 5827 events and some are not.
Now, i'm not sure if the machines which didn't generate the 5827 event yet are as well having issue and just that they did not generate the event yet.
Is there any way that i can test connection from my clients to the domain controllers. Like if i do a ping test from the machine to Domain controller and if the machine has issue is the ping test supposed to generate 5827 event?
Why I'm asking this is, we have a plan to enforce on domain controllers but before that we want to make sure that we add all the exception machines to the AD group. So, how do i get that list of machines which all have issue. As per what i see, it looks like machines take some time to generate 5827 event. So, im just thinking if there is any way that we can force test all the machines
From the Domain Controller, you can enable debug logging for the Netlogon service.
From the client side, you can use the following line of Windows PowerShell to initiate a RPC call to the domain or to a specific Domain Controller:
Test-NetConnection -Computername DomainOrDomainControllerFQDN -Port 135
Alternatively, you can use Ryan Ries' Test-RPC script or the MetaSploit PoC code for CVE-2020-1472.
I disagree on the assessment that the FullSecureChannelProtection registry key is the reason someone sees the 5827 EventID. We have all our DCs patched, and we have NOT enforced the FullSecureChannelProtection. That is, it doesn't exist or is not set to 1 on our DCs at this time.
We see several Windows devices randomly hitting the DC and producing the event. I believe most OSes have or can support the MS-NRPC protocol and still communicate effectively with a patched DC. I don't believe those clients need to be added to the bypass list unless they are specifically not signing the communication, which if I'm not mistaken is a requirement by the DC now.
I personally would focus on 5829 messages as these are known third-party devices that are likely not compliant.
I agree with T Bruss
Seeing conflicting info re server 2008 R2 …this is now unsupported so shouldnt get the updates however seeing info that if you have 2008 R2 SP1 you may well.
1) Will server 2008 R2 SP1 be affected?
2) If I manually add the entry onto such server will this detect necessary events or will it not work at all
3) Working on a domain with supported and non supported DCs – will this potential cause issues with some servers accepting insecure connections and others blocking?
Hi, I have one Windows XP machine that shows up for the events that I knew about. My question is about 2008R2 servers. I still have a bunch to retire but can't yet. I don't see any of them in the logs. Are they still going to function after the enforcement? I see different opinions on the matter of 2008 R2. they are all patched to the latest that MS released for them.
I also have Server 2003 box that is not creating alerts in my system log. Makes me wonder if there is something misconfigured in our group policies.