O que realmente acontece quando você faz login no domínio

Do Enter pressionado até o desktop carregado — cada componente, cada etapa, cada decisão que o Windows toma nos bastidores.

Você pressiona Enter. O desktop aparece. Parece simples.

Por baixo disso, o Windows acabou de executar uma sequência de operações envolvendo pelo menos quatro componentes distintos, dois protocolos de rede, uma troca de chaves criptográficas e uma consulta ao DNS — tudo em menos de dois segundos.

A maioria dos profissionais que opera o AD há anos nunca precisou entender esse processo em detalhes. O problema é que quando algo quebra, é exatamente esse conhecimento que determina se você resolve em dez minutos ou passa horas no lugar errado.

Etapa 1 — O LSA entra em cena

Antes de qualquer comunicação com o Domain Controller, o processo começa localmente. Quando você digita as credenciais, o componente responsável por recebê-las é o LSA — Local Security Authority. É ele que decide o que fazer com elas.

A primeira decisão do LSA é verificar se existe um logon em cache. Em máquinas que já fizeram logon no domínio anteriormente, o Windows armazena um hash das credenciais localmente — exatamente para permitir autenticação offline quando o DC não está acessível. Se o cache existe e as credenciais batem, o logon acontece localmente, sem nenhuma comunicação com o DC.

Se não há cache — ou se o cache está desabilitado pela política — o LSA precisa ir ao Domain Controller. É aqui que o Netlogon assume.

Etapa 2 — O Netlogon localiza o Domain Controller

O Netlogon é o serviço responsável por localizar um Domain Controller disponível para autenticar o usuário. Ele faz isso via DNS — consultando registros SRV específicos que o AD registra automaticamente na zona do domínio.

Esses registros seguem um formato padrão: _ldap._tcp.dc._msdcs.seudominio.com. Eles listam quais servidores estão disponíveis como Domain Controllers, em qual porta, e com qual prioridade.

Se o DNS não resolve esses registros corretamente — por falha de configuração, replicação pendente ou zona corrompida — o Netlogon não encontra o DC. E sem DC, não há autenticação Kerberos. O Windows tenta um fallback para NTLM via broadcast, e se isso também falhar, o logon simplesmente não acontece.

Esse é o motivo pelo qual problemas de DNS são responsáveis pela maioria das falhas de autenticação em ambientes enterprise. O sintoma aparece no logon. A causa está no DNS.

Etapa 3 — O KDC e o protocolo Kerberos

Com o Domain Controller localizado, o LSA inicia o processo de autenticação Kerberos. O componente responsável no DC é o KDC — Key Distribution Center — que roda como parte do serviço do AD em todo Domain Controller.

O fluxo Kerberos segue uma sequência de mensagens bem definida:

O cliente envia uma mensagem AS-REQ ao KDC — Authentication Service Request — com o nome do usuário e um timestamp criptografado com o hash da senha. O KDC verifica se consegue descriptografar o timestamp usando o hash que tem armazenado no NTDS.dit. Se conseguir, a identidade está confirmada.

Em resposta, o KDC emite o TGT — Ticket Granting Ticket — uma credencial criptografada com a chave do próprio KDC que o cliente não consegue ler, mas pode apresentar para solicitar acesso a recursos. Esse ticket tem validade de 10 horas por padrão e é o que permite o SSO em ambientes on-premises: o usuário autentica uma vez e usa o TGT para acessar qualquer recurso do domínio sem redigitar a senha.

O Kerberos nunca transmite a senha pela rede. O que viaja é uma prova criptográfica de que o usuário a conhece. Essa distinção é fundamental para entender por que o protocolo é mais seguro que o NTLM — e por que o NTLM ainda é um risco em ambientes modernos.

Etapa 4 — Autorização e Group Policy

Autenticação confirmada, o processo passa para a autorização. O DC verifica a qual grupos o usuário pertence, quais permissões esses grupos carregam e se há restrições de logon — horário, estação de trabalho, conta desabilitada ou expirada.

Em paralelo, o serviço de Group Policy é acionado. O cliente consulta o DC para identificar quais GPOs se aplicam àquele usuário e àquela máquina, baixa as que mudaram desde o último logon e as aplica. É nessa etapa que scripts de logon rodam, mapeamentos de drive são feitos e configurações de segurança são aplicadas.

Se uma GPO demorar para processar — por latência de rede, DC sobrecarregado ou política mal configurada — o desktop vai demorar para aparecer. O usuário vai reclamar que o logon está lento. E sem entender que o gargalo está no processamento de GPO, é difícil saber onde olhar.

O que os logs revelam

Todo esse processo deixa rastros no Event Viewer. Três Event IDs cobrem as etapas principais do fluxo Kerberos:

O 4768 registra a solicitação do TGT — o AS-REQ. Se esse evento não aparece, o cliente nunca chegou ao KDC. Problema antes do Kerberos: provavelmente DNS ou conectividade.

O 4769 registra a solicitação de um Service Ticket — quando o cliente usa o TGT para acessar um recurso específico. Falhas aqui geralmente indicam problema de SPN — o Service Principal Name que identifica o serviço no Kerberos.

O 4624 registra o logon bem-sucedido na máquina. O campo Logon Type indica se foi interativo, remoto ou de serviço. O campo Authentication Package indica se usou Kerberos ou NTLM — e quando aparece NTLM onde deveria aparecer Kerberos, é um sinal de que algo no fluxo anterior falhou silenciosamente.

Por que isso importa além do troubleshooting

Entender o processo de logon não é só útil para resolver problemas. É o alicerce de tudo que vem depois em IAM.

Identidade híbrida — conectar o AD ao Entra ID — só faz sentido quando você entende como a autenticação funciona on-premises. SSO com SAML e OpenID Connect são extensões do mesmo princípio que o Kerberos aplica: provar identidade uma vez e usar essa prova para acessar múltiplos recursos.

Quem domina o logon do AD tem o modelo mental certo para entender qualquer protocolo de autenticação moderno. Quem pula essa fundação vai encontrar dificuldade para justificar decisões de arquitetura — e é exatamente aí que as entrevistas técnicas internacionais separam os candidatos.

No próximo artigo, aprofundo o Kerberos vs NTLM — os dois protocolos que dividem a autenticação em ambientes Windows, quando cada um é usado e por que o fallback silencioso para NTLM é um problema que a maioria não percebe.

Se você quer ver esse processo acontecendo em tempo real — o TGT sendo emitido, os Event IDs sendo gerados, o Kerberos sendo observado no lab — o Módulo 1 do Identity Engineer Foundation cobre exatamente isso.

Scripts PowerShell prontos, checklist de verificação e lab estruturado do zero. → Ver o curso

Toda semana publico conteúdo técnico sobre Active Directory, Entra ID e identidade híbrida. → Assinar a newsletter