LmCompatibilityLevel to zasada Windows, a nie poprawka VPN
Jedna wartość rejestru steruje logowaniem sieciowym na całym komputerze, nie tylko w tunelu. Dowiedz się, co każdy poziom wysyła i odrzuca, zanim potraktujesz to jako naprawę.
Ktoś nie dociera do udziału plików przez VPN, czyta, że obniżenie LmCompatibilityLevel naprawia problemy z NTLM, i zmienia je na współdzielonym serwerze. Następnego ranka inne aplikacje zawodzą, a pierwotny problem nadal istnieje. To ustawienie nigdy nie było przełącznikiem dla pojedynczego tunelu; jest deklaracją na poziomie całego komputera, jakie odpowiedzi uwierzytelniania ten system będzie wysyłał i akceptował. Zmiana go, aby naprawić jedno logowanie, przepisuje reguły dla każdego logowania wykonywanego przez komputer.
Czytanie udokumentowanych poziomów to najszybszy sposób, by przestać traktować wartość zasady jak magiczną liczbę.
Trzy poziomy, trzy różne obietnice
Poziom 1 każe klientowi wysyłać odpowiedzi LM i NTLM, korzystając z zabezpieczeń sesji NTLMv2, gdy negocjacja na to pozwala. Poziom 3 każe klientowi wysyłać tylko odpowiedzi NTLMv2, co nie jest tym samym, co odrzucenie każdej starszej odpowiedzi po stronie odbiorcy. Poziom 5 utrzymuje klienta na NTLMv2 i dodaje udokumentowane odrzucenie LM i NTLMv1 przez kontroler domeny. Trzy liczby, a różnica między nimi to decyzja o zasadzie, a nie preferencja.
Te różnice wyjaśniają, dlaczego kopiowanie wartości z działającego przypadku jest zawodne. Przeniesienie błędnie skonfigurowanego klienta z 1 na zatwierdzoną linię bazową może być właściwe. Przeniesienie utwardzonego wdrożenia z 5 na 3 tylko dlatego, że wątek na forum wspomniał o 3, poluzowuje granicę, którą ktoś wybrał świadomie, i dzieje się to dla każdej usługi, z którą komputer rozmawia.
Czytaj obowiązującą zasadę, a nie jedną wartość rejestru
Wgląd w wartość lokalną tylko do odczytu jest rozsądnym punktem wyjścia: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Brak wartości nie oznacza, że obowiązująca zasada wynosi zero, bo zasada domeny lub lokalna zasada zabezpieczeń może ustawić ją gdzie indziej, a rola komputera zmienia to, co robi z tą liczbą.
Sprawdź zasadę zarządzaną, rolę systemu i rzeczywistą kompilację, zanim cokolwiek wywnioskujesz. Stacja robocza i kontroler domeny z tą samą wartością zachowują się inaczej na górnym końcu, i właśnie to ludzie zapominają przy porównywaniu dwóch komputerów.
Ustal, które uwierzytelnianie faktycznie zawiodło
Problemy z biletami Kerberos, odrzucenia NTLM i niepowodzenia wstępu VPN wymagają różnych dowodów. Trzymaj docelową usługę, konto i dokładny błąd razem w jednej notatce, a potem patrz na to, o co prosiła usługa, a nie na to, co woli klient. Ta jedna notatka zapobiega najczęstszemu błędnemu krokowi, czyli zmianie wartości po stronie klienta w odpowiedzi na odmowę po stronie serwera.
Wielokrotne obniżanie zasady, aż zniknie ogólny błąd logowania, nie jest diagnozą; to zmiana, która ukrywa dowód. Jeśli aplikacja używa Kerberos, poziom zgodności NTLM nie jest nawet właściwą kontrolą, a granicę poluzowano na darmo.
Niektórego wsparcia protokołów nie da się przywrócić
Windows 11 24H2 i Windows Server 2025 w ogóle nie zawierają już uwierzytelniania sieciowego NTLMv1. Żadna liczba zgodności nie przywraca protokołu, którego kompilacja już nie implementuje, więc degradacja, która pomogła na starszej wersji, po prostu zawiedzie na nowszej. Microsoft dokumentuje to usunięcie osobno od ustawienia zasady, a mieszanie obu daje porady, które nie mogą działać.
Powiązane, ale inne ograniczenie dotyczy poświadczeń pochodnych od NTLMv1 używanych przez logowanie jednokrotne oparte na MSCHAPv2. To kwestia poświadczeń pochodnych, a nie samego protokołu sieciowego i nie tej jednej wartości rejestru. Traktowanie wszystkich trzech jako tego samego tematu to droga, na której organizacje osłabiają jedną kontrolę, próbując naprawić inną.
Zmieniaj to przez właściciela, a potem przetestuj oba kierunki
Jeśli poprawka jest naprawdę potrzebna, zrób ją przez właściciela zasady, aby linia bazowa pozostała spójna, i zapisz dlaczego. Potem przetestuj autoryzowaną aplikację w nowym ustawieniu oraz celowo zabroniony przypadek uwierzytelniania, bo zmiana, która naprawia jeden udział i po cichu zezwala na stare odpowiedzi gdzie indziej, nie jest sukcesem. Działające połączenie VPN dowodzi, że wstęp się udał. Nie potwierdza zasady uwierzytelniania komputera i z pewnością nie pokazuje, że każda usługa za nim nadal zachowuje się zgodnie z projektem.
Jeśli zawodząca usługa opiera się na Kerberos, przestań całkowicie patrzeć na to ustawienie. Jeśli to stare urządzenie, które naprawdę nie potrafi lepiej, udokumentuj ten wyjątek i ogranicz jego zakres, bo alternatywą jest cicho osłabiona linia bazowa, o której zatwierdzeniu nikt nie pamięta.