What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
To remediate Zerologon (CVE-2020-1472), update every writable and read-only domain controller, confirm Netlogon secure RPC enforcement is active, and identify any devices still making vulnerable connections. An exception that allows a vulnerable connection is not a fix: the device and its machine or trust account remain a security risk.
What the Zerologon fix changes
CVE-2020-1472 affects the Netlogon Remote Protocol (MS-NRPC), which domain-joined devices and domain controllers use to establish secure channels. Microsoft’s remediation requires secure RPC for Netlogon secure-channel connections. Updating domain controllers is essential, but full protection also depends on enforcement and resolving devices that cannot make compliant connections. Microsoft’s Netlogon deployment guidance describes the change and its staged rollout.
Microsoft identified updates released August 11, 2020 or later as the starting point for deploying the change. The enforcement phase began with updates released February 9, 2021; those updates put domain controllers in enforcement mode by default, requiring secure RPC unless an account is explicitly allowed by policy. Check the update level and enforcement state on your own servers rather than assuming an old registry setting reflects their current configuration. Microsoft’s enforcement announcement explains the transition.
Verify domain-controller coverage and enforcement
- Inventory the forest. List every writable and read-only domain controller (RODC) in the forest. Confirm that each has an applicable update released August 11, 2020 or later; do not limit the check to writable controllers.
- Confirm enforcement against current guidance. Microsoft documented
FullSecureChannelProtectionas a DWORD underHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters, with value1enabling enforcement on the historical early-enforcement path. Microsoft says that after the February 9, 2021-or-later enforcement phase, this registry value is unnecessary and unsupported. Verify the server’s update level and current Microsoft guidance before changing registry values. - Review domain-controller System logs. Search for Netlogon events 5827, 5828, 5829, 5830 and 5831. Use event details, including the machine or trust identity and device information, to determine which peer needs attention.
- Track remediation to closure. Record each non-compliant device or trust, its owner or vendor, the corrective action, and whether any exception remains. Recheck logs after the device is updated, replaced or otherwise made compliant.
Interpret the Netlogon event IDs
The event indicates whether a vulnerable connection was denied, allowed during the initial rollout, or allowed by an exception. Microsoft’s guidance gives these meanings:
#1 Best Overall
| Event | What it means | What to do |
|---|---|---|
| 5827 | A vulnerable connection from a machine account was denied. | Identify the machine account and make its client compliant. |
| 5828 | A vulnerable connection from a trust account was denied. | Investigate the trust peer and work with its operator to enable secure RPC. |
| 5829 | During the initial deployment phase, a vulnerable machine-account connection was allowed; enforcement would deny it. | Use the event to identify and remediate the non-compliant device. |
| 5830 | A vulnerable machine-account connection was allowed by the exception policy. | Review why it is allowed and remove the exception after remediation. |
| 5831 | A vulnerable trust-account connection was allowed by the exception policy. | Review the exception’s scope and remove it when the trust is compliant. |
Events 5827 and 5828 are useful even though the connection was denied: they identify a peer that may lose Netlogon connectivity under enforcement. Events 5829, 5830 and 5831 show vulnerable connections that were allowed in the circumstances described by Microsoft, so investigate them rather than treating successful connectivity as evidence of remediation. For event definitions and deployment context, see Microsoft’s event and rollout guidance.
Make non-compliant devices compatible
Windows clients
Confirm that each Windows client is on a supported version and has the applicable updates installed. Check the security policy named Domain member: Digitally encrypt or sign secure channel data (always) and ensure it is enabled. Use the event details to connect the affected machine account to the actual device, then verify that the client can establish a compliant secure channel.
Third-party devices and software
Ask the device manufacturer or software vendor to enable secure RPC or provide a compatible update. Coordinate changes with the system’s owner, especially where the device supports a business-critical service. If a domain controller itself cannot be made compliant, Microsoft’s guidance is to retire it rather than leave it in service as an exception.
Handle exceptions as temporary exposure
If an exception is unavoidable while a device is being fixed, limit it to a dedicated security group and ensure the policy has replicated to all domain controllers. Continue monitoring events 5830 and 5831, document why each account remains allowed, and remove accounts from the exception policy as soon as their devices support secure RPC.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Rank #3
An allow-listed machine identity is not harmless: Microsoft warns that an attacker who takes over that identity could use the permissions held by the account. A vulnerable connection allowed by policy therefore leaves exposure in place; it should not be counted as a completed fix. Microsoft’s guidance recommends updating or replacing non-compliant devices and removing their accounts from exceptions as soon as possible.
Plan enforcement to avoid avoidable outages
When enforcement denies a non-compliant connection, the affected device may lose its Netlogon connection. Resolve warning events and coordinate with device owners before relying on enforcement to reveal incompatibilities in production. Microsoft’s staged rollout required administrators to update domain controllers, monitor connections, address non-compliant devices and enforce secure RPC for full protection. Microsoft’s October 2020 security update reminder also discusses continued exploitation at the time; it does not provide a numerical incident count.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What detection tools can and cannot do
In a January 14, 2021 post, Microsoft Security Response Center Vice President of Engineering Aanchal Gupta wrote that organizations using Microsoft Defender for Identity (then called Azure Advanced Threat Protection) or Microsoft 365 Defender (then called Microsoft Threat Protection) could detect adversaries attempting to exploit the vulnerability against domain controllers. That is a dated statement about detection, not a substitute for updating domain controllers, enforcing secure RPC or remediating exceptions. The MSRC post contains the statement and its 2021 product names.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
