Netlogon secure channel hardening after ZeroLogon

Every domain-joined computer and every trust keeps a secure channel to a domain controller through the Netlogon Remote Protocol (MS-NRPC). It carries NTLM pass-through authentication, machine account password changes and trust validation. ZeroLogon (CVE-2020-1472) showed how bad a weak secure channel can be. A flaw in the AES-CFB8 handshake let an unauthenticated attacker on the network set a DC's machine account password to empty and take over the domain in seconds.

The patch is old news, but the hardening around it is often not finished. Allowlist GPOs created during the 2020 rollout still grant exceptions. The follow-up sealing requirement from CVE-2022-38023 was never checked, and a few NAS appliances or old Samba hosts quietly log denials every day. This guide goes beyond the one-line check in the DC baseline. It shows how to measure what is still using weak Netlogon, enforce every layer and prove it.

What the hardening layers are

Netlogon hardening arrived in stages. Each stage has its own control and its own events:

What the ZeroLogon events mean:

• 5827: the DC denied a vulnerable Netlogon connection from a machine account.
• 5828: the DC denied a vulnerable Netlogon connection from a trust account.
• 5829: the DC allowed a vulnerable machine connection. You only see this in the pre-enforcement phase, so on a patched DC today it means something is wrong.
• 5830: the DC allowed a vulnerable machine connection because of the allowlist GPO.
• 5831: the DC allowed a vulnerable trust connection because of the allowlist GPO.

Events 5838 and 5839 mean a machine account or trust account used RPC signing when sealing was expected. On a fully updated DC past the enforcement date, those clients are denied, not warned.

Measure: collect the events from every DC

Pull a month of Netlogon events from each DC in one sweep. If you forward System logs to a SIEM, run the equivalent query there. The point is to know which devices and trusts are still on the edge.

$ids = 5827,5828,5829,5830,5831,5838,5839
$since = (Get-Date).AddDays(-30)

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'System'; ProviderName = 'NETLOGON'; Id = $ids; StartTime = $since
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, Id, TimeCreated,
    @{ n = 'Detail'; e = { ($_.Message -split "`n" | Select-String 'Machine|Account|Domain|OS' ) -join ' | ' } } |
    Sort-Object Id, TimeCreated |
    Export-Csv C:\Reports\netlogon-events.csv -NoTypeInformation

Each event records the machine or trust name, its domain and, where it is known, the OS version. The typical findings are storage appliances, printers and scanners that authenticate to the domain, old Samba releases, and embedded Linux systems joined with outdated tooling.

Next, find out whether anyone ever filled in the allowlist. It is a security descriptor stored in a GPO, so read it from the resultant policy on each DC:

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    $p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
    Get-ItemProperty $p | Select-Object PSComputerName,
        FullSecureChannelProtection, RequireSeal, VulnerableChannelAllowList,
        RequireSignOrSeal, SealSecureChannel, SignSecureChannel, RequireStrongKey
}

VulnerableChannelAllowList is the registry value behind the GPO. If it has content, decode the SDDL (ConvertFrom-SddlString) to see which accounts or groups are exempt.

Audit: resolve every device before you tighten

Work through the CSV one device at a time:

1. Identify the owner of each machine account in events 5827, 5829, 5830 and 5838. Use Get-ADComputer <name> -Properties operatingSystem, whenChanged, ManagedBy, Description.
2. Update or replace. Vendor firmware or a current Samba release fixes nearly all of these. Samba has required secure schannel by default for years, but old appliance builds may pin an older version.
3. Check trusts for 5828, 5831 and 5839. These are external or forest trusts whose other side has unpatched DCs, often a partner or an acquired domain. That domain's DCs need patching. There is no safe local workaround.
4. Delete the dead. A surprising share of denied machine accounts belong to devices that no longer exist. Disable, then remove them in line with your stale-object process.

