LmCompatibilityLevel este o politică Windows, nu o reparație VPN

Cineva nu ajunge la o partajare de fișiere prin VPN, citește că reducerea LmCompatibilityLevel rezolvă problemele NTLM și o modifică pe un server partajat. A doua zi dimineață alte aplicații eșuează, iar problema inițială este încă acolo. Această setare nu a fost niciodată un comutator per tunel; este o declarație la nivelul întregului calculator despre ce răspunsuri de autentificare va trimite și va accepta acest sistem. Modificarea ei pentru a repara o singură autentificare rescrie regulile pentru fiecare autentificare pe care o face calculatorul.

Citirea nivelurilor documentate este cea mai rapidă cale de a înceta să tratați o valoare de politică ca pe un număr magic.

Trei niveluri, trei promisiuni diferite

Nivelul 1 face clientul să trimită răspunsuri LM și NTLM, folosind securitatea sesiunii NTLMv2 atunci când negocierea permite. Nivelul 3 face clientul să trimită doar răspunsuri NTLMv2, ceea ce nu este același lucru cu a refuza fiecare răspuns vechi pe partea care primește. Nivelul 5 ține clientul pe NTLMv2 și adaugă refuzul documentat al LM și NTLMv1 de către controlerul de domeniu. Trei numere, iar diferența dintre ele este o decizie de politică, nu o preferință.

Aceste diferențe explică de ce copierea unei valori dintr-un caz funcțional nu este fiabilă. Mutarea unui client configurat greșit de la 1 la linia de bază aprobată poate fi corectă. Mutarea unei implementări întărite de la 5 la 3 doar pentru că un fir de forum a menționat 3 relaxează o limită pe care cineva a ales-o deliberat, și o face pentru fiecare serviciu cu care calculatorul vorbește.

Citiți politica efectivă, nu o singură valoare de registru

O privire doar-citire la valoarea locală este un punct de plecare rezonabil: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Absența valorii nu înseamnă că politica efectivă este zero, deoarece o politică de domeniu sau o politică locală de securitate o poate stabili în altă parte, iar rolul calculatorului schimbă ce face cu acel număr.

Verificați politica gestionată, rolul sistemului și build-ul real înainte de a trage vreo concluzie. O stație de lucru și un controler de domeniu cu aceeași valoare se comportă diferit la capătul superior, și exact asta uită oamenii când compară două calculatoare.

Identificați ce autentificare a eșuat de fapt

Problemele cu tichete Kerberos, refuzurile NTLM și eșecurile de admitere VPN necesită dovezi diferite. Țineți serviciul țintă, contul și eroarea exactă împreună într-o singură notă, apoi uitați-vă la ce a cerut serviciul, nu la ce preferă clientul. Acea singură notă împiedică cea mai frecventă greșeală, anume schimbarea unei valori pe partea clientului pentru a răspunde unui refuz pe partea serverului.

Scăderea repetată a unei politici până când dispare o eroare generică de autentificare nu este diagnostic; este o schimbare care ascunde dovada. Dacă aplicația folosește Kerberos, nivelul de compatibilitate NTLM nici măcar nu este controlul relevant, iar limita a fost relaxată degeaba.

Unele suporturi de protocol nu pot fi restaurate

Windows 11 24H2 și Windows Server 2025 nu mai includ deloc autentificarea de rețea NTLMv1. Niciun număr de compatibilitate nu readuce un protocol pe care build-ul nu îl mai implementează, așa că o retrogradare care a ajutat pe o versiune mai veche va eșua pur și simplu pe una mai nouă. Microsoft documentează acea eliminare separat de setarea de politică, iar amestecarea celor două produce sfaturi care nu pot funcționa.

O restricție înrudită, dar distinctă se aplică acreditărilor derivate din NTLMv1 folosite de autentificarea unică bazată pe MSCHAPv2. Este o chestiune de acreditări derivate, nu de protocolul de rețea în sine și nu de această singură valoare de registru. Tratarea tuturor trei ca același subiect este calea pe care organizațiile ajung să slăbească un control în timp ce încearcă să repare altul.

Modificați-o prin proprietar, apoi testați ambele direcții

Dacă o corecție este cu adevărat necesară, faceți-o prin proprietarul politicii, astfel încât linia de bază să rămână coerentă, și notați de ce. Apoi testați o aplicație autorizată sub noua setare și un caz de autentificare interzis în mod deliberat, deoarece o schimbare care repară o partajare și permite în tăcere răspunsuri vechi în altă parte nu este un succes. O conexiune VPN funcțională dovedește că admiterea a reușit. Ea nu validează politica de autentificare a calculatorului și cu siguranță nu arată că fiecare serviciu din spatele lui se comportă încă așa cum a fost proiectat.

Dacă serviciul care eșuează se bazează pe Kerberos, opriți complet vizualizarea acestei setări. Dacă este un dispozitiv vechi care chiar nu poate face mai bine, documentați acea excepție și delimitați-o, deoarece alternativa este o linie de bază slăbită în tăcere pe care nimeni nu își amintește că a aprobat-o.