SEC_I_LOCAL_LOGON 0x00090315: Local Logon Without Network Authority

Quick answer: 0x00090315 is an informational status code, not a failure. Windows authenticated you with cached credentials because it couldn't reach a domain controller at sign-in, and that's usually the right behavior. The fix is finding out why the DC wasn't reachable, not suppressing the code.

What SEC_I_LOCAL_LOGON actually means

The SEC_I_LOCAL_LOGON code is the informational status returned when Windows performs a local logon using cached domain credentials. The I in the name matters. It stands for Informational. Microsoft carved out an entire range of SEC_I_* status codes for events that are noteworthy but not failures, and this is one of them.

You'll most often see it in the Security log as part of Event ID 4624 (An account was successfully logged on). The Status and Sub Status fields show 0x0 and 0x0 for a normal interactive domain logon. When you spot 0x00090315 in either field, Windows is telling you the logon succeeded, but the local Security Accounts Manager (SAM) handled it instead of Kerberos talking to a DC.

Here's the trigger that catches most people. A laptop user closes the lid at the office, drives home, opens it, and signs in on hotel Wi-Fi or a home router that's still negotiating DHCP. The cached credential hashes in HKEY_LOCAL_MACHINE\SECURITY\Cache let Windows validate the password locally. You get a session, you get a 4624, and you get SEC_I_LOCAL_LOGON because there's no DC in sight. Same thing happens when a VPN isn't up yet, a WAN link is flapping, or the DC is down for patching.

If the user can still reach everything they need, do nothing. Seriously. Chasing this code during a DC outage wastes time and tempts you into disabling cached logons, which is a great way to lock remote users out of their own machines.

When you should care

Treat it as a real problem only when one of these is true:

• The user can log on but can't reach mapped drives, printers, or file shares (cached logon without a token for those resources).
• You see it on a wired desktop that should always have line-of-sight to a DC.
• It fires for every user on the same subnet at once — that's a network or DC problem, not a client problem.
• You also see Netlogon 5719, Group Policy 1129, or NtpClient warnings within the same minute.

Confirm the cause

1. Check DC reachability from the affected machine. Open an elevated Command Prompt and run:

   nltest /dsgetdc:yourdomain.com /force

   You should get a DC name, IP, and site. If it times out or returns error 1355 ("The specified domain either does not exist or could not be contacted"), the client can't find a DC. That alone explains the code.
2. Verify DNS is pointing at a DC. Run ipconfig /all and look at the DNS servers on the active adapter. If they're set to a public resolver like 8.8.8.8 or 1.1.1.1, that's your bug. Domain-joined clients must use internal DNS that hosts the SRV records for _ldap._tcp.dc._msdcs.yourdomain.com. Fix it:

   netsh interface ip set dns "Ethernet" static 10.0.0.10 primary
   netsh interface ip add dns "Ethernet" 10.0.0.11 index=2
   ipconfig /flushdns
   ipconfig /registerdns

3. Test the secure channel. On the client:

   nltest /sc_verify:yourdomain.com

   A healthy machine returns "NERR_Success" for both the trust verification and the secure channel. "Access is denied" or a 5-minute timeout means the machine account password is out of sync. Reset it with:

   Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential)

   Reboot and sign in again.
4. Check the clock. Kerberos refuses any ticket with more than 5 minutes of skew by default. If the client's clock drifted during a long offline stretch, it may be rejecting DC responses. Run w32tm /query /status and look at the "Source" and "Last Successful Sync Time" lines. Force a resync:

   w32tm /resync /force

5. Look at the cached logon count. The default is 10 cached logons per machine. If HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount is set to 0, cached logons are disabled and the user should have gotten a hard failure instead. Somebody probably set that and the code is showing up because the policy is inconsistent across the fleet.
6. Check the site link. If the client is in a branch office with a slow or down WAN link to the hub DCs, it may be timing out on AD site discovery and falling back to cached creds. Run nltest /dsgetsite on the client and compare to the DC it should be using.

If the main fix doesn't stick

Try these in order:

• Restart Netlogon and the Workstation service. Sounds basic. It resolves a surprising number of stuck-secure-channel cases.

  net stop netlogon && net start netlogon
  net stop lanmanworkstation && net start lanmanworkstation

• Rejoin the domain. If nltest /sc_verify keeps failing after a password reset, remove the machine from the domain, reboot, and rejoin. Yes, it's heavy-handed. It's also the fastest fix when you've been fighting this for an hour.
• Check the DC's Netlogon and KDC services. If it's a single-DC environment and that DC is down, no client-side fix exists. Bring the DC up or promote a second one before you spend more time on the client.
• Look at firewall rules on the client. A third-party endpoint agent that blocks outbound 88, 389, 445, or 3268 will produce this code and nothing else. Test with the agent temporarily disabled.

Prevention

Keep at least two internal DNS servers configured on every domain-joined adapter, and never put a public resolver on one. Make sure your branch offices have a local read-only domain controller or a reliable site link, because cached logons are a fallback, not a design. And leave the default 10 cached logons alone. Admins who bump it to 50 to "help remote users" are just widening the credential cache for anyone who steals the laptop. If you want to monitor this proactively, set an alert on Security Event ID 4624 where Sub Status equals 0x00090315 and watch for trends — three clients in one hour is a DC problem, one laptop a week is a mobile user problem, and neither deserves an all-hands.