NTLM a Caminho da Extinção: Auditoria e Migração para Kerberos

A Microsoft declarou todas as versões do NTLM (LANMAN, NTLMv1 e NTLMv2) oficialmente descontinuadas em Junho de 2024, e o Windows Server 2025 dá o primeiro passo prático: um interruptor que bloqueia ligações NTLM (NT LAN Manager) no SMB (Server Message Block). O que era uma recomendação de consultores passou a ser um calendário — e as PME com Active Directory têm de saber hoje que aplicações, impressoras e scripts ainda dependem de NTLM antes que o bloqueio as deixe sem rede.

Este guia cobre o ciclo completo: entender porque é que o NTLM é um problema (relay, sem MFA, sem Kerberos), auditar onde é usado com as ferramentas incluídas no Windows, migrar as dependências para Kerberos/Negotiate, e activar o bloqueio no Windows Server 2025 com excepções controladas. Nada disto exige software adicional — tudo vem com o sistema.

⚠ Porque é urgente

O NTLM é o protocolo preferido de ataques relay e pass-the-hash: não valida o servidor, não suporta autenticação moderna (incluindo MFA — Multi-Factor Authentication) e expõe hashes capturáveis. O Windows Server 2025 já traz o interruptor para o desligar — fica o alerta: auditar primeiro, bloquear depois.

NTLM vs Kerberos: O Que Muda

Aspecto NTLM Kerberos
Validação do servidor Nenhuma — qualquer host pode receber o hash Mutual authentication (cliente valida o servidor)
Ataques típicos Relay, pass-the-hash, captura de hashes em rede Muito mais difícil — tickets com timestamp e SPNs
Delegação e MFA Não suporta Suporta (delegação restrita, smart cards, MFA)
Estado na Microsoft Descontinuado (junho 2024); bloqueável no WS2025 Protocolo de referência em qualquer AD (Active Directory)

O NTLM sobrevive nas redes por três razões: aplicações antigas que fazem autenticação própria, impressoras e NAS (Network Attached Storage) que só falam NTLM, e clientes fora do domínio. A auditoria do Passo 1 serve exactamente para descobrir qual dos três casos existe na vossa rede — sem isso, bloquear às cegas quebra serviços.

Passo 1 — Auditar Quem Usa NTLM na Rede

O Windows tem auditoria NTLM pronta a activar. Nos Domain Controllers (e nos servidores de ficheiros), active a auditoria e observe os registos durante 2 a 4 semanas:

# Activar auditoria NTLM (Directiva de Grupo ou registo nos DCs)
auditpol /set /subcategory:"Audit NTLM authentication" /success:enable /failure:enable

# Nos servidores: auditar tráfego NTLM entrante
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name AuditOutboundNTLM -Value 2
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name AuditIncomingNTLM -Value 2

# Ler os eventos gerados (DC: eventos 4776/4768-4770; servidores: 8001-8004 do Security)
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=8004} -MaxEvents 20 | 
  Select-Object TimeCreated, Message

Os eventos indicam o computador, a conta e o destino de cada utilização NTLM. Compile um inventário: quem chama, o quê e para onde. A política Network security: Restrict NTLM (em gpmc.msc → Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options) também tem modos de auditoria que registam sem bloquear — o ponto de partida recomendado.

Passo 2 — Migrar Dependências para Kerberos

Com o inventário em mãos, as migrações típicas são:

  • Aplicações que usam credenciais NTLM hardcoded — migrar para autenticação Negotiate/Kerberos (a maioria das libs .NET, Java e Python suporta com SPN correcto). Registar os SPNs em falta com setspn -S.
  • Acessos a partilhas por IP — o Kerberos precisa de nomes; configurar DNS (Domain Name System) e usar \\servidor.partilha\ em vez de \\10.0.0.5\.
  • Impressoras e NAS antigos — actualizar firmware ou substituir; em último caso, ficam na lista de excepções do Passo 3 com data de revisão.
  • Contas de serviço — substituir por Managed Service Accounts (gMSA), que usam Kerberos nativamente e renovam a password sozinhas.

Passo 3 — Bloquear NTLM no Windows Server 2025

