• The things that are better left unspoken

17 Responses to Knowledgebase: You experience Warnings with EventID 5829 on Domain Controllers

1. 
   

   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.

   from Ian August 25, 2020 at 9:15 PM
   • 

     EventID 5830 indicates that you:

     • have the August 11th, 2020 cumulative update for Windows Server installed on your Domain Controllers;
     • have the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy enabled with Domain Controllers in scope
     • have machine accounts for 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

     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):

     • Create a new Active Directory site.
     • Deploy at least two Domain Controllers.
     • Provide the IP addresses of the two new Domain Controller and the IP addresses as /32 subnets to the new site.
     • Reboot the Domain Controllers so they appear as Domain Controllers for the site.
     • Manually point systems that do not support DCLocator to the new Domain Controllers and document the pre-existing configuation.
     • Create firewall rules to isolate the new Domain Controllers and the systems that do not support the feature. Make sure the systems that do not support the feature cannot access shares on the old Domain Controllers and that systems that support the feature cannot access shares on the new Domain Controllers. Additionally think about disabling lateral movement between the Domain Controllers themselves; Only allow the relevant network traffic.
     • Enable enforcement mode on the previously existing Domain Controllers and enable the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy on the Domain Controllers only.
     • Monitor Event IDs 5827-5830 on the Domain Controllers towards the systems that support the feature and ignore Event ID 5827-5830 on the Domain Controllers towards the systems that do not support the feature.
     • Monitor firewall rules for networking traffic that attempts to break the isolation.

     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).

     from Sander Berkouwer August 27, 2020 at 9:47 AM
     
2. 
   

   Hi
   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 ?

   from Mittal September 30, 2020 at 7:26 PM
   • 

     Hi Mittal,

     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.

     from Sander Berkouwer October 5, 2020 at 7:28 AM
     
3. 
   

   Hi Sander,
   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.

   from Lakshmi November 5, 2020 at 3:01 PM
   • 

     Hi Lakshmi,

     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.

     from Sander Berkouwer November 5, 2020 at 4:21 PM
     
4. 
   

   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

   from Lakshmi November 5, 2020 at 6:47 PM
   • 

     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.

     from Sander Berkouwer November 6, 2020 at 8:05 AM
     
5. 
   

   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?

   from Manideep Parimi November 6, 2020 at 8:20 PM
   • 

     Hi Manideep,

     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.

     from Sander Berkouwer November 8, 2020 at 8:58 AM
     
6. 
   

   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 Manideep Parimi November 9, 2020 at 1:53 PM
   • 

     Hi Manideep,

     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.

     from Sander Berkouwer November 9, 2020 at 5:01 PM
     
7. 
   

   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.

   from T Bruss December 5, 2020 at 12:40 AM
8. 
   

   I agree with T Bruss

   from Rey December 7, 2020 at 9:46 PM
9. 
   

   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?

   Many thanks

   from Donna February 9, 2021 at 3:48 PM
10. 
    

    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.

    from David W February 9, 2021 at 4:54 PM
11. 
    

    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.

    from Safe February 16, 2021 at 8:35 PM