Event ID 5827: Netlogon blocks vulnerable secure channel connections

Fix it now

A domain controller denied a machine account’s Netlogon secure channel connection because the connection did not use secure RPC. That is enforcement working as designed. There is no setting on the domain controller that makes the connection acceptable and safe at the same time, so the device at the other end has to change.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=5827,5828,5829} -MaxEvents 500 |
  Select-Object TimeCreated, Id, Message |
  Sort-Object TimeCreated

1. Collect the account names from every domain controller, not one. The combined list is the entire scope of the problem.
2. Sort the list by what each account is: a Windows machine, a non-Windows domain member such as a storage or print appliance, or a trust account. Trust accounts appear as 5828 rather than 5827.
3. For supported Windows machines, apply current updates and reboot. Secure RPC support arrived with the same updates that introduced the enforcement.
4. For non-Windows members, move to a build the vendor states implements secure RPC for the Netlogon channel. Ask the vendor for the version number in writing.
5. Treat the allow-list policy as a stop-gap with an end date, not a fix.

Devices exempted through the policy are recorded as 5830 (machine accounts) or 5831 (trust accounts). Those two events are your exemption register – review them regularly, because nothing else tracks the list.

Once an account stops appearing, that device is compliant. The next section explains what the domain controller is checking and why the allow-list is a poor long-term answer.

Why it happens

The Netlogon secure channel carries machine authentication between a domain member and a domain controller. Secure RPC on that channel is now required: a domain controller refuses a connection that does not use it, and records the refusal as Event ID 5827 for a machine account or 5828 for a trust account. The name in the event is the account that failed, and it is the only thing you need to identify the device.

The exception mechanism is a single group policy setting, Domain controller: Allow vulnerable Netlogon secure channel connections. Accounts listed in it are allowed through, and every such connection is logged – 5830 for a machine account, 5831 for a trust account. Nothing else records the exemption, so those two events are the only running inventory of the risk you are carrying.

Event 5829 is different in kind and worth understanding before you assume you are safe. It records a vulnerable connection that was allowed during the deployment phase, and its own text warns that the connection will be denied once enforcement is in place. A domain controller full of 5829 entries is a list of the devices that will fail next, which makes it the most useful event of the set.

Full reference

The five events and what each one tells you

Using the events as a project plan

1. Collect 5827 and 5828 from every domain controller: those devices are broken now.
2. Collect 5829 where any domain controller is still allowing vulnerable connections: those devices break next.
3. Collect 5830 and 5831: those are the exemptions you already hold.
4. De-duplicate by account name, not by event, because one device generates many entries.
5. Give every account an owner and a date. The list only shrinks if somebody is responsible for each row.

Where the allow-list belongs

Domain controller: Allow vulnerable Netlogon secure channel connections is a domain controller policy, and it takes specific accounts. Add the account, not everything: the setting exists so that one uncooperative appliance does not force you to weaken authentication for the estate. Every allowed connection is then logged, which is the mechanism that stops an exemption becoming permanent by accident.

Do not use the allow-list as a general fix for a wave of 5827 events. The connections it permits are exactly the ones the enforcement exists to stop, and the accounts on it are the accounts an attacker would target first.

Checking a device rather than waiting for the log

• Reboot the device and watch a single domain controller’s System log while it authenticates. One reboot gives you a clean answer for that account.
• If the device authenticates against several domain controllers, check them all – a device can succeed on one and be denied by another if patching is uneven.
• Where a vendor claims support, confirm with the log rather than the release notes. The absence of 5827 for that account after a reboot is the only proof that matters.
• Keep an eye on newly joined devices. Anything that joins the domain running old firmware appears in this list on its first authentication.

Every code this article covers

Confirm the fix worked

1. The account has stopped appearing in 5827 or 5828 on every domain controller, not just the one you were watching.
2. No 5830 or 5831 is written for it either, which would mean it is being allowed by exemption rather than complying.
3. A reboot of the device produces a clean authentication with no new events.
4. The allow-list policy contains only accounts you can name a reason and a date for.
5. 5829 entries have stopped, or are down to devices already on the replacement plan.

Questions people ask about this