← Voltar ao início

Produto

Bloqueios de conta: por que uma conta do Active Directory fica bloqueando

O módulo de Bloqueios de conta responde, a partir do painel e sem uma sessão RDP no Domain Controller, por que uma conta do Active Directory fica bloqueando: qual dispositivo disparou o último bloqueio, de onde vêm as tentativas de autenticação com falha e o que ainda está tentando com a senha antiga. O levantamento roda pelo agente já instalado no Domain Controller e termina em um diagnóstico com apontamentos codificados e um relatório em PDF com a sua marca.

O módulo abre a partir do cadastro do Domain Controller, e a busca de usuário aceita nome e sobrenome, nome da conta, UPN ou endereço de e-mail. Quando o termo corresponde a várias contas, a tela lista as correspondências com o status de cada uma e o técnico escolhe qual levantar: uma conta que o técnico não escolheu nunca é levantada.

O dispositivo por trás do bloqueio: evento 4740 no PDC Emulator

O Windows grava o evento 4740, que é o que registra o bloqueio de uma conta, em um único lugar do domínio: o PDC Emulator. O KairosLink lê ali e mostra o dispositivo de origem e o horário exato do último bloqueio. Se o levantamento rodou contra um Domain Controller que não é o PDC Emulator, o diagnóstico avisa, informa qual é o PDC do domínio e oferece rodar a consulta de novo contra ele.

Se a auditoria de bloqueios estiver desligada no Domain Controller, o evento 4740 nunca é gravado e não dá para determinar a origem do bloqueio. O KairosLink detecta essa situação e permite ligar a auditoria pelo painel, com um motivo escrito obrigatório e um registro no log de auditoria de segurança. É a única ação do módulo que altera o Domain Controller. Se uma GPO do domínio gerencia essa política, o diagnóstico avisa que a GPO vai sobrescrever a mudança local.

De onde vêm os logins com falha: eventos 4771 e 4625

O levantamento cobre uma janela de 72 horas e agrupa as tentativas de autenticação com falha (evento 4771 para Kerberos e 4625 para NTLM) por dispositivo de origem, com a contagem de tentativas e o horário da última. É ali que o padrão real aparece: um único dispositivo com dezenas de falhas, ou várias origens diferentes falhando ao mesmo tempo.

Quando as falhas vêm de um Domain Controller, o diagnóstico sinaliza isso à parte. Significa que um serviço intermediário está autenticando em nome do usuário, e o dispositivo em que a pessoa realmente trabalha não tem culpa.

Três ou mais tentativas com falha da mesma origem dentro do mesmo segundo são reportadas como rajada automatizada. Ninguém erra a senha três vezes em um segundo: esse padrão é um aparelho ou um serviço tentando em loop com a senha antiga.

O mesmo levantamento traz a política de senhas do domínio e a política de senhas refinada (FGPP) aplicada a essa conta, que é o que define o limite de bloqueio e a janela de observação a que o usuário está de fato sujeito.

O que continua tentando com a senha antiga

Saber qual dispositivo disparou o bloqueio não basta: é preciso achar o que está rodando dentro dele com a senha antiga. Com um clique, o KairosLink analisa o dispositivo de origem e reporta sessões abertas ou desconectadas, tarefas agendadas, serviços, credenciais salvas, unidades de rede mapeadas e perfis em disco ligados a essa conta.

A busca é feita por SID além de por nome de conta. Quando um perfil de usuário é excluído de um dispositivo, as tarefas agendadas não são excluídas: elas continuam referenciando o SID, porque já não existe um nome para resolver. Por nome elas não aparecem; por SID, sim. Esse caso, um perfil excluído com tarefas vivas, é sinalizado como um apontamento próprio.

Quando as falhas vêm de um Domain Controller, a análise equivalente roda nesse DC, para identificar qual serviço está intermediando a autenticação. As duas análises são somente leitura: elas levantam e descrevem, não excluem tarefas, não param serviços e não mexem em credenciais.

Na própria conta, o técnico pode desbloqueá-la, habilitá-la e forçar a troca de senha no próximo login. Cada uma dessas ações cai no histórico de ações do Active Directory, junto com o técnico que a executou.

Onde o usuário está conectado: todo dispositivo é consultado

