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