Keep the sweep running after this first pass. New devices get joined, partners rebuild their DCs, and appliances get restored from old images. A monthly report of any Netlogon event in the 5827-5839 range, sent to the team that owns domain joins, catches these long before an enforcement change turns them into an outage.

Enforce

Empty the vulnerable-connection allowlist

Open the GPO that sets it (usually the Default Domain Controllers Policy or a ZeroLogon-era GPO) and go to:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections

Set it to Not Defined once every listed device has been fixed. If a business-critical device truly cannot be fixed yet, keep a single dedicated group in the descriptor, document the owner and end date, and alert on every 5830. Never grant it to a broad group such as Domain Computers.

Confirm sealing enforcement

On current, supported Windows Server builds, Microsoft's CVE-2022-38023 timeline has already made sealing mandatory: since the July 2023 updates, RequireSeal can no longer be set to 0 (disabled) or 1 (compatibility), so on an updated DC the value no longer changes behaviour. Setting it to 2 is harmless and only makes a difference on a DC stuck on a November 2022 to June 2023 update level. Set the value explicitly anyway, so a DC restored from an old backup or a rarely patched DC shows up in the drift report:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty -Path $p -Name RequireSeal -Value 2 -Type DWord
Set-ItemProperty -Path $p -Name FullSecureChannelProtection -Value 1 -Type DWord

Deploy these values as Group Policy Preferences registry items in a DC-only GPO, not by hand, so they are reapplied on every refresh.

Lock the classic secure channel options

These Security Options have existed since Windows 2000 and should be enabled on every domain member and DC. Microsoft's security baselines already set most of them:

• Domain member: Digitally encrypt or sign secure channel data (always) = Enabled
• Domain member: Digitally encrypt secure channel data (when possible) = Enabled
• Domain member: Digitally sign secure channel data (when possible) = Enabled
• Domain member: Require strong (Windows 2000 or later) session key = Enabled
• Domain member: Disable machine account password changes = Disabled
• Domain member: Maximum machine account password age = 30 days
• Domain controller: Refuse machine account password changes = Disabled

Regular machine password rotation limits how long a stolen machine secret is useful. Stop any imaging or VDI process that disables rotation to "keep the trust stable". Fix the image instead.

Verify

First, check that the secure channel still works from a sample of members, including one per OS family:

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:corp.example.com

Next, rerun the event sweep and confirm there are no 5829, 5830 or 5831 events and that 5827, 5828, 5838 and 5839 only name devices you have already decided to retire. Rerun the registry query and confirm that VulnerableChannelAllowList is absent on every DC.

Finally, add detections that watch for regression and exploitation:

• Any 5829, 5830 or 5831 is a configuration regression. Raise a ticket.
• A burst of 5827 from a single source can be a scan for weak Netlogon.
• Event 4742 (computer account changed) on a domain controller's own account where the subject is ANONYMOUS LOGON and the password was changed is the classic ZeroLogon exploitation artefact. It should never happen legitimately. Alert on it at high severity. The event IDs to forward are listed in the AD event IDs reference.

What it breaks

• Non-Windows devices with old Netlogon stacks. NAS appliances, multifunction printers, old Samba file servers and some Linux domain-join agents fail to authenticate or to change machine passwords once they are denied. Users see "trust relationship failed" or NTLM logon errors on those devices.
• Trusts with unpatched domains. A forest or external trust whose remote DCs cannot seal is denied. Authentication across that trust fails until the partner patches.
• Frozen VDI and lab images. Images that disabled machine password changes drift out of sync and lose their secure channel once rotation resumes. Rebuild them with rotation enabled, or use your VDI vendor's supported machine password handling.
• Restored DCs. A DC restored from a backup older than your update baseline comes back without enforcement until patched. Include these values in your forest recovery plan checks.

Related reading: the DC baseline for the surrounding configuration, blocking authentication coercion for the other RPC-based DC attack class, and restricting NTLM to shrink how much depends on Netlogon pass-through at all.