LmCompatibilityLevel es una política de Windows, no una solución para la VPN

Alguien no llega a un recurso compartido por la VPN, lee que bajar LmCompatibilityLevel arregla los problemas de NTLM y lo cambia en un servidor compartido. A la mañana siguiente otras aplicaciones fallan, y el problema original sigue ahí. Esta configuración nunca fue un interruptor por túnel; es una declaración a escala de máquina sobre qué respuestas de autenticación enviará y aceptará este sistema. Cambiarla para arreglar un solo inicio de sesión reescribe las reglas de cada inicio de sesión que realiza la máquina.

Leer los niveles documentados es la forma más rápida de dejar de tratar un valor de política como un número mágico.

Tres niveles, tres promesas distintas

El nivel 1 hace que el cliente envíe respuestas LM y NTLM, usando la seguridad de sesión NTLMv2 cuando la negociación lo permite. El nivel 3 hace que el cliente envíe solo respuestas NTLMv2, lo que no es lo mismo que rechazar todas las respuestas heredadas en el lado receptor. El nivel 5 mantiene al cliente en NTLMv2 y añade el rechazo documentado de LM y NTLMv1 por parte del controlador de dominio. Tres números, y la diferencia entre ellos es una decisión de política y no una preferencia.

Esas diferencias explican por qué copiar un valor de un caso que funciona no es fiable. Mover un cliente mal configurado del 1 a la línea base aprobada puede ser correcto. Mover un despliegue endurecido del 5 al 3 solo porque un hilo de foro mencionó el 3 relaja una frontera que alguien eligió deliberadamente, y lo hace para cada servicio con el que habla la máquina.

Lea la política efectiva, no un valor del registro

Una mirada de solo lectura al valor local es un punto de partida razonable: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Que falte el valor no significa que la política efectiva sea cero, porque una política de dominio o una política de seguridad local puede fijarlo en otro sitio, y el rol de la máquina cambia lo que hace con el número.

Compruebe la política administrada, el rol del sistema y la compilación real antes de concluir nada. Una estación de trabajo y un controlador de dominio con el mismo valor se comportan distinto en el extremo superior, y esa es la parte que la gente olvida al comparar dos máquinas.

Identifique qué autenticación falló realmente

Los problemas de tickets Kerberos, los rechazos de NTLM y los fallos de admisión de la VPN necesitan pruebas distintas. Mantenga el servicio de destino, la cuenta y el error exacto juntos en una sola nota, y luego mire lo que pidió el servicio en lugar de lo que prefiere el cliente. Esa única nota evita el giro equivocado más común, que es cambiar un valor del lado del cliente para responder a un rechazo del lado del servidor.

Bajar una política una y otra vez hasta que desaparezca un error genérico de inicio de sesión no es diagnóstico; es un cambio que oculta la prueba. Si la aplicación usa Kerberos, el nivel de compatibilidad NTLM ni siquiera es el control relevante, y ha relajado una frontera para nada.

Hay soporte de protocolo que no se puede restaurar

Windows 11 24H2 y Windows Server 2025 ya no incluyen en absoluto la autenticación de red NTLMv1. Ningún número de compatibilidad devuelve un protocolo que la compilación ya no implementa, así que una degradación que ayudó en una versión anterior simplemente fallará en una más nueva. Microsoft documenta esa eliminación por separado de la configuración de política, y confundir ambas cosas produce consejos que no pueden funcionar.

Una restricción relacionada pero distinta se aplica a las credenciales derivadas de NTLMv1 que usa el inicio de sesión único basado en MSCHAPv2. Es una cuestión de credenciales derivadas, no del protocolo de red en sí, y no de este valor del registro. Tratar las tres cosas como el mismo tema es como las organizaciones acaban debilitando un control mientras intentan arreglar otro.

Cámbiela a través del propietario y luego pruebe las dos direcciones

Si de verdad hace falta una corrección, hágalo a través del propietario de la política para que la línea base siga siendo coherente, y anote por qué. Después pruebe una aplicación autorizada con la nueva configuración y un caso de autenticación deliberadamente no permitido, porque un cambio que arregla un recurso compartido y permite en silencio respuestas heredadas en otro sitio no es un éxito. Una conexión VPN que funciona demuestra que la admisión tuvo éxito. No valida la política de autenticación de la máquina, y mucho menos demuestra que cada servicio detrás de ella siga comportándose como se diseñó.

Si el servicio que falla se basa en Kerberos, deje de mirar esta configuración por completo. Si es un dispositivo antiguo que de verdad no puede hacerlo mejor, documente esa excepción y delimítela, porque la alternativa es una línea base debilitada en silencio que nadie recuerda haber aprobado.