Cached domain logon verification: REG_SZ and offline sign-in

What Is Cached Domain Logon Verification?

Cached domain logon verification connects three pieces of evidence on the same pilot workstation: the applied computer policy, the local registry value and type, and an observed offline sign-in. A policy-level finding starts that investigation. It does not identify a privileged account in the cache or prove that the workstation has been compromised.

Microsoft documents CachedLogonsCount under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon as REG_SZ. Its cached domain logon reference states that zero disables caching and that direct changes to this registry key require a restart. The Security Option's separate restart guidance is covered under Remediation. These details matter when an audit collector expects a different registry type or misses the policy's delivery channel.

The practical deliverable is a decision record: which device was reviewed, what it should allow, what was actually observed, and who accepted any remaining exception. The procedure below is a proposed verification workflow, not a report of tests performed on a live domain. Sources and detector behavior were checked on 6 October 2026; no Windows sign-in or remediation command was executed for this article.

How It Works: Keep Policy, Type and Availability Separate

Use three evidence layers with separate conclusions:

The first two are configuration observations. The third is a behavior observation with a specific identity, machine and time. Keep those qualifiers in the final statement. A successful test on one laptop does not cover every laptop in its OU, and a failed test needs an explanation before it can support a change decision.

Our RDP hardening guide separates NLA, security-layer and credential-delegation decisions. It already discusses cached-logon settings alongside those controls. This workflow adds the evidence needed when the cached-logon finding disagrees with endpoint configuration; it does not repeat the broader RDP configuration guide.

Also keep credential-isolation work separate. The Credential Guard after-upgrade guide checks inherited exceptions and the running service. Use that investigation for its own protection-state question. Neither a cached-logon registry read nor the detector described below measures Credential Guard runtime.

Decide the pilot and the required behavior first

Before collecting evidence, name the pilot owner and the user workflow that requires offline access. Describe the expected outcome in operational terms: for example, whether a designated nonprivileged test user must reach the local desktop during a planned loss of domain connectivity. That is an organization-specific acceptance criterion, not a universal Microsoft or ANSSI cache quota.

Record the change authority, maintenance window, recovery contact and review date. If there is no agreed offline requirement, do not let the detector's message silently become the requirement. Ask the responsible owner to choose the intended behavior before proposing a value.

Verification: Reconcile the Applied GPO and Local REG_SZ

Step 1: Capture the computer's resultant-policy report

On the pilot, use the documented gpresult syntax and output options. These local commands adapt that syntax to computer scope; run each separately in an authorized Windows command prompt:

gpresult /scope computer /r

gpresult /scope computer /h cached-logon-computer-policy.html

The first returns summary data; the second saves an HTML report. On ARM64 Windows, Microsoft specifies that the /h option requires the gpresult executable in SysWow64. The relative filename is an example: select the approved evidence directory for the actual review. Preserve the report's computer identity and collection time, then inspect the setting-specific evidence available in the report. A list of applied GPO names is useful context but does not, by itself, identify which value won for this Security Option.

For the relevant GPO, retain its name, GUID, version and the exact cached-logon setting from the administrative evidence. Compare that with the pilot's resultant-policy information. Where the report does not establish the setting's source, record provenance as unresolved and obtain setting-specific evidence before deciding which policy to change.

Inspect the relevant GPO's Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf and its [Registry Values] entry when present. Preserve only the setting-specific excerpt and the policy identity needed for this review. This check is motivated by the collector's documented standard-channel blind spot, detailed below. A SYSVOL declaration still needs to be reconciled with the pilot; do not substitute an unrelated GPO's declaration for applied-policy evidence.

Step 2: Read the local value without hiding its type

Use the reg query reference with the documented Winlogon path and value name:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

This is a read-only syntax adaptation, not a command copied from a Microsoft worked example. Inspect the returned value name, type and data. For the documented configuration, expect the type label REG_SZ and the configured numeric text. Do not filter the query to DWORD: doing so would conceal the very type mismatch under investigation.

Store the actual output alongside the policy report. If the value is missing, the type differs, access fails or the output was collected from another host, label that observation explicitly. None of those outcomes is permission to manufacture a local value of ten from an audit message.

Build a reconciliation row for the pilot containing the reported policy source, GptTmpl.inf evidence, local type/data, collection time and reboot context. Give discrepancies an owner and a next action. For instance, a documented REG_SZ zero alongside a continuing finding points toward the collector limitation; it is not a reason to rewrite the workstation value as DWORD to make the audit disappear.

Detection: Preserve LsaSrv 45058 and Test Offline Sign-in

Microsoft's LsaSrv 45058 troubleshooting article describes an informational System log event recording eviction of the oldest cached user entry when the quota is reached. The event identifies the removed user and the entry's timestamp. It supplies useful context for an offline sign-in failure; it does not establish credential theft.

If the event exists in the relevant period, retain its event time, computer, source, event ID, removed test identity and entry timestamp. Correlate it with the pilot's sign-in timeline. If collection or retention is incomplete, record that gap. Treat absence of an observed event as an evidence limitation, not as a complete inventory of cached identities.

Step 3: Use a nonprivileged identity and record conditions

Choose a dedicated nonprivileged domain test identity whose owner authorizes the exercise. Record how its lack of privileged access was verified through the organization's account-review process. Do not use a privileged administrator simply because the detector's title mentions privileged accounts.

Plan a local-console sign-in test with an approved recovery route. Record the online baseline, the controlled network condition, how domain-controller reachability was excluded, the sign-in method and the exact observed result. Restore connectivity after the exercise. If the test's network condition cannot be established, report the result as inconclusive.

The outcome statement should be narrow: the named test identity did or did not reach the desktop on the named pilot under the stated conditions. Microsoft separately notes that offline desktop access does not provide access to resources requiring domain validation. Do not report desktop success as successful domain-service access.

If an eviction needs investigation, use an observed 45058 event for the test identity or a separately approved lab exercise. Do not churn production accounts merely to force an event. Record “eviction not observed” when that is the available evidence. No cache dump, verifier export, registry-hive extraction or password recovery is needed for this protocol.

Step 4: Record the decision before changing the setting

A useful review record can use this template:

Ask three explicit questions at the review gate: Which pilot and offline constraint justify an exception? Which GptTmpl.inf/REG_SZ evidence and resultant GPO should be retained when the finding diverges from local state? Which nonprivileged identity can demonstrate the relevant behavior without handling secrets? Name the decision owner rather than leaving these questions implicit.

Remediation: Apply the Decision and Repeat the Pilot Check

If the approved decision is to change caching, use the Security Option identified in Microsoft's 45058 article: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, then Interactive logon: Number of previous logons to cache (in case domain controller is not available). Scope the change to the intended devices.

For a decision to disable caching, Microsoft documents zero as the disabling value. An exception that retains caching needs its own workflow justification, owner and review date. Do not turn the detector's global maximum, its default-ten message or an informational eviction into a universal acceptable quota.

Microsoft's Security Option reference says policy changes take effect without a restart when saved locally or distributed through Group Policy. Its registry troubleshooting article separately requires a restart for direct changes to the registry key. Record which configuration route was used and follow that route's documented restart guidance. After the change takes effect, repeat the same policy report, local type/value read and controlled pilot test. Compare like with like: the same evidence layers and acceptance criterion. Retain unresolved differences instead of closing the record solely because the audit becomes quiet.

For a user affected by eviction, Microsoft's documented recovery is to restore domain-controller connectivity and name resolution and complete an authenticated domain sign-in; recaching depends on caching being enabled. Keep recovery distinct from a policy decision to enlarge the quota. A restored user session does not by itself justify a fleet-wide configuration change.

How EtcSec Detects This

EtcSec's etc-collector check BP039_PRIV_ACCOUNTS_CACHED, read at commit bcd03c54, examines collected GPO registry settings. Any observed CachedLogonsCount zero in any GPO suppresses the finding. Otherwise it returns one Medium-severity finding with Count=1, including when no GPO value was collected. Its worstSeen value is the maximum across the collected GPOs, not the resultant policy for each workstation.

The provider populates this field from Registry.pol using getDWORDValue, which accepts REG_DWORD. Microsoft documents the actual setting as REG_SZ. The GptTmpl.inf parser does not populate CachedLogonsCount from [Registry Values]. The detector's own code explains that the standard Security Option channel can therefore be invisible and produce a false positive.

Two consequences belong in the review record. A standard-channel zero can coexist with a finding; conversely, a zero observed in another GPO can suppress the finding without proving coverage of the pilot. The no-value message's reference to the Windows default of ten is an inference in that message, not a measured local setting.

This check does not observe a specific cached account, its effective privileges, compromise, LsaSrv events, offline sign-in behavior or Credential Guard runtime. Treat it as a request to verify configuration through the proper channel. Close the pilot review with the policy evidence, local REG_SZ observation, behavior result and authorized decision; keep any unmeasured fleet coverage visible.