Blog Post

Ask the Directory Services Team
3 MIN READ

Stop Worrying and Love the Outage, Vol III: Cached Logons

Chris_Cartwright's avatar
Jun 20, 2024

This is the third article in a series:
Stop Worrying and Love the Outage, Vol I: Group Policy and Sharing Violations
Stop Worrying and Love the Outage, Vol II: DCs, custom ports, and Firewalls/ACLs
Stop Worrying and Love the Outage, Vol III: Cached Logons
Stop Worrying and Love the Outage, Vol IV: Preference items | Microsoft Community Hub

        Hello, Chris Cartwright here from the Directory Services support team.  This is the third post in a series where I try to provide the IT community with some tools and verbiage that will hopefully save you and your business many hours, dollars, and frustrations.  Occasionally, we get cases for users working remotely that are unable to log on with a message that the domain is not available.  More often than not, this is caused by an overly enthusiastic Cached Logon configuration.

 

 

The setting:

 

 

        The “Interactive logon: Number of previous logons to cache (in case domain controller is not available)” policy setting controls whether cached account information can be used to sign in to a Windows domain.  When a user signs in to a domain account, the sign-in information can be stored locally so that, if a domain controller is unreachable later, the user can still sign in.  If a user’s credentials are not cached, you should get one of the following errors:

 

There are currently no logon servers available to service the logon request.

 

We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential.

 

The domain specified is not available.  Please try again later.

This policy setting specifies how many different users' sign-in information can be kept locally, but it leaves out some rather important details like:

  • Cached logon is based on the method used for logon.  Smart card (per issuer), passwords, and Windows Hello logons have their own cache entry per user. 
  • You cannot cache a new entry without line of sight to a Domain Controller. 
  • New smart cards require a new entry and will overwrite an existing one if from same issuer.
  • Service accounts also have their own entry

        By default, the number of cached logons setting is set to a value of 10, which is generally high enough for most organizations.  The security risk for this setting is based on use/abuse of the cached credentials by bad actors.  Security is a balancing act. 

Consider the following points as well:

 

“The Windows security baselines don’t recommend configuring  [the number of previously cached logons].”

“…the server overwrites the oldest cached sign-in session.”

“Users can't sign in to any devices if there's no domain controller available to authenticate them.”

 

        So, when your compliance team comes in and tells you to set this to lower values, especially 1 or 0, make sure you know your environment.  Issues from miscalculating this cache value range from remote users being unable to log on to (worst case) data loss.  After reading this, I hope in future conversations you feel better armed to respond with the potential risks associated with this setting and can avoid this kind of outage without having to learn the hard way!

 

References:

Interactive logon Number of previous logons to cache (in case domain controller is not available) - Windows 10 | Microsoft Learn

Cached domain logon information - Windows Server | Microsoft Learn

 

 

Updated Jan 28, 2025
Version 3.0

5 Comments

  • DRgooglesthings's avatar
    DRgooglesthings
    Copper Contributor

    ChrisKnight - could you expand on the registry fix steps in layman's terms? I'm troubleshooting the same issue as level 1 tech. Our affected machines were not upgraded from Win 10 (fresh install of 11). 

     

    I've reviewed HK LM\System\CurrentControlSet\Control\Lsa\MSV1_0 and confirmed it is the same on a working machine. 

     

    Did you have to search and compare every hive in the registry?

    • ChrisKnight's avatar
      ChrisKnight
      Brass Contributor

      MSV1_0 subkey was entirely missing on my impacted systems. All other Credential Guard-related registry entries were correct (did a compare of HKLM on a clean install vs an impacted system).

      I exported this subkey from a clean install of a working Windows 11 system, imported on the impacted systems and tested the cached logon on the impacted systems. It fixed the problem on all impacted systems.

      Sounds like you have a different problem. Recommend you check out the https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues.

  • ChrisKnight's avatar
    ChrisKnight
    Brass Contributor

    Yep, absolutely an abnormal result. Didn't post it for diagnosis, just an observation across a range of Windows 11 devices where I've experienced this.

     

    They'd all fail with Credential Guard enabled and no line-of-sight to a DC, with an "RPC call failed" error, LSASS crashing (0xC0000409) and insta-rebooting the system. Systems could be used without line-of-sight to a DC with Credential Guard disabled.

     

    So I finally had some time to spin up a test system with a clean Windows 11 install and it works as expected, so pulled the telemetry from the impacted systems and worked out they were all upgrades from Windows 10. Then proceeded to gather all the Device Guard-related registry keys and perform a diff against the Windows 11 working baseline. All impacted systems had the Lsa\MSV1_0 subkey missing as a commonality. Replaced the missing subkey and values from the clean install of Windows 11, rebooted a couple of impacted systems with Credential Guard enabled and no line-of-sight to a DC and hey presto - cached credentials working again! Interestingly, Lsa\MSV1_0 subkey now holds an IsolatedCredentialsRootSecret value, so I'm wondering if the absence of this value was the root cause for the LSASS crash/insta-reboot.

     

    Anyway, thanks for this blog post and your reply. If it wasn't for that I probably would have spent time on working through other annoying misconfigurations - either mine or Microsoft-induced 🙂

  • stryqx That is an abnormal result.  However, it isn't a problem that can be diagnosed here.  To receive assistance with this, you may wish to open a support case and collect some diagnostic data to investigate it.

  • stryqx's avatar
    stryqx
    Brass Contributor

    You don't get any of these errors when cached logons are enabled, the Windows 11 client device has Credential Guard enabled and there's no line of sight to a DC - you get informed that your logon failed and LSASS helpfully insta-reboots your client device after a 30-60 second delay. Been happening for many, many months now so I'm assuming that cached logons with Credential Guard enabled isn't a tested scenario.