Revisao de logonCount por DC no AD: qualificar totais antes de retirar a conta

O que estabelece uma revisão de logonCount por DC no AD

Uma revisao de logonCount por DC no AD procura saber de onde veio um contador do diretório antes de o usar para desativar definitivamente uma conta administrativa. Um valor baixo num controlador de domínio pode iniciar uma revisão. Não estabelece a atividade da conta em todo o domínio, as suas permissões atuais nem se o responsável pela conta ainda precisa dela.

O resultado útil é um registo de revisão: a identidade da conta, todos os DCs no âmbito, cada valor devolvido, leituras por resolver, o acesso atual e a decisão do responsável. Mantenha estas observações juntas para que um administrador possa explicar por que motivo uma conta foi mantida, investigada mais a fundo ou encaminhada para um processo de desativação definitiva aprovado.

Este guia propõe um fluxo de recolha apenas de leitura e de decisão. Os exemplos de PowerShell adaptam parâmetros documentados no Microsoft Learn a identidades e servidores ilustrativos; não foram executados num domínio de um cliente. Substitua os valores de exemplo por valores verificados e use o módulo ActiveDirectory com uma identidade autorizada a ler o diretório.

Como funciona o contador

A referência do atributo Logon-Count da Microsoft descreve um contador de inícios de sessão bem-sucedidos mantido de forma independente em cada DC, sem replicação. Recomenda consultar todos os DCs e somar os seus valores. Zero significa desconhecido. DCs retirados de serviço podem deixar lacunas no histórico, e o limite documentado de 65535 torna um contador saturado inadequado para acompanhar a atividade nesse DC.

Trate o atributo como uma contagem cumulativa com limites de cobertura e de histórico, e não como um carimbo temporal. Uma contagem de 1–4 não contém nenhuma data a partir da qual se possa calcular inatividade recente. Mesmo um conjunto completo de leituras atuais não consegue reconstruir as contribuições de controladores retirados de serviço. Registe estas limitações ao lado de qualquer subtotal em vez de o descrever como todo o histórico de utilização da conta.

Não substitua logonCount por badPwdCount quando não estiver disponível. O fluxo relacionado de triagem de badPwdCount qualifica os contadores de falhas antes de concluir que houve um ataque. A sua disciplina de preservar o servidor, a hora e a qualidade da recolha aplica-se aqui, mas um contador de falhas não responde à questão dos inícios de sessão bem-sucedidos.

Deteção: construir uma matriz de evidências por conta e DC

Passo 1 — Fixar a identidade e o âmbito

Parta do resultado original e preserve o identificador da conta, o endpoint do coletor, a hora da recolha, a revisão do coletor e os erros. Confirme o domínio da conta e o inventário de DCs com a equipa responsável pelas operações do diretório. Os dois nomes de host abaixo ilustram leituras separadas; não são uma lista completa de DCs de um domínio real.

Escolha um identificador estável da conta e verifique-o face ao resultado antes de repetir a leitura. Mantenha o DN ou GUID junto do nome apresentado no registo de revisão. Se a conta não puder ser resolvida num servidor, preserve o erro de pesquisa e investigue a identidade, o âmbito ou a disponibilidade do diretório. Não crie uma entrada numérica para um objeto que não foi devolvido.

A Microsoft documenta a seleção da identidade, a seleção explícita do servidor e os atributos adicionais em Get-ADUser. Estas adaptações pedem logonCount explicitamente a um DC identificado, em vez de dependerem da seleção predefinida do servidor:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc02.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Execute a mesma leitura documentada em cada DC verificado no âmbito, separadamente. Guarde o objeto devolvido e qualquer erro juntamente com o endpoint escolhido e a hora da leitura. Uma ligação bem-sucedida, por si só, não estabelece que o atributo pedido foi devolvido. Inspecione a propriedade em vez de permitir que uma conversão numérica posterior transforme um valor vazio em zero.

Passo 2 — Preservar as observações em bruto

Use uma linha por conta e DC. A matriz abaixo é uma estrutura de evidências recomendada, não uma saída de exemplo de um ambiente de cliente nem campos fornecidos automaticamente pelo detetor.

Para um zero devolvido, mantenha o zero literal e marque o valor de atividade como desconhecido. Para um atributo ausente, mantenha a ausência. Para um valor inválido, preserve a sua representação original e classifique a interpretação como não resolvida. Para uma leitura falhada, preserve o erro e deixe a contagem sem valor. Estes estados podem exigir acompanhamentos diferentes, embora nenhum forneça uma contagem de atividade conhecida.

Se um servidor estiver indisponível, mantenha a sua linha no âmbito declarado. Atribua a repetição ou a investigação a um responsável. Uma repetição bem-sucedida torna-se uma nova observação com a sua própria hora; não deve apagar a falha da recolha original. Da mesma forma, preserve as diferentes observações se a recolha for repetida, em vez de escolher o valor que faz a revisão parecer completa.

Passo 3 — Resumir sem apagar a incerteza

Some os valores positivos conhecidos e preserve a matriz completa. Apresente o resultado como um subtotal conhecido sempre que algum DC tenha um valor desconhecido ou não tenha sido lido com sucesso. Juntamente com o subtotal, liste quais os DCs que contribuíram, quais não contribuíram, o intervalo da recolha e qualquer contador saturado ou contribuição histórica em falta.

