LmCompatibilityLevel é uma política do Windows, não um conserto de VPN

Alguém não alcança um compartilhamento de arquivos pela VPN, lê que baixar o LmCompatibilityLevel corrige problemas de NTLM e o altera num servidor compartilhado. Na manhã seguinte, outras aplicações falham, e o problema original continua lá. Essa configuração nunca foi um interruptor por túnel; é uma declaração no nível da máquina sobre quais respostas de autenticação este sistema enviará e aceitará. Alterá-la para consertar um único logon reescreve as regras de cada logon que a máquina realiza.

Ler os níveis documentados é a forma mais rápida de parar de tratar um valor de política como um número mágico.

Três níveis, três promessas diferentes

O nível 1 faz o cliente enviar respostas LM e NTLM, usando a segurança de sessão NTLMv2 quando a negociação permite. O nível 3 faz o cliente enviar apenas respostas NTLMv2, o que não é o mesmo que recusar todas as respostas antigas no lado receptor. O nível 5 mantém o cliente em NTLMv2 e acrescenta a recusa documentada de LM e NTLMv1 pelo controlador de domínio. Três números, e a diferença entre eles é uma decisão de política, não uma preferência.

Essas diferenças explicam por que copiar um valor de um caso que funciona não é confiável. Mover um cliente mal configurado do 1 para a linha de base aprovada pode estar correto. Mover uma implantação endurecida do 5 para o 3 só porque um tópico de fórum mencionou o 3 relaxa uma fronteira que alguém escolheu de propósito, e isso para cada serviço com que a máquina fala.

Leia a política efetiva, não um valor do registro

Uma olhada somente leitura no valor local é um ponto de partida razoável: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. A ausência do valor não significa que a política efetiva seja zero, porque uma política de domínio ou de segurança local pode defini-la em outro lugar, e o papel da máquina muda o que ela faz com o número.

Verifique a política gerenciada, o papel do sistema e a compilação real antes de concluir qualquer coisa. Uma estação de trabalho e um controlador de domínio com o mesmo valor comportam-se de forma diferente no extremo superior, e é essa a parte que as pessoas esquecem ao comparar duas máquinas.

Identifique qual autenticação realmente falhou

Problemas de ticket Kerberos, recusas NTLM e falhas de admissão da VPN exigem provas diferentes. Mantenha o serviço de destino, a conta e o erro exato juntos numa única nota, e depois olhe para o que o serviço pediu em vez do que o cliente prefere. Essa única nota evita o desvio errado mais comum, que é alterar um valor do lado do cliente para responder a uma recusa do lado do servidor.

Baixar uma política repetidamente até que um erro genérico de logon desapareça não é diagnóstico; é uma alteração que esconde a prova. Se a aplicação usa Kerberos, o nível de compatibilidade NTLM nem sequer é o controle relevante, e você relaxou uma fronteira sem motivo.

Algum suporte de protocolo não pode ser restaurado

O Windows 11 24H2 e o Windows Server 2025 já não incluem de todo a autenticação de rede NTLMv1. Nenhum número de compatibilidade traz de volta um protocolo que a compilação já não implementa, então uma degradação que ajudou numa versão anterior simplesmente falhará numa mais nova. A Microsoft documenta essa remoção separadamente da definição de política, e confundir as duas produz conselhos que não podem funcionar.

Uma restrição relacionada mas distinta aplica-se às credenciais derivadas de NTLMv1 usadas pelo logon único baseado em MSCHAPv2. É uma questão de credenciais derivadas, não do protocolo de rede em si, e não deste valor do registro. Tratar as três coisas como o mesmo tema é como as organizações acabam enfraquecendo um controle enquanto tentam consertar outro.

Altere-a através do proprietário e depois teste as duas direções

Se uma correção for realmente necessária, faça-a através do proprietário da política para que a linha de base continue coerente, e registe por quê. Depois teste uma aplicação autorizada com a nova configuração e um caso de autenticação deliberadamente proibido, porque uma alteração que conserta um compartilhamento e permite em silêncio respostas antigas noutro lugar não é um êxito. Uma ligação VPN que funciona prova que a admissão foi bem-sucedida. Não valida a política de autenticação da máquina, e muito menos mostra que cada serviço por trás dela continua a comportar-se como projetado.

Se o serviço que falha se baseia em Kerberos, pare completamente de olhar para esta configuração. Se for um dispositivo antigo que realmente não consegue fazer melhor, documente essa exceção e delimite-a, porque a alternativa é uma linha de base silenciosamente enfraquecida que ninguém se lembra de ter aprovado.