Kerberos vs NTLM — a diferença que todo profissional de AD deveria saber explicar

Aqui está o texto completo para colar no Ghost:

Kerberos vs NTLM — a diferença que todo profissional de AD deveria saber explicar

Os dois protocolos dividem a autenticação em ambientes Windows. Entender quando cada um é usado — e por que o fallback entre eles é silencioso — é o que separa quem opera o AD de quem entende o AD.

Em todo ambiente Active Directory, dois protocolos de autenticação coexistem: Kerberos e NTLM. Na maioria das vezes, você não escolhe qual usar — o Windows decide por você, de forma automática e silenciosa.

Esse comportamento automático é conveniente quando tudo funciona. É um problema quando algo falha — porque o protocolo que assumiu o controle pode não ser o que você esperava, e os sintomas raramente indicam o protocolo como causa raiz.

Entender a diferença entre os dois não é detalhe acadêmico. É o pré-requisito para diagnosticar falhas de autenticação com precisão — e para justificar decisões de segurança em ambientes enterprise.

Kerberos — o protocolo padrão

O Kerberos é o protocolo de autenticação padrão em domínios Windows desde o Windows 2000. Foi projetado com um princípio fundamental: a senha nunca deve trafegar pela rede — nem em texto claro, nem em hash.

O que o Kerberos usa no lugar da senha é uma prova criptográfica — um ticket emitido por uma autoridade central chamada KDC, o Key Distribution Center, que roda em todo Domain Controller. Esse ticket prova que o usuário se autenticou com sucesso, sem revelar as credenciais originais.

O resultado prático é o SSO — Single Sign-On. O usuário autentica uma vez ao fazer logon e recebe um TGT, Ticket Granting Ticket, válido por 10 horas. Durante esse período, pode acessar qualquer recurso do domínio — servidores de arquivo, aplicações, serviços — sem redigitar a senha. O TGT é apresentado ao KDC, que emite um Service Ticket específico para cada recurso acessado.

Para que o Kerberos funcione, dois pré-requisitos precisam estar satisfeitos: o DNS precisa estar funcionando corretamente — para que o cliente localize o DC — e o serviço alvo precisa ter um SPN registrado, um Service Principal Name que identifica o serviço no contexto do Kerberos.

Quando qualquer um desses pré-requisitos falha, o Kerberos não é tentado. E é aí que o NTLM entra.

NTLM — o protocolo legado que ainda está em todo lugar

O NTLM — NT LAN Manager — é o predecessor do Kerberos. Foi o protocolo padrão de autenticação Windows antes da chegada do Active Directory e do Kerberos no Windows 2000.

Ao contrário do Kerberos, o NTLM não depende de um serviço centralizado como o KDC. Ele funciona com um mecanismo de desafio-resposta diretamente entre o cliente e o servidor — o servidor gera um desafio, o cliente responde com um hash calculado a partir da senha, e o servidor verifica a resposta.

Essa independência do KDC é ao mesmo tempo a vantagem e o problema do NTLM. A vantagem é que ele funciona em cenários onde o Kerberos não consegue — acesso por endereço IP em vez de nome, serviços sem SPN registrado, autenticação fora do domínio. O problema é que esse mecanismo de desafio-resposta tem vulnerabilidades conhecidas que o Kerberos não tem.

O NTLM não foi removido do Windows porque ainda é necessário para cenários específicos — workgroups, acesso por IP, sistemas legados. Mas em ambientes enterprise modernos, toda autenticação NTLM que poderia ser Kerberos é um risco desnecessário.

O fallback silencioso — o problema que ninguém vê

O comportamento mais crítico de entender é o fallback automático do Kerberos para o NTLM. Quando o Kerberos falha — por DNS incorreto, SPN ausente ou duplicado, diferença de horário entre cliente e DC superior a 5 minutos — o Windows não exibe nenhum erro. Simplesmente tenta o NTLM.

Do ponto de vista do usuário, o logon funcionou. Do ponto de vista do administrador sem os logs certos, tudo parece normal. Mas nos bastidores, uma autenticação que deveria usar Kerberos está usando NTLM — com todas as implicações de segurança que isso traz.

Em ambientes enterprise com políticas de auditoria maduras, autenticações NTLM onde se espera Kerberos aparecem nos logs de segurança e disparam alertas. Em ambientes sem essa visibilidade, o problema pode existir há meses sem que ninguém perceba.

O Event ID 4624 no Security Log revela qual protocolo foi usado em cada logon. O campo Authentication Package indica Kerberos ou NTLM. Quando esse campo mostra NTLM em autenticações de domínio, é um sinal de que algo no fluxo Kerberos está falhando silenciosamente — e vale investigar a causa raiz antes que isso se torne um vetor de ataque.

As vulnerabilidades do NTLM que o Kerberos resolve

O NTLM é vulnerável a duas classes de ataque que o Kerberos, por design, não permite.

A primeira é o Pass-the-Hash. Como o NTLM autentica com um hash da senha — não com a senha em si — um atacante que obtém o hash de um usuário pode usá-lo diretamente para autenticar, sem precisar quebrar a senha. O hash vira a credencial. Em ambientes onde o NTLM é predominante, isso permite movimento lateral significativo após um comprometimento inicial.

A segunda é o NTLM Relay. O mecanismo de desafio-resposta do NTLM pode ser interceptado e retransmitido — um atacante no meio da comunicação captura o desafio e a resposta e os usa para autenticar em outro serviço. Ataques como o Responder exploram exatamente esse comportamento em redes onde o NTLM ainda está ativo.

O Kerberos não é vulnerável a esses ataques porque a autenticação é mediada pelo KDC — não há hash trafegando diretamente entre cliente e servidor, e tickets são emitidos especificamente para um serviço e um cliente, tornando a retransmissão inútil.

Quando o NTLM ainda é necessário

Mesmo em ambientes enterprise modernos, o NTLM ainda tem casos de uso legítimos. Acesso a recursos por endereço IP — em vez de nome DNS — força o NTLM porque o Kerberos não consegue emitir um ticket sem um SPN registrado para o nome do serviço. Sistemas legados que não suportam Kerberos também dependem do NTLM para autenticar.

A estratégia correta não é eliminar o NTLM completamente — o que causaria quebra em sistemas legítimos — mas reduzir seu uso ao mínimo necessário, auditar onde ele ainda aparece e garantir que não está sendo usado onde o Kerberos deveria estar.

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

Se você quer entender como Kerberos e NTLM se comportam em tempo real — o fallback acontecendo no lab, os Event IDs sendo gerados, o SPN duplicado simulado e corrigido — o Módulo 3 do Identity Engineer Foundation cobre exatamente isso.

Scripts PowerShell prontos, mapa comparativo de protocolos 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