Não retire silenciosamente os servidores indisponíveis do âmbito nem preencha as suas células com zero. Uma folha de cálculo com um valor numérico em cada linha pode continuar a conter evidências por resolver. O resumo deve tornar isso visível à pessoa que decide se é necessária mais recolha.

Use a mesma regra ao comparar revisões. Mantenha consistentes a identidade da conta e a cobertura de DCs, descreva alterações no inventário e preserve a matriz anterior. Uma alteração no subtotal pode refletir uma mudança na cobertura; não fornece automaticamente um intervalo de atividade recente. Se a decisão exigir uma cronologia, obtenha evidências de atividade qualificadas separadamente para um período indicado e documente a sua cobertura.

Rever o acesso e a responsabilidade pela conta antes da desativação definitiva (Remediation)

Passo 4 — Esclarecer o marcador administrativo

O detetor usa adminCount=1 para selecionar candidatos. Antes de chamar à conta uma conta de administrador, estabeleça o seu acesso atual. O fluxo de limpeza de adminCount obsoleto explica por que o marcador pode persistir após a participação em grupos privilegiados. Siga a sua revisão de participação em grupos e permissões em vez de assumir que o indicador é um inventário dos direitos atuais.

Para a decisão de desativação definitiva, peça uma revisão dos grupos diretos e aninhados, do grupo primário, das permissões delegadas relevantes e dos recursos que a conta pode administrar. Mantenha o revisor, o âmbito e os caminhos por resolver no processo. Uma lista de grupos diretos aparentemente normal não encerra a questão mais ampla do acesso.

Isto pode produzir resultados distintos: uma conta com acesso atual justificado; uma conta anteriormente privilegiada com estado residual; permissões injustificadas que exigem uma alteração específica; ou acesso que continua por verificar. Registe as evidências reais para a classificação. Não limpe adminCount apenas para remover este resultado, nem trate a limpeza do indicador como desativação definitiva da conta.

Passo 5 — Obter a decisão do responsável pela conta

Identifique o responsável pela conta e pergunte quais os fluxos de trabalho que dependem dela. Reveja a finalidade declarada face às evidências operacionais e dependências disponíveis. Inclua utilizações agendadas, pouco frequentes, de recuperação e de emergência quando forem aplicáveis à conta; a sua relevância deve resultar do responsável e do ambiente, não de uma explicação presumida para um contador baixo.

O processo proposto separa a revisão do contador da autorização para alterar o acesso. Se a desativação definitiva for aprovada, use o procedimento de ciclo de vida das contas da organização para a identidade verificada. Escolha o método de alteração e de recuperação a partir desse plano aprovado. Este guia não prescreve uma desativação ou eliminação em massa com base no limiar do detetor.

Passo 6 — Validar o resultado registado

Após uma alteração aprovada, volte a ler a mesma conta nos servidores documentados e preserve os novos resultados separadamente. Os parâmetros de identidade, servidor e propriedades de Get-ADUser documentados acima também permitem esta leitura repetível:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Repita a revisão de acesso relevante para a alteração e peça ao responsável que confirme os fluxos de trabalho afetados. Registe o estado real da conta, as permissões, as dependências restantes, os erros e o acompanhamento. O desaparecimento do resultado, por si só, não estabelece que as permissões ou dependências de negócio foram tratadas corretamente.

Como a EtcSec deteta esta situação

A verificação de etc-collector revista é ADMIN_LOGON_COUNT_LOW, em Accounts, com severidade Info. Na revisão do coletor afca1b9f7bba6f076d6a6493371486071001452b, admin-logon-count-low.go:36 seleciona utilizadores com a conta ativada e AdminCount=true, exclui LogonCount=0 e mantém uma contagem diferente de zero inferior a 5. Não aplica nenhum período de inatividade. O limiar é um predicado do produto, não uma regra para desativar definitivamente contas.

Count é o número de utilizadores correspondentes, não uma soma de inícios de sessão. O detetor devolve o resultado mesmo quando essa contagem é zero; os detalhes dos utilizadores afetados são anexados quando pedidos e quando existem correspondências. Uma correspondência é uma pista de investigação a partir da visão recolhida.

O fornecedor LDAP limita essa visão. client.go:460 obtém utilizadores através da ligação selecionada sem agregar os contadores dos DCs. parser.go:41 pede logonCount; o parser de utilizadores lê-o através de getIntAttr, cujo tratamento de valores ausentes e de inteiros inválidos pode produzir zero. Por isso, o detetor não consegue distinguir todos os estados de recolha que a matriz independente preserva. Excluir zero impede que uma contagem desconhecida se torne um resultado positivo, mas não verifica a utilização em todo o domínio.

A verificação não calcula nenhum total do domínio nem estabelece direitos efetivos, responsabilidade pela conta, dependências ou uma cronologia de atividade recente. adminCount é o seu marcador de seleção, não prova de privilégios atuais. Use ADMIN_LOGON_COUNT_LOW para iniciar a revisão e depois qualifique cada observação de DC e o acesso da conta antes de decidir o seu futuro.