LmCompatibilityLevel은 Windows 정책이지 VPN 해결책이 아닙니다

누군가 VPN으로 파일 공유에 접근하지 못해, LmCompatibilityLevel을 낮추면 NTLM 문제가 해결된다는 글을 읽고 공유 서버에서 그 값을 바꿉니다. 다음 날 아침 다른 애플리케이션이 실패하고, 원래 문제는 그대로 남아 있습니다. 이 설정은 결코 터널별 스위치가 아니었으며, 이것은 이 시스템이 어떤 인증 응답을 보내고 받아들일지에 대한 컴퓨터 전체 수준의 선언입니다. 로그온 하나를 고치려고 이 값을 바꾸면 컴퓨터가 수행하는 모든 로그온의 규칙이 다시 쓰입니다.

문서화된 수준을 읽는 것이 정책 값을 마법의 숫자로 다루는 습관을 끊는 가장 빠른 방법입니다.

세 가지 수준, 세 가지 다른 약속

수준 1은 클라이언트가 LM 및 NTLM 응답을 보내도록 하며, 협상이 허용하면 NTLMv2 세션 보안을 사용합니다. 수준 3은 클라이언트가 NTLMv2 응답만 보내도록 하며, 이는 수신 측에서 모든 레거시 응답을 거부하는 것과 같지 않습니다. 수준 5는 클라이언트를 NTLMv2에 유지하고 도메인 컨트롤러의 문서화된 LM 및 NTLMv1 거부를 추가합니다. 세 개의 숫자이며, 그 사이의 차이는 선호가 아니라 정책 결정입니다.

이런 차이 때문에 작동하는 사례에서 값을 복사하는 것이 신뢰할 수 없습니다. 잘못 구성된 클라이언트를 1에서 승인된 기준선으로 옮기는 것은 올바를 수 있습니다. 포럼 스레드가 3을 언급했다는 이유만으로 강화된 배포를 5에서 3으로 내리는 것은 누군가 의도적으로 선택한 경계를 느슨하게 만들며, 컴퓨터가 대화하는 모든 서비스에 대해 그렇게 합니다.

레지스트리 값 하나가 아니라 적용되는 정책을 읽으세요

로컬 값에 대한 읽기 전용 확인은 합리적인 출발점입니다: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. 도메인 정책이나 로컬 보안 정책이 다른 곳에서 설정할 수 있고, 컴퓨터의 역할이 그 숫자로 무엇을 하는지를 바꾸기 때문에, 값이 없다고 해서 적용되는 정책이 영이라는 뜻은 아닙니다.

무엇이든 결론을 내리기 전에 관리되는 정책, 시스템 역할, 실제 빌드를 확인하세요. 같은 값을 가진 워크스테이션과 도메인 컨트롤러는 상단에서 다르게 동작하며, 두 컴퓨터를 비교할 때 사람들이 잊는 것이 바로 그 부분입니다.

실제로 어떤 인증이 실패했는지 파악하세요

Kerberos 티켓 문제, NTLM 거부, VPN 허용 실패에는 서로 다른 증거가 필요합니다. 대상 서비스, 계정, 정확한 오류를 하나의 메모에 함께 두고, 클라이언트가 선호하는 것이 아니라 서비스가 요청한 것을 보세요. 그 메모 하나가 서버 측 거부에 답하려고 클라이언트 측 값을 바꾸는 가장 흔한 잘못된 선택을 막습니다.

일반적인 로그온 오류가 사라질 때까지 정책을 반복해서 낮추는 것은 진단이 아니라 증거를 숨기는 변경입니다. 애플리케이션이 Kerberos를 사용한다면 NTLM 호환 수준은 관련 제어조차 아니며, 경계를 공연히 느슨하게 만든 셈입니다.

일부 프로토콜 지원은 복원할 수 없습니다

Windows 11 24H2와 Windows Server 2025에는 NTLMv1 네트워크 인증이 전혀 포함되지 않습니다. 빌드가 더 이상 구현하지 않는 프로토콜을 호환성 숫자로 되돌릴 수는 없으므로, 이전 릴리스에서 도움이 된 다운그레이드는 최신 릴리스에서 그저 실패합니다. Microsoft는 그 제거를 정책 설정과 별도로 문서화하며, 둘을 혼동하면 작동할 수 없는 조언이 됩니다.

관련은 있지만 다른 제한이 MSCHAPv2 기반 싱글 사인온이 사용하는 NTLMv1 파생 자격 증명에 적용됩니다. 이것은 파생 자격 증명의 문제이지 네트워크 프로토콜 자체의 문제도, 이 레지스트리 값의 문제도 아닙니다. 셋을 같은 주제로 다루는 것이 조직이 한 통제를 약화시키면서 다른 통제를 고치려는 방식입니다.

소유자를 통해 변경하고, 그다음 양방향을 시험하세요

정말 수정이 필요하다면 기준선이 일관되게 유지되도록 정책 소유자를 통해 진행하고, 이유를 기록하세요. 공유 하나를 고치면서 다른 곳에서 레거시 응답을 조용히 허용하는 변경은 성공이 아니기 때문에, 그다음 새 설정에서 승인된 애플리케이션과 의도적으로 금지된 인증 사례를 시험하세요. 작동하는 VPN 연결은 허용이 성공했음을 증명합니다. 그것은 컴퓨터의 인증 정책을 검증하지 않으며, 그 뒤의 모든 서비스가 여전히 설계대로 동작한다는 것을 보여주지도 않습니다.

실패하는 서비스가 Kerberos 기반이라면 이 설정을 보는 것을 완전히 그만두세요. 정말로 더 나아질 수 없는 구형 장비라면 아무도 승인한 기억이 없는 기준선이 조용히 약화된 채 남지 않도록 그 예외를 문서화하고 범위를 정하세요.