O Windows não mantém nenhum registro central de onde um usuário de domínio está conectado. A única fonte confiável é perguntar aos próprios dispositivos, e é exatamente isso que o painel faz: ele pergunta a cada dispositivo online do cliente, usando o quser, se aquela conta tem uma sessão aberta, e mostra o que cada um respondeu.

O resultado nunca mistura três coisas diferentes: os dispositivos com sessão, os dispositivos que responderam que a conta não tem sessão e os dispositivos que não puderam ser consultados, cada um com um motivo escrito (estava offline, não tem agente, não respondeu a tempo). Um dispositivo que não respondeu não é um dispositivo sem sessão, e a tela nunca o conta como tal.

Para cada sessão encontrada, ele informa se está ativa ou desconectada. A distinção importa em uma investigação de bloqueio: uma sessão desconectada deixada aberta semanas atrás com a senha antiga continua tentando sozinha, e ninguém está olhando.

A consulta é somente leitura: ela diz onde existe uma sessão e não fecha nenhuma. Não há logoff remoto neste módulo.

Histórico de logins: o que cada Domain Controller realmente viu

O atributo lastLogon do Active Directory não replica entre Domain Controllers: cada um guarda o valor que ele mesmo autenticou. Perguntar a um único DC dá uma resposta parcial, e essa é a armadilha clássica desse atributo. O KairosLink pergunta a todos os Domain Controllers do domínio e mostra cada resposta, com o nome do DC ao lado e os que não responderam em uma lista própria.

Junto disso ele mostra o lastLogonTimestamp, que replica, com o aviso de que ele carrega um atraso de até 14 dias por definição do Active Directory. Ele diz se uma conta está em uso; não diz se ela foi usada hoje de manhã.

Ele também soma os logins que o Domain Controller viu (evento 4624 na mesma janela), agrupados por dispositivo de origem, com o tipo de logon, a contagem e o mais recente. O número vem com o seu limite escrito ao lado: um Domain Controller só vê os logins que passaram por ele, então o que a pessoa fez contra a própria estação de trabalho não está ali.

Essa diferença faz parte do diagnóstico, não é uma limitação escondida. Perguntar a um dispositivo se a conta tem uma sessão aberta é fato concreto. O que o Active Directory reporta sobre logins é uma inferência a partir do que um Domain Controller conseguiu ver. Os dois são mostrados separadamente, e cada tela declara de onde veio o seu número.

Funções FSMO: qual dispositivo é de fato o PDC Emulator

O diagnóstico mostra as cinco funções FSMO do domínio e qual Domain Controller detém cada uma. Isso importa por um motivo concreto: o evento 4740 só é gravado no PDC Emulator, então levantar o Domain Controller errado deixa a origem do bloqueio invisível.

O detentor da função PDC Emulator é conferido contra duas fontes diferentes dentro do próprio domínio. Se as duas discordarem, o diagnóstico reporta isso como um apontamento em vez de escolher uma por conta própria. Quando um domínio se contradiz sobre qual dispositivo é o PDC dele, isso é informação para o técnico, não ruído para disfarçar.

Critérios determinísticos, sem IA na análise

A avaliação vive no código do painel, não em um modelo de linguagem: os mesmos dados sempre produzem os mesmos apontamentos, cada um com o seu código, a sua causa e a ação recomendada. Nenhuma IA participa da análise de um bloqueio.

O diagnóstico sempre separa "não há problema" de "não consigo ver". Quando falta um dado, a tela diz o que falta e por quê, em vez de mostrar um vazio que parece um resultado: não encontrar um evento 4740 com a auditoria desligada não significa que a conta nunca bloqueou.

O diagnóstico completo sai como relatório em PDF com o logo e o cabeçalho da sua empresa, pronto para entregar ao cliente.

Bloqueios de conta está disponível nos planos KairosBusiness, KairosEnterprise e KairosEnterpriseFlex.

Perguntas frequentes

