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, полностью перестаньте смотреть на этот параметр. Если же это устаревшее устройство, которое действительно не может лучше, задокументируйте это исключение и ограничьте его область, потому что альтернатива — тихо ослабенная базовая линия, о согласовании которой никто не помнит.