August 2026 CU breaks/fixes secure channel trust with Credential Manager enabled

Question

August 2026 CU breaks/fixes secure channel trust with Credential Manager enabled

Rich Siegel 0

It seems that a constant fail/repair occurs in netlogon.log where Windows 11 patched servers on August 2026 have issues and report NETLOGON 5419 errors in the system event log. This does not happen if CM is disabled.

example:

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSessionSetup: Denied access as we could not authenticate with Kerberos 0xC002002E

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSessionSetup: Denied access as we could not authenticate with Kerberos (translated status) 0xC00000E5

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSetStatusClientSession: Set connection status to c00000e5

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSetStatusClientSession: Unbind from server \REDACTED.fqdn (TCP) 0.

08/24 10:40:54 [MISC] [2852] Eventlog: 5719 (1) "REDACTED" 0xc00000e5 3dc54378 84808124 847d677c e2aadc59 xC.=$...|g}.Y...

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSessionSetup: Session setup Failed

08/24 10:40:54 [SESSION] [2852] REDACTED: NlSessionSetup: Try Session setup

08/24 10:40:54 [MISC] [4044] NlpStoreKeyInDS: Key already provisioned in DS, nothing to do

08/24 10:40:54 [MISC] [4044] NlProvisionMachineAuthKey: Successfully provisioned the machine auth key

0 comments

1 answer

Your answer

Answer 1

Hello @Rich Siegel

The NetLogon.log entries you posted are significant because they closely match a documented Microsoft behavior involving Kerberos-based secure-channel establishment:

NlSessionSetup: Denied access as we could not authenticate with Kerberos 0xC002002E followed by 0xC00000E5 (STATUS_INTERNAL_ERROR) / Event ID 5719.

Microsoft explains that newer Windows builds can initially attempt the secure channel using the newer Kerberos method. If the DC doesn't support that RPC authentication method, the Kerberos attempt fails and Windows normally falls back to the legacy NetLogon method.

However, your case differs from the harmless scenario Microsoft documents because you're reporting repeated fail/repair behavior and actual trust problems, apparently correlated with Credential Manager/Credential Guard being enabled. Microsoft specifically says recurring 5719 events accompanied by authentication or domain-trust failures should be investigated further.

As a diagnostic/workaround, Microsoft documents temporarily disabling Kerberos for secure-channel setup:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters" /v UseKerberosForSecureChannels /t REG_DWORD /d 0 /f

Then restart the machine and test the secure channel:

Test-ComputerSecureChannel -Verbose

If the repeated failures stop with UseKerberosForSecureChannels=0, that strongly indicates the problem is in the Kerberos secure-channel path introduced in newer Windows builds, rather than a conventional machine-account password mismatch.

I wouldn't repeatedly repair/rejoin the machines at this point. Given the correlation with the August 2026 CU, capture the affected Windows build/KB, Event 5719, NetLogon.log, and the Security-NetLogon Operational log, and open a Microsoft support case. Microsoft recommends this specifically when the failure persists and doesn't successfully fall back to NetLogon.

Sharing this reference with you:

Event ID 5719 (STATUS_INTERNAL_ERROR) occurs when the NetLogon service restarts

The key point is that the 0xC002002E → 0xC00000E5 sequence in the posted log is already documented by Microsoft, so there's good evidence this isn't simply a broken AD computer trust.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.