Por que uma conta do Active Directory bloqueia se o usuário não fez nada?
Porque alguma coisa que não é a pessoa continua autenticando com a senha anterior. Os suspeitos de sempre são uma tarefa agendada ou um serviço configurado com essa conta, uma unidade de rede mapeada, uma credencial salva no Gerenciador de Credenciais do Windows ou um aparelho que ainda guarda a senha antiga. Cada nova tentativa soma uma falha e, ao atingir o limite da política do domínio, a conta se bloqueia sozinha mesmo com o usuário longe do dispositivo dele.
O que é o evento 4740 e por que ele só existe no PDC Emulator?
O evento 4740 é o evento de segurança do Windows que registra o bloqueio de uma conta e informa o dispositivo de onde ele veio. Todos os Domain Controllers encaminham as tentativas de senha incorreta ao PDC Emulator, que é quem mantém a contagem e decide o bloqueio, então o 4740 é gravado apenas no log dele. Levantar qualquer outro Domain Controller deixa a origem do bloqueio invisível: o KairosLink detecta isso, avisa e permite rodar a consulta de novo contra o PDC.
O que acontece se a auditoria de bloqueios estiver desligada no Domain Controller?
Sem essa auditoria, o evento 4740 não é gravado e não dá para determinar a origem do bloqueio. O KairosLink reporta isso como um apontamento em vez de mostrar uma tela vazia que parece um resultado. A partir do mesmo diagnóstico você liga a auditoria no Domain Controller, com um motivo escrito e um registro no log de auditoria de segurança e, daí em diante, o próximo bloqueio fica registrado. Se uma GPO do domínio gerencia essa política, o diagnóstico avisa: a GPO vai sobrescrever a mudança local.
Por que às vezes o evento não informa o dispositivo de origem?
Isso acontece quando o bloqueio se origina por Kerberos: o 4740 é registrado com o horário do bloqueio, mas sem nome de dispositivo. Nesse caso o diagnóstico diz isso com todas as letras e a investigação continua pelas origens das tentativas com falha, os eventos 4771 e 4625, que vêm agrupados por dispositivo com a contagem de tentativas e o horário da última.
Quais restos de um perfil excluído podem continuar bloqueando uma conta?
Tarefas agendadas e serviços sobrevivem ao perfil: eles continuam referenciando o SID da conta, não o nome dela. Por isso a análise do dispositivo de origem busca por SID além de por nome de conta, e encontra tarefas de um usuário cujo perfil já não está em disco. A mesma passagem reporta credenciais salvas e unidades de rede mapeadas, que tentam sozinhas com a senha antiga toda vez que o dispositivo as usa.
Como distinguir uma tentativa humana de uma tentativa automatizada?
Pelo quanto elas se concentram no tempo. Uma pessoa errando a senha produz tentativas separadas por segundos ou minutos. Três ou mais falhas da mesma origem dentro do mesmo segundo são típicas de um aparelho ou de um serviço tentando em loop, e o KairosLink reporta isso como rajada automatizada, com as tentativas por segundo e o dispositivo de onde elas vêm.
Como descobrir em quais dispositivos um usuário está conectado?
Perguntando aos dispositivos, que é a única fonte confiável: o Windows não mantém registro central das sessões de um usuário de domínio. O painel consulta todos os dispositivos online do cliente com o quser e monta o resultado a partir do que cada um respondeu, sempre separando os dispositivos com sessão, os que responderam que não há sessão e os que não puderam ser alcançados, cada um com o seu motivo. Para cada sessão encontrada ele informa se está ativa ou desconectada. A consulta é somente leitura: não fecha sessões e não executa logoff remoto.
Por que o último login informado pelo Active Directory nem sempre bate?
Porque o atributo lastLogon não replica entre Domain Controllers: cada um guarda o valor que ele mesmo autenticou, então perguntar a um único DC dá uma resposta parcial. O KairosLink pergunta a todos os Domain Controllers do domínio e mostra cada resposta separadamente. O lastLogonTimestamp replica, mas carrega um atraso de até 14 dias por definição, e a tela diz isso bem ao lado do valor. Tudo isso é uma inferência sobre o que cada Domain Controller conseguiu ver, e é apresentado à parte das sessões consultadas nos dispositivos, que são fato concreto.
Para que servem as funções FSMO em uma investigação de bloqueio?
Elas dizem a qual Domain Controller perguntar. O evento 4740 só é gravado no PDC Emulator, então um levantamento feito contra qualquer outro Domain Controller não consegue identificar o dispositivo de origem. O diagnóstico mostra as cinco funções do domínio com o seu detentor e confere o PDC Emulator contra duas fontes diferentes: se elas discordarem, ele reporta isso como um apontamento em vez de escolher uma por conta própria.
Teste o KairosLink grátis por 14 dias

Módulos de software padrão incluídos. Sem cartão de crédito.