Verificar logon de dominio em cache: REG_SZ e acesso offline

O que significa verificar o logon de domínio em cache?

Verificar logon de dominio em cache reúne três elementos de evidência na mesma estação de trabalho piloto: a política de computador aplicada, o valor e o tipo locais no registro e um logon offline observado. Uma constatação no nível da política inicia essa investigação. Ela não identifica uma conta privilegiada no cache nem comprova que a estação de trabalho foi comprometida.

A Microsoft documenta CachedLogonsCount em HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon como REG_SZ. Sua referência sobre logon de domínio em cache informa que zero desativa o cache e que alterações diretas nessa chave de registro exigem uma reinicialização. A orientação separada de reinicialização da Security Option é tratada na seção de remediação. Esses detalhes importam quando um coletor de auditoria espera um tipo de registro diferente ou não identifica o canal de distribuição da política.

O resultado prático é um registro de decisão: qual dispositivo foi analisado, o que ele deve permitir, o que foi realmente observado e quem aceitou qualquer exceção remanescente. O procedimento abaixo é um fluxo de verificação proposto, não um relato de testes realizados em um domínio em produção. As fontes e o comportamento do detector foram verificados em 6 de outubro de 2026; nenhum logon do Windows nem comando de remediação foi executado para este artigo.

Como funciona: separar política, tipo e disponibilidade

Use três camadas de evidência com conclusões distintas:

As duas primeiras são observações de configuração. A terceira é uma observação de comportamento com uma identidade, máquina e horário específicos. Mantenha essas qualificações na declaração final. Um teste bem-sucedido em um laptop não abrange todos os laptops de sua OU, e um teste malsucedido precisa de uma explicação antes de fundamentar uma decisão de mudança.

Nosso guia de proteção de RDP separa as decisões sobre NLA, camada de segurança e delegação de credenciais. Ele já aborda as configurações de logon em cache junto com esses controles. Este fluxo acrescenta as evidências necessárias quando a constatação sobre logon em cache diverge da configuração do endpoint; não repete o guia mais amplo de configuração de RDP.

Mantenha também o trabalho de isolamento de credenciais separado. O guia de Credential Guard após uma atualização verifica exceções herdadas e o serviço em execução. Use essa investigação para a respectiva questão de estado da proteção. Nem a leitura do registro de logon em cache nem o detector descrito abaixo medem o estado de execução de Credential Guard.

Definir primeiro o piloto e o comportamento necessário

Antes de coletar evidências, identifique o responsável pelo piloto e o fluxo de trabalho do usuário que exige acesso offline. Descreva o resultado esperado em termos operacionais: por exemplo, se um usuário de teste designado e sem privilégios deve acessar a área de trabalho local durante uma perda planejada de conectividade com o domínio. Esse é um critério de aceitação específico da organização, não uma cota universal de cache da Microsoft ou da ANSSI.

Registre a autoridade para a mudança, a janela de manutenção, o contato de recuperação e a data de revisão. Se não houver um requisito offline acordado, não deixe que a mensagem do detector se torne silenciosamente o requisito. Peça ao responsável que escolha o comportamento desejado antes de propor um valor.

Verificação: conciliar a GPO aplicada e o REG_SZ local

Etapa 1: capturar o relatório de política resultante do computador

No piloto, use a sintaxe e as opções de saída documentadas de gpresult. Estes comandos locais adaptam essa sintaxe ao escopo do computador; execute cada um separadamente em um prompt de comando do Windows autorizado:

gpresult /scope computer /r

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

O primeiro retorna dados resumidos; o segundo salva um relatório HTML. No Windows ARM64, a Microsoft especifica que a opção /h exige o executável gpresult de SysWow64. O nome de arquivo relativo é um exemplo: selecione o diretório de evidências aprovado para a revisão real. Preserve a identidade do computador e o horário da coleta do relatório, depois examine as evidências específicas da configuração disponíveis nele. Uma lista dos nomes das GPOs aplicadas é um contexto útil, mas não identifica, por si só, qual valor prevaleceu para essa Security Option.

