LmCompatibilityLevel — це політика Windows, а не виправлення VPN

Хтось не може дістатися до файлового ресурсу через VPN, читає, що зниження LmCompatibilityLevel вирішує проблеми NTLM, і змінює його на спільному сервері. Наступного ранку інші застосунки зазнають збоїв, а початкова проблема залишається. Цей параметр ніколи не був перемикачем для окремого тунелю; це заява на рівні всієї машини про те, які відповіді автентифікації ця система надсилатиме й прийматиме. Його зміна заради виправлення одного входу переписує правила для кожного входу, який виконує машина.

Читання задокументованих рівнів — найшвидший спосіб перестати сприймати значення політики як магічне число.

Три рівні, три різні обіцянки

Рівень 1 змушує клієнт надсилати відповіді LM і NTLM, використовуючи безпеку сеансу NTLMv2, коли це дозволяє узгодження. Рівень 3 змушує клієнт надсилати лише відповіді NTLMv2, що не те саме, що відхиляти кожну застарілу відповідь на стороні отримувача. Рівень 5 утримує клієнт на NTLMv2 і додає задокументовану відмову контролера домену від LM і NTLMv1. Три числа, і різниця між ними — рішення політики, а не вподобання.

Ці відмінності пояснюють, чому копіювання значення з робочого випадку ненадійне. Перевести неправильно налаштований клієнт з 1 на затверджену базову лінію може бути правильно. Перевести посилене розгортання з 5 на 3 лише тому, що в темі форуму згадувалося 3, означає послабити межу, яку хтось обрав свідомо, і так для кожного сервісу, з яким спілкується машина.

Читайте чинну політику, а не одне значення реєстру

Перегляд локального значення лише для читання — розумна відправна точка: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Відсутність значення не означає, що чинна політика дорівнює нулю, адже політика домену або локальна політика безпеки може задати його в іншому місці, а роль машини змінює те, що вона робить із цим числом.

Перевірте керовану політику, роль системи та фактичну збірку, перш ніж робити будь-які висновки. Робоча станція й контролер домену з однаковим значенням поводяться по-різному на верхньому краї, і саме це люди забувають, коли порівнюють дві машини.

Визначте, яка автентифікація насправді не вдалася

Проблеми з квитками Kerberos, відмови NTLM і невдачі допуску через VPN потребують різних доказів. Тримайте цільовий сервіс, обліковий запис і точну помилку разом в одній нотатці, а потім дивіться на те, що запросив сервіс, а не на те, що воліє клієнт. Ця одна нотатка запобігає найпоширенішому хибному кроку — зміні значення на боці клієнта у відповідь на відмову на боці сервера.

Багаторазове зниження політики, доки не зникне загальна помилка входу, — це не діагностика; це зміна, яка приховує доказ. Якщо застосунок використовує Kerberos, рівень сумісності NTLM навіть не є відповідним елементом керування, і ви марно послабили межу.

Частину підтримки протоколів відновити неможливо

Windows 11 24H2 і Windows Server 2025 більше взагалі не містять мережевої автентифікації NTLMv1. Жодне число сумісності не повертає протокол, який збірка більше не реалізує, тож зниження, що допомогло на старішій версії, просто зазнає невдачі на новішій. Microsoft документує це вилучення окремо від налаштування політики, і змішування обох дає поради, які не можуть працювати.

Пов'язане, але інше обмеження стосується облікових даних, похідних від NTLMv1, які використовує єдиний вхід на основі MSCHAPv2. Це питання похідних облікових даних, а не самого мережевого протоколу і не цього одного значення реєстру. Розгляд усіх трьох як однієї теми — це шлях, яким організації послаблюють один контроль, намагаючись виправити інший.

Змінюйте через власника, а потім перевірте обидва напрямки

Якщо виправлення справді потрібне, зробіть його через власника політики, щоб базова лінія залишалася узгодженою, і запишіть чому. Потім перевірте авторизований застосунок за нового налаштування та навмисно заборонений випадок автентифікації, бо зміна, яка виправляє один ресурс і тихо дозволяє застарілі відповіді в іншому місці, не є успіхом. Робоче з'єднання VPN доводить, що допуск вдався. Воно не перевіряє політику автентифікації машини і точно не показує, що кожен сервіс за нею досі поводиться так, як задумано.

Якщо збійний сервіс базується на Kerberos, повністю припиніть дивитися на це налаштування. Якщо ж це застарілий пристрій, який справді не може краще, задокументуйте цей виняток і обмежте його сферу, бо альтернатива — тихо послаблена базова лінія, про схвалення якої ніхто не пам'ятає.