Netlogon Secure Channel fails over WiFi after KB5068865 - ERROR_ACCESS_DENIED (0x5) / WSAEACCES (10013)

Question

Netlogon Secure Channel fails over WiFi after KB5068865 - ERROR_ACCESS_DENIED (0x5) / WSAEACCES (10013)

Anatolijs Artemjevs 45

Environment:

Client: Windows 10/11, domain member TESTAPC.vdzti.local
DC: Windows Server 2016 (build 14393), KB5070882 (October 2025)
Client updates: KB5068865 (November 2025)

Problem: Group Policy does not apply over WiFi. Netlogon Secure Channel cannot be established over any WiFi adapter, but works correctly over wired Ethernet.

Symptoms:

nltest /sc_verify:vdzti.local returns ERROR_ACCESS_DENIED (0x5) over WiFi
netlogon.log: I_NetServerReqChallenge fails with 0xc0000022, extended error status 10013 (WSAEACCES)
Wireshark capture shows: client queries EPM on port 135, receives correct Netlogon port (49668), but never sends TCP SYN to port 49668
The decision not to connect is made inside RPC runtime on the client before any TCP connection attempt
TCP connectivity to port 49668 is confirmed working (Test-NetConnection succeeds)
Kerberos tickets obtained successfully over WiFi
SMB/SYSVOL accessible over WiFi by hostname
Problem reproduces on all WiFi adapters (USB and built-in)
Problem does not reproduce over wired Ethernet

What was ruled out:

Network/firewall blocking (TCP to 49668 works fine)
DNS resolution issues
Kerberos authentication failures
DC firewall rules (none blocking)
RPC filters on DC (none configured)
DCLocatorRpcPolicy (tested both audit and enforce mode - no change)
NetBT binding on WiFi adapter
VirtualBox NDIS6 driver interference
MTU/fragmentation issues

Key finding from Wireshark: Client sends EPM Map request → receives RPC_NETLOGON TCP Port:49668 response → closes connection with FIN → never attempts TCP SYN to 49668. This behavior is specific to WiFi interface only.

Key finding from netlogon.log:

DenyVulnerableSigningClients = 1

I_NetServerReqChallenge → Status 10013 (WSAEACCES), Detection location 311

Question: What internal check in RPC runtime / lsass.exe prevents TCP connection to Netlogon port after successful EPM response, specifically on WiFi interfaces, after KB5068865?Environment:

Client: Windows 10/11, domain member TESTAPC.vdzti.local
DC: Windows Server 2016 (build 14393), KB5070882 (October 2025)
Client updates: KB5068865 (November 2025)

Problem: Group Policy does not apply over WiFi. Netlogon Secure Channel cannot be established over any WiFi adapter, but works correctly over wired Ethernet.

Symptoms:

nltest /sc_verify:vdzti.local returns ERROR_ACCESS_DENIED (0x5) over WiFi
netlogon.log: I_NetServerReqChallenge fails with 0xc0000022, extended error status 10013 (WSAEACCES)
Wireshark capture shows: client queries EPM on port 135, receives correct Netlogon port (49668), but never sends TCP SYN to port 49668
The decision not to connect is made inside RPC runtime on the client before any TCP connection attempt
TCP connectivity to port 49668 is confirmed working (Test-NetConnection succeeds)
Kerberos tickets obtained successfully over WiFi
SMB/SYSVOL accessible over WiFi by hostname
Problem reproduces on all WiFi adapters (USB and built-in)
Problem does not reproduce over wired Ethernet

<<< 05/27 23:09:58 [SESSION] VDZTI: NlSessionSetup: Try Session setup

05/27 23:09:58 [SESSION] VDZTI: NlDiscoverDc: Found DC \Saturn.vdzti.local

05/27 23:09:58 [CRITICAL] NlPrintRpcDebug: Dumping extended error for I_NetServerReqChallenge with 0xc0000022