Para a GPO relevante, retenha seu nome, GUID, versão e a configuração exata de logon em cache obtida nas evidências administrativas. Compare isso com as informações de política resultante do piloto. Quando o relatório não estabelecer a origem da configuração, registre a proveniência como não resolvida e obtenha evidências específicas da configuração antes de decidir qual política alterar.

Examine Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf da GPO relevante e sua entrada em [Registry Values], quando presente. Preserve apenas o trecho específico da configuração e a identidade da política necessários para esta revisão. Essa verificação é motivada pelo ponto cego documentado do coletor no canal padrão, detalhado abaixo. Uma declaração no SYSVOL ainda precisa ser conciliada com o piloto; não substitua evidências da política aplicada pela declaração de uma GPO sem relação com o caso.

Etapa 2: ler o valor local sem ocultar seu tipo

Use a referência de reg query com o caminho de Winlogon e o nome de valor documentados:

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

Esta é uma adaptação de sintaxe somente de leitura, não um comando copiado de um exemplo completo da Microsoft. Examine o nome do valor, o tipo e os dados retornados. Para a configuração documentada, espere o rótulo de tipo REG_SZ e o texto numérico configurado. Não filtre a consulta para DWORD: isso ocultaria justamente a divergência de tipo em investigação.

Armazene a saída real junto com o relatório de política. Se o valor estiver ausente, o tipo for diferente, o acesso falhar ou a saída tiver sido coletada de outro host, identifique explicitamente essa observação. Nenhum desses resultados autoriza fabricar um valor local de dez a partir de uma mensagem de auditoria.

Crie uma linha de conciliação para o piloto contendo a origem de política relatada, as evidências de GptTmpl.inf, o tipo e os dados locais, o horário da coleta e o contexto de reinicialização. Atribua um responsável e uma próxima ação às divergências. Por exemplo, um REG_SZ zero documentado junto com uma constatação persistente aponta para a limitação do coletor; não é motivo para reescrever o valor da estação de trabalho como DWORD para fazer a auditoria desaparecer.

Detecção: preservar LsaSrv 45058 e testar o logon offline

O artigo de solução de problemas de LsaSrv 45058 da Microsoft descreve um evento informativo no log System que registra a remoção da entrada de usuário mais antiga em cache quando a cota é atingida. O evento identifica o usuário removido e o carimbo de data e hora da entrada. Ele fornece contexto útil para uma falha de logon offline; não comprova roubo de credenciais.

Se o evento existir no período relevante, retenha seu horário, computador, origem, ID do evento, identidade de teste removida e carimbo de data e hora da entrada. Correlacione-o com a linha do tempo de logon do piloto. Se a coleta ou a retenção estiver incompleta, registre essa lacuna. Trate a ausência de um evento observado como uma limitação das evidências, não como um inventário completo de identidades em cache.

Etapa 3: usar uma identidade sem privilégios e registrar as condições

Escolha uma identidade de teste de domínio dedicada e sem privilégios cujo responsável autorize o exercício. Registre como a ausência de acesso privilegiado foi verificada pelo processo de revisão de contas da organização. Não use um administrador privilegiado apenas porque o título do detector menciona contas privilegiadas.

Planeje um teste de logon no console local com uma rota de recuperação aprovada. Registre a situação inicial online, a condição controlada da rede, como a acessibilidade aos controladores de domínio foi excluída, o método de logon e o resultado exato observado. Restaure a conectividade após o exercício. Se a condição de rede do teste não puder ser estabelecida, relate o resultado como inconclusivo.

A declaração do resultado deve ser restrita: a identidade de teste indicada conseguiu ou não acessar a área de trabalho no piloto indicado nas condições declaradas. A Microsoft observa separadamente que o acesso offline à área de trabalho não dá acesso a recursos que exigem validação pelo domínio. Não relate o sucesso na área de trabalho como acesso bem-sucedido aos serviços do domínio.

Se uma remoção precisar ser investigada, use um evento 45058 observado para a identidade de teste ou um exercício de laboratório aprovado separadamente. Não alterne contas de produção apenas para forçar um evento. Registre “remoção não observada” quando essa for a evidência disponível. Este protocolo não exige dump do cache, exportação de verificadores, extração de hives do registro nem recuperação de senhas.