No WS2025, o SMB passa a poder recusar NTLM directamente. Primeiro em modo auditoria, depois em bloqueio:

# Servidor: recusar NTLM nas ligações ENTRANTEs ao SMB (após auditoria limpa)
Set-SmbServerConfiguration -BlockNTLM $true

# Cliente: impedir que o servidor USE NTLM para sair
Set-SmbClientConfiguration -BlockNTLM $true

# Excepções pontuais (hosts que ainda não migram):
Set-SmbServerConfiguration -BlockNTLMExceptionsList @("NAS-antigo.corp.local")

# Reverter se algo partir (temporariamente!)
Set-SmbServerConfiguration -BlockNTLM $false

O documento oficial da Microsoft recomenda exactamente esta sequência: activar o bloqueio no cliente (que deixa de iniciar NTLM), depois no servidor (que deixa de aceitar), com uma lista de excepções nomeada para os sistemas que ainda não migraram. Cada excepção deve ter dono e data para sair da lista.

Passo 4 — Restrições de Domínio em 2019/2022

No Windows Server 2019/2022 (e nos clientes), o controlo faz-se pela política Network security: Restrict NTLM e pela família NTLM authentication in this domain:

# Reforço 1: só NTLMv2 (recusa LM e NTLMv1) — aplica-se a servidores e clientes
# Política equivalente: "Network security: LAN Manager authentication level" = Refuse LM & NTLM
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel -Value 5 -Type DWord

# Reforço 2: auditar o tráfego NTLM ENTRANTE
# Política equivalente: "Network security: Restrict NTLM: Audit Incoming NTLM Traffic" = Audit all
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name AuditReceivingNTLMTraffic -Value 2 -Type DWord

# (No domínio inteiro, a política "Audit NTLM authentication in this domain" aplica-se nos DCs via GPO)

# Ler os eventos (log dedicado, não o Security):
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 20

A sequência segura para domínios em 2019/2022: (1) LmCompatibilityLevel 5 (só NTLMv2), (2) auditar 30 dias, (3) migrar o que o inventário mostrar, (4) quando o domínio tiver WS2025 disponível, avançar para o bloqueio do Passo 3. O fallback gerido por MDM usa o CSP WindowsLogon (AllowAutomaticRestartSignOut e políticas NTLM equivalentes) em dispositivos geridos.

Passo 5 — Verificar e Monitorizar

# Confirmar que o SMB já não negocia NTLM (de outro host, tentar autenticação NTLM)
Get-SmbServerConfiguration | Select-Object BlockNTLM, RejectUnencryptedAccess

# Procurar eventos de bloqueio/reject
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-SmbClient/Security"; Id=31011} -MaxEvents 10

# No DC: confirmar que os eventos 4776 NTLM deixaram de crescer
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4776; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Measure-Object

Estado final saudável: BlockNTLM = True no cliente e no servidor SMB, zero eventos 4776 NTLM nos DCs ao longo de uma semana, e a lista de excepções vazia ou com datas de revisão. A partir daqui, qualquer novo dispositivo que “precise” de NTLM entra no processo de excepção — não na configuração silenciosa.

Erros Comuns

Erro/Sintoma Causa Solução
Impressora/NAS deixa de aceitar acessos após bloqueio Dispositivo só suporta NTLM Adicionar à lista de excepções + planear substituição/firmware
App legada falha com erro de logon Aplicação usa NTLM hardcoded Migrar para Negotiate/Kerberos; registar SPN em falta
Acesso por IP à partilha falha Kerberos não funciona por IP, só por nome Criar registo DNS e usar o nome do servidor
Bloqueio aplicado e ninguém sabe o que partiu Sem auditoria prévia Voltar atrás, executar o Passo 1 durante 2-4 semanas e repetir
Eventos 4776 continuam nos DCs Alguns hosts ainda em NTLMv1/NTLMv2 fora das políticas Verificar GPOs (Group Policy Objects) aplicadas e dispositivos fora do domínio

Artigos Relacionados

Fontes oficiais: Block NTLM connections on SMB in Windows Server 2025, Deprecated Windows features (deprecação NTLM) e NTLM overview (Microsoft Learn).