05/27 23:09:58 [CRITICAL] [0] Status is 5

05/27 23:09:58 [CRITICAL] [0] Detection location is 313

05/27 23:09:58 [CRITICAL] [1] Status is 10013

05/27 23:09:58 [CRITICAL] [1] Detection location is 311

05/27 23:09:58 [CRITICAL] Long val: 49668

05/27 23:09:58 [CRITICAL] VDZTI: NlSessionSetup: Session setup: cannot I_NetServerReqChallenge 0xc0000022

05/27 23:09:58 [SESSION] VDZTI: NlSessionSetup: negotiated 612fffff flags rather than 0

05/27 23:09:58 [SESSION] VDZTI: NlSessionSetup: denying access due to being unable to authenticate with Netlogon 0xC0000022>>>

What was ruled out:

Network/firewall blocking (TCP to 49668 works fine)
DNS resolution issues
Kerberos authentication failures
DC firewall rules (none blocking)
RPC filters on DC (none configured)
DCLocatorRpcPolicy (tested both audit and enforce mode - no change)
NetBT binding on WiFi adapter
VirtualBox NDIS6 driver interference
MTU/fragmentation issues

Key finding from Wireshark: Client sends EPM Map request → receives RPC_NETLOGON TCP Port:49668 response → closes connection with FIN → never attempts TCP SYN to 49668. This behavior is specific to WiFi interface only.

Key finding from netlogon.log:

DenyVulnerableSigningClients = 1
I_NetServerReqChallenge → Status 10013 (WSAEACCES), Detection location 311

Question: What internal check in RPC runtime / lsass.exe prevents TCP connection to Netlogon port after successful EPM response, specifically on WiFi interfaces, after KB5068865?

0 comments

Answer accepted by question author

Kate Pham (WICLOUD CORPORATION) 825 Microsoft External Staff Moderator

Hi @Anatolijs Artemjevs

Thank you for reaching to Q&A community and contribute with such a great scenario. Given your environment and the specific issue where Group Policy fails to apply over WiFi due to Netlogon Secure Channel errors while everything works correctly over wired Ethernet and the root cause is firewall, much appreciate that.

Technically, Windows Firewall or third-party security software may enforce different rules for WiFi versus wired networks, potentially blocking or restricting outbound RPC connections on dynamic ports.

The dynamic RPC port range (default: 49152–65535) must be open for outbound connections from the client to the DC.
Some firewall profiles (e.g., "Public" for WiFi) may be more restrictive than "Private" or "Domain" profiles used for wired connection.

The key finding is that, with DenyVulnerableSigningClients = 1, the client’s Netlogon process on WiFi is being denied at the OS level (Winsock error 10013) before it can initiate a connection to the Netlogon RPC port. This enforcement is specific to the WiFi interface, likely due to how local security policies or network profiles are applied, and not due to any external network or authentication failure.

Allow me to address your last question "What internal check in RPC runtime / lsass.exe prevents TCP connection to Netlogon port after successful EPM response, specifically on WiFi interfaces, after KB5068865"

After KB5068865, the RPC runtime within lsass.exe introduces an internal validation step that, upon detecting a WiFi interface or a non-compliant security context, prevents the initiation of a TCP connection to the Netlogon port even after a successful EPM response by enforcing updated Netlogon security policies and interface trust requirements.

If you believe this information adds some value, please accept the answer so that your experience with the issue would help contribute to the whole communi_ty.

T&K,

Kate.

0 comments

Answer accepted by question author

AI answer

The behavior described matches Netlogon/RPC hardening changes that return WSAEACCES (10013) when a connection is considered cryptographically or protocol‑wise “vulnerable,” not a pure network block.

From the available information, the only documented internal gate that maps to STATUS_ACCESS_DENIED (0xC0000022) with extended status 10013 (WSAEACCES) in the Netlogon path is the Netlogon/RPC cryptographic enforcement logic introduced for CVE‑2020‑1472 and CVE‑2022‑38023:

Netlogon now enforces secure RPC for machine and trust accounts.
Weak or non‑compliant cryptography (for example, RC4/MD5 or RPC signing without sealing where sealing is required) is rejected.
When a client attempts to use such a configuration, the Netlogon/RPC stack denies the operation and surfaces WSAEACCES (10013) as the extended error.

Relevant documented behaviors:

For CVE‑2020‑1472 (Netlogon secure channel hardening):
- DCs enforce secure RPC for machine accounts and trusts.
- Vulnerable Netlogon secure channel connections are denied unless explicitly allowed via the "Domain controller: Allow vulnerable Netlogon secure channel connections" policy.
- Denials are surfaced as Netlogon errors (5827/5828) and are tied to the FullSecureChannelProtection enforcement logic.
For CVE‑2022‑38023 (Netlogon RC4/MD5 hardening):
- Event 5840 indicates a client using RC4 on the Netlogon secure channel.
- Event 5841 indicates the client is denied because RejectMD5Clients is TRUE.
- The documentation explicitly notes that 5841 is “a sign that the RejectMD5Clients value is set to TRUE,” and that this is an existing Netlogon key controlling rejection of weak cryptography.

In both cases, the decision to deny is made in the Netlogon/RPC security logic before or during secure channel setup, not by the network stack. When the client stack determines that the attempted secure channel would violate these policies (for example, using RC4/MD5 or non‑sealed RPC where sealing is now required), it returns STATUS_ACCESS_DENIED with an extended WSAEACCES (10013) and does not proceed with the TCP connection.

The context provided does not document a WiFi‑specific or interface‑specific internal check in RPC runtime or lsass.exe. It only documents:

Netlogon secure channel enforcement (FullSecureChannelProtection, DenyVulnerableSigningClients/RejectMD5Clients behavior) that denies vulnerable connections.
The mapping of weak cryptography usage to Netlogon events and error codes (including WSAEACCES 10013) when such connections are rejected.

Therefore, based on the available documentation, the internal gate that prevents the TCP connection is the Netlogon/RPC cryptographic enforcement logic (for CVE‑2020‑1472 and CVE‑2022‑38023), which rejects connections it classifies as vulnerable and surfaces WSAEACCES (10013). No additional, WiFi‑specific internal check is described in the provided context.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

3 additional answers

Your answer

Answer 1

Anatolijs Artemjevs 45

Root cause found: Bitdefender Endpoint Security Firewall was blocking Netlogon RPC traffic over WiFi. Disabling Bitdefender Firewall resolved the issue. Group Policy now applies successfully over WiFi.

bl1982 0 Reputation points

2026-07-29T06:59:10.04+00:00

We had the same issue. I was able to trace it back to the network profile of the adapters. In the Bitdefender firewall settings, the wireless adapter was set to "Public". I changed it to "Home/Office" and everything worked fine after that.

Answer 2

Thank you for the response. However, this does not explain the WiFi-specific behavior. The same client machine works perfectly over wired Ethernet connecting to the same DC. Events 5827, 5828, 5840, 5841 are absent on DC. RejectMD5Clients is not configured. The cryptographic configuration is identical on both interfaces of the same machine. The key observation is: over WiFi, the client never sends TCP SYN to Netlogon port 49668 after receiving EPM response — verified via Wireshark. Over wired Ethernet, the TCP connection is established normally. What internal check in lsass.exe/RPC runtime causes different behavior on WiFi vs wired interface on the same machine?

Answer 3

Anatolijs Artemjevs 45

AI answer suggests CVE-2020-1472 / CVE-2022-38023 cryptographic enforcement. However, this does not explain why the issue is WiFi-specific — the same client machine works perfectly over wired Ethernet with the same DC. Events 5840/5841/5827/5828 are not present on DC. RejectMD5Clients is not set. The cryptographic configuration is identical between wired and wireless connections on the same machine.

0 comments