Etapa 4: registrar a decisão antes de alterar a configuração

Um registro de revisão útil pode usar este modelo:

Faça três perguntas explícitas no gate de revisão: Qual piloto e qual restrição offline justificam uma exceção? Quais evidências de GptTmpl.inf/REG_SZ e qual GPO resultante devem ser retidas quando a constatação diverge do estado local? Qual identidade sem privilégios pode demonstrar o comportamento relevante sem manipular segredos? Identifique o responsável pela decisão em vez de deixar essas perguntas implícitas.

Remediação: aplicar a decisão e repetir a verificação do piloto (Remediation)

Se a decisão aprovada for alterar o cache, use a Security Option identificada no artigo de 45058 da Microsoft: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, depois Interactive logon: Number of previous logons to cache (in case domain controller is not available). Limite a mudança aos dispositivos pretendidos.

Para uma decisão de desativar o cache, a Microsoft documenta zero como o valor que o desativa. Uma exceção que mantenha o cache precisa de sua própria justificativa de fluxo de trabalho, responsável e data de revisão. Não transforme o máximo global do detector, sua mensagem sobre o padrão de dez ou uma remoção informativa em uma cota universalmente aceitável.

A referência da Security Option da Microsoft informa que alterações de política entram em vigor sem reinicialização quando salvas localmente ou distribuídas por Group Policy. Seu artigo de solução de problemas do registro exige separadamente uma reinicialização para alterações diretas na chave de registro. Registre qual rota de configuração foi usada e siga a orientação de reinicialização documentada para essa rota. Após a mudança entrar em vigor, repita o mesmo relatório de política, a leitura local de tipo e valor e o teste controlado do piloto. Compare elementos equivalentes: as mesmas camadas de evidência e o mesmo critério de aceitação. Retenha diferenças não resolvidas em vez de encerrar o registro apenas porque a auditoria deixou de emitir a constatação.

Para um usuário afetado pela remoção, a recuperação documentada pela Microsoft consiste em restaurar a conectividade com o controlador de domínio e a resolução de nomes e concluir um logon autenticado no domínio; a recolocação em cache depende de o cache estar ativado. Mantenha a recuperação separada de uma decisão de política de ampliar a cota. Uma sessão de usuário restaurada não justifica, por si só, uma mudança de configuração em toda a frota.

Como o EtcSec detecta isso

A verificação BP039_PRIV_ACCOUNTS_CACHED do etc-collector do EtcSec, lida no commit bcd03c54, examina configurações de registro de GPOs coletadas. Qualquer CachedLogonsCount zero observado em qualquer GPO suprime a constatação. Caso contrário, ela retorna uma constatação de gravidade Medium com Count=1, inclusive quando nenhum valor de GPO foi coletado. Seu valor worstSeen é o máximo entre as GPOs coletadas, não a política resultante de cada estação de trabalho.

O provedor preenche esse campo a partir de Registry.pol usando getDWORDValue, que aceita REG_DWORD. A Microsoft documenta a configuração real como REG_SZ. O parser de GptTmpl.inf não preenche CachedLogonsCount a partir de [Registry Values]. O próprio código do detector explica que o canal padrão da Security Option pode, portanto, ficar invisível e produzir um falso positivo.

Duas consequências devem constar no registro de revisão. Um zero pelo canal padrão pode coexistir com uma constatação; inversamente, um zero observado em outra GPO pode suprimir a constatação sem comprovar a cobertura do piloto. A referência ao padrão do Windows de dez na mensagem de ausência de valor é uma inferência dessa mensagem, não uma configuração local medida.

Essa verificação não observa uma conta específica em cache, seus privilégios efetivos, comprometimento, eventos LsaSrv, comportamento de logon offline nem o estado de execução de Credential Guard. Trate-a como um pedido de verificação da configuração pelo canal adequado. Encerre a revisão do piloto com as evidências de política, a observação local de REG_SZ, o resultado comportamental e a decisão autorizada; mantenha visível qualquer cobertura da frota que não tenha sido medida.