LmCompatibilityLevel är en Windows-princip, inte en VPN-reparation

Någon kommer inte åt en filresurs via VPN, läser att sänkning av LmCompatibilityLevel löser NTLM-problem, och ändrar den på en delad server. Nästa morgon misslyckas andra program, och det ursprungliga problemet är kvar. Den här inställningen har aldrig varit en brytare per tunnel; den är ett uttalande på datornivå om vilka autentiseringssvar systemet skickar och accepterar. Att ändra den för att reparera en enda inloggning skriver om reglerna för varje inloggning datorn gör.

Att läsa de dokumenterade nivåerna är det snabbaste sättet att sluta behandla ett principvärde som ett magiskt tal.

Tre nivåer, tre olika löften

Nivå 1 får klienten att skicka LM- och NTLM-svar, och använder NTLMv2-sessionssäkerhet när förhandlingen tillåter det. Nivå 3 får klienten att bara skicka NTLMv2-svar, vilket inte är detsamma som att neka varje äldre svar på mottagarsidan. Nivå 5 håller klienten på NTLMv2 och lägger till domänkontrollantens dokumenterade nekande av LM och NTLMv1. Tre tal, och skillnaden mellan dem är ett principbeslut och inte en preferens.

Dessa skillnader förklarar varför det är opålitligt att kopiera ett värde från ett fungerande fall. Att flytta en felkonfigurerad klient från 1 till den godkända baslinjen kan vara korrekt. Att flytta en härdad utrullning från 5 ned till 3 bara för att en forumtråd nämnde 3, lossar en gräns som någon valde medvetet, och det görs för varje tjänst datorn talar med.

Läs den effektiva principen, inte ett registervärde

En skrivskyddad titt på det lokala värdet är en rimlig utgångspunkt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Ett saknat värde betyder inte att den effektiva principen är noll, eftersom en domän- eller lokal säkerhetsprincip kan sätta den någon annanstans, och datorns roll ändrar vad den gör med talet.

Kontrollera den hanterade principen, systemrollen och den faktiska versionen innan du drar någon slutsats. En arbetsstation och en domänkontrollant med samma värde beter sig olika i övre änden, och det är den delen folk glömmer när de jämför två datorer.

Identifiera vilken autentisering som faktiskt misslyckades

Kerberos-biljettproblem, NTLM-nekanden och VPN-inträdesfel kräver olika bevis. Håll måltjänsten, kontot och det exakta felet tillsammans i en anteckning, och titta sedan på vad tjänsten begärde i stället för vad klienten föredrar. Den enda anteckningen förhindrar det vanligaste felsteget, nämligen att ändra ett klientvärde för att svara på ett nekande på serversidan.

Att sänka en princip gång på gång tills ett generiskt inloggningsfel försvinner är inte diagnostik; det är en ändring som döljer beviset. Om programmet använder Kerberos är NTLM-kompatibilitetsnivån inte ens den relevanta kontrollen, och du har lossat en gräns förgäves.

Visst protokollstöd kan inte återställas

Windows 11 24H2 och Windows Server 2025 innehåller inte längre NTLMv1-nätverksautentisering alls. Inget kompatibilitetstal tar tillbaka ett protokoll som versionen inte längre implementerar, så en nedgradering som hjälpte på en äldre version kommer helt enkelt att misslyckas på en nyare. Microsoft dokumenterar den borttagningen separat från principinställningen, och att blanda de två ger råd som inte kan fungera.

En besläktad men annan begränsning gäller för NTLMv1-härledda autentiseringsuppgifter som används av MSCHAPv2-baserad enkel inloggning. Det är en fråga om härledda autentiseringsuppgifter, inte nätverksprotokollet självt, och inte detta enda registervärde. Att behandla alla tre som samma ämne är sättet organisationer till slut försvagar en kontroll medan de försöker reparera en annan.

Ändra den via ägaren och testa sedan båda riktningarna

Om en rättelse verkligen behövs, gör den via principägaren så att baslinjen förblir sammanhängande, och notera varför. Testa sedan ett auktoriserat program under den nya inställningen och ett medvetet förbjudet autentiseringsfall, eftersom en ändring som reparerar en delning och tyst tillåter äldre svar någon annanstans inte är en framgång. En fungerande VPN-anslutning bevisar att inträdet lyckades. Den validerar inte datorns autentiseringsprincip, och visar absolut inte att varje tjänst bakom den fortfarande beter sig som designat.

Om tjänsten som misslyckas är Kerberos-baserad, sluta helt att titta på den här inställningen. Om det är en äldre enhet som verkligen inte kan göra bättre, dokumentera det undantaget och avgränsa det, eftersom alternativet är en tyst försvagad baslinje som ingen minns att de godkände.