Verifica CachedLogonsCount: REG_SZ e accesso offline

Che cos'è la verifica degli accessi di dominio memorizzati nella cache?

La verifica degli accessi di dominio memorizzati nella cache collega tre elementi di prova sulla stessa workstation pilota: i criteri del computer applicati, il valore e il tipo nel registro locale e un accesso offline osservato. Una segnalazione a livello di criteri avvia questa indagine. Non identifica un account privilegiato nella cache né dimostra che la workstation sia stata compromessa.

Microsoft documenta CachedLogonsCount in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon come REG_SZ. La sua documentazione sugli accessi di dominio memorizzati nella cache indica che zero disabilita la memorizzazione nella cache e che le modifiche dirette a questa chiave di registro richiedono un riavvio. Le indicazioni separate sul riavvio per la Security Option sono trattate nella sezione Correzione. Questi dettagli contano quando un raccoglitore di audit si aspetta un tipo di registro diverso o non rileva il canale di distribuzione dei criteri.

Il risultato pratico è un registro della decisione: quale dispositivo è stato esaminato, cosa dovrebbe consentire, cosa è stato effettivamente osservato e chi ha accettato eventuali eccezioni residue. La procedura seguente è un flusso di verifica proposto, non un resoconto di test eseguiti su un dominio in produzione. Le fonti e il comportamento del rilevatore sono stati verificati il 6 ottobre 2026; per questo articolo non è stato eseguito alcun accesso a Windows né alcun comando di correzione.

Come funziona: distinguere criteri, tipo e disponibilità

Utilizzare tre livelli di prova con conclusioni separate:

I primi due sono osservazioni della configurazione. Il terzo è un'osservazione del comportamento con un'identità, una macchina e un momento specifici. Mantenere queste precisazioni nella conclusione finale. Un test riuscito su un portatile non copre tutti i portatili della sua OU, e un test fallito richiede una spiegazione prima di poter sostenere una decisione di modifica.

La nostra guida al rafforzamento di RDP distingue le decisioni su NLA, livello di sicurezza e delega delle credenziali. Tratta già le impostazioni degli accessi nella cache insieme a questi controlli. Questo flusso aggiunge le prove necessarie quando la segnalazione sugli accessi nella cache contraddice la configurazione dell'endpoint; non ripete la guida generale alla configurazione di RDP.

Mantenere separato anche il lavoro sull'isolamento delle credenziali. La guida a Credential Guard dopo un aggiornamento verifica le eccezioni ereditate e il servizio in esecuzione. Utilizzare tale indagine per la sua specifica domanda sullo stato di protezione. Né una lettura del registro degli accessi nella cache né il rilevatore descritto di seguito misura il funzionamento di Credential Guard.

Definire prima il pilota e il comportamento richiesto

Prima di raccogliere le prove, indicare il responsabile del pilota e il flusso di lavoro dell'utente che richiede accesso offline. Descrivere il risultato atteso in termini operativi: per esempio, se un utente di test non privilegiato designato debba raggiungere il desktop locale durante una perdita pianificata di connettività con il dominio. È un criterio di accettazione specifico dell'organizzazione, non una quota universale di cache di Microsoft o ANSSI.

Registrare l'autorità responsabile della modifica, la finestra di manutenzione, il contatto per il ripristino e la data di riesame. Se non esiste un requisito offline concordato, non lasciare che il messaggio del rilevatore diventi implicitamente tale requisito. Chiedere al responsabile di scegliere il comportamento previsto prima di proporre un valore.

Verifica: riconciliare la GPO applicata e il REG_SZ locale

Passo 1: acquisire il rapporto dei criteri risultanti del computer

Sul pilota, utilizzare la sintassi e le opzioni di output documentate di gpresult. Questi comandi locali adattano tale sintassi all'ambito computer; eseguire ciascuno separatamente in un prompt dei comandi Windows autorizzato:

gpresult /scope computer /r

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

Il primo restituisce dati di riepilogo; il secondo salva un rapporto HTML. Su Windows ARM64, Microsoft specifica che l'opzione /h richiede l'eseguibile gpresult in SysWow64. Il nome di file relativo è un esempio: selezionare la directory delle prove approvata per la revisione effettiva. Conservare l'identità del computer e l'ora di raccolta del rapporto, quindi esaminare le prove specifiche dell'impostazione disponibili nel rapporto. Un elenco di nomi di GPO applicate fornisce un contesto utile ma non identifica, da solo, quale valore abbia prevalso per questa Security Option.

Per la GPO pertinente, conservare nome, GUID, versione e l'esatta impostazione degli accessi nella cache ricavata dalle prove amministrative. Confrontarli con le informazioni sui criteri risultanti del pilota. Quando il rapporto non stabilisce l'origine dell'impostazione, registrarne la provenienza come irrisolta e ottenere prove specifiche dell'impostazione prima di decidere quali criteri modificare.

Esaminare il file Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf della GPO pertinente e la sua voce [Registry Values], quando presente. Conservare soltanto l'estratto specifico dell'impostazione e l'identità dei criteri necessari per questa revisione. Questo controllo è motivato dal punto cieco documentato del raccoglitore sul canale standard, descritto più avanti. Una dichiarazione SYSVOL deve comunque essere riconciliata con il pilota; non sostituire le prove dei criteri applicati con la dichiarazione di una GPO estranea.

Passo 2: leggere il valore locale senza nasconderne il tipo

Utilizzare la documentazione di reg query con il percorso Winlogon e il nome del valore documentati:

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

Si tratta di un adattamento della sintassi in sola lettura, non di un comando copiato da un esempio completo di Microsoft. Esaminare il nome del valore, il tipo e i dati restituiti. Per la configurazione documentata, aspettarsi l'etichetta di tipo REG_SZ e il testo numerico configurato. Non filtrare la query per DWORD: così si nasconderebbe proprio la discrepanza di tipo oggetto dell'indagine.

Archiviare l'output effettivo insieme al rapporto dei criteri. Se il valore manca, il tipo è diverso, l'accesso fallisce o l'output è stato raccolto su un altro host, qualificare esplicitamente l'osservazione. Nessuno di questi esiti autorizza a inventare un valore locale di dieci a partire da un messaggio di audit.

Costruire una riga di riconciliazione per il pilota con l'origine dei criteri riportata, le prove GptTmpl.inf, il tipo e i dati locali, l'ora di raccolta e il contesto di riavvio. Assegnare alle discrepanze un responsabile e un'azione successiva. Per esempio, uno zero REG_SZ documentato insieme a una segnalazione persistente indica la limitazione del raccoglitore; non è un motivo per riscrivere il valore della workstation come DWORD per far scomparire l'audit.

Rilevamento: conservare LsaSrv 45058 e provare l'accesso offline

L'articolo Microsoft sulla risoluzione dei problemi di LsaSrv 45058 descrive un evento informativo del registro System che registra la rimozione della voce utente nella cache più vecchia quando viene raggiunta la quota. L'evento identifica l'utente rimosso e il timestamp della voce. Fornisce un contesto utile per un errore di accesso offline; non dimostra un furto di credenziali.

Se l'evento esiste nel periodo pertinente, conservare ora dell'evento, computer, origine, ID evento, identità di test rimossa e timestamp della voce. Correlarlo alla sequenza temporale degli accessi del pilota. Se la raccolta o la conservazione è incompleta, registrare la lacuna. Trattare l'assenza di un evento osservato come una limitazione delle prove, non come un inventario completo delle identità nella cache.

Passo 3: utilizzare un'identità non privilegiata e registrare le condizioni

Scegliere un'identità di test di dominio dedicata e non privilegiata il cui responsabile autorizzi l'esercizio. Registrare come l'assenza di accesso privilegiato sia stata verificata attraverso il processo di revisione degli account dell'organizzazione. Non utilizzare un amministratore privilegiato solo perché il titolo del rilevatore menziona gli account privilegiati.

Pianificare un test di accesso alla console locale con un percorso di ripristino approvato. Registrare la situazione iniziale online, la condizione di rete controllata, come è stata esclusa la raggiungibilità dei controller di dominio, il metodo di accesso e l'esatto risultato osservato. Ripristinare la connettività dopo l'esercizio. Se non si può stabilire la condizione di rete del test, riportare il risultato come inconcludente.

La conclusione deve essere circoscritta: l'identità di test indicata ha raggiunto o meno il desktop sul pilota indicato nelle condizioni specificate. Microsoft precisa separatamente che l'accesso al desktop offline non fornisce accesso alle risorse che richiedono la convalida del dominio. Non presentare un accesso al desktop riuscito come un accesso riuscito ai servizi di dominio.

Se una rimozione richiede un'indagine, utilizzare un evento 45058 osservato per l'identità di test o un esercizio di laboratorio approvato separatamente. Non far avvicendare account di produzione soltanto per forzare un evento. Registrare «rimozione non osservata» quando questa è la prova disponibile. Per questo protocollo non servono un dump della cache, un'esportazione del verificatore, un'estrazione degli hive del registro o un recupero di password.

Passo 4: registrare la decisione prima di modificare l'impostazione

Un registro di revisione utile può utilizzare questo modello:

Porre tre domande esplicite durante la revisione: Quale pilota e quale vincolo offline giustificano un'eccezione? Quali prove GptTmpl.inf/REG_SZ e quale GPO risultante devono essere conservate quando la segnalazione diverge dallo stato locale? Quale identità non privilegiata può dimostrare il comportamento pertinente senza gestire segreti? Indicare il responsabile della decisione invece di lasciare implicite queste domande.

Correzione: applicare la decisione e ripetere il controllo pilota (Remediation)

Se la decisione approvata è di modificare la memorizzazione nella cache, utilizzare la Security Option identificata nell'articolo 45058 di Microsoft: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, quindi Interactive logon: Number of previous logons to cache (in case domain controller is not available). Limitare la modifica ai dispositivi previsti.

Per una decisione di disabilitare la cache, Microsoft documenta zero come valore di disattivazione. Un'eccezione che mantenga la memorizzazione nella cache richiede una propria giustificazione operativa, un responsabile e una data di riesame. Non trasformare il massimo globale del rilevatore, il suo messaggio sul valore predefinito di dieci o una rimozione informativa in una quota universale accettabile.

La documentazione Microsoft sulla Security Option afferma che le modifiche ai criteri hanno effetto senza riavvio quando vengono salvate localmente o distribuite tramite Group Policy. Il suo articolo sulla risoluzione dei problemi del registro richiede separatamente un riavvio per le modifiche dirette alla chiave di registro. Registrare quale percorso di configurazione è stato utilizzato e seguire le indicazioni documentate sul riavvio per quel percorso. Dopo che la modifica ha avuto effetto, ripetere lo stesso rapporto dei criteri, la lettura del tipo e del valore locali e il test pilota controllato. Confrontare elementi equivalenti: gli stessi livelli di prova e lo stesso criterio di accettazione. Conservare le differenze irrisolte invece di chiudere il registro solo perché l'audit non segnala più nulla.

Per un utente interessato dalla rimozione, il ripristino documentato da Microsoft consiste nel ristabilire la connettività e la risoluzione dei nomi del controller di dominio e completare un accesso al dominio autenticato; la nuova memorizzazione nella cache dipende dall'abilitazione della cache. Mantenere il ripristino distinto da una decisione sui criteri per ampliare la quota. Una sessione utente ripristinata non giustifica da sola una modifica della configurazione dell'intero parco.

Come EtcSec rileva questo problema

Il controllo BP039_PRIV_ACCOUNTS_CACHED di etc-collector di EtcSec, letto al commit bcd03c54, esamina le impostazioni di registro delle GPO raccolte. Qualsiasi CachedLogonsCount zero osservato in qualsiasi GPO sopprime la segnalazione. Altrimenti restituisce un'unica segnalazione di gravità Medium con Count=1, anche quando non è stato raccolto alcun valore GPO. Il suo valore worstSeen è il massimo fra le GPO raccolte, non i criteri risultanti di ciascuna workstation.

Il provider popola questo campo da Registry.pol tramite getDWORDValue, che accetta REG_DWORD. Microsoft documenta l'impostazione effettiva come REG_SZ. Il parser GptTmpl.inf non popola CachedLogonsCount da [Registry Values]. Il codice stesso del rilevatore spiega che il canale standard della Security Option può quindi essere invisibile e produrre un falso positivo.

Due conseguenze devono figurare nel registro di revisione. Uno zero del canale standard può coesistere con una segnalazione; viceversa, uno zero osservato in un'altra GPO può sopprimere la segnalazione senza dimostrare la copertura del pilota. Il riferimento al valore predefinito di Windows di dieci nel messaggio di assenza di valore è un'inferenza di quel messaggio, non un'impostazione locale misurata.

Questo controllo non osserva un account specifico nella cache, i suoi privilegi effettivi, una compromissione, eventi LsaSrv, il comportamento di accesso offline o il funzionamento di Credential Guard. Trattarlo come una richiesta di verificare la configurazione attraverso il canale corretto. Chiudere la revisione del pilota con le prove dei criteri, l'osservazione REG_SZ locale, il risultato del comportamento e la decisione autorizzata; mantenere visibile qualsiasi copertura del parco non misurata.