LmCompatibilityLevel er en Windows-policy, ikke en VPN-reparasjon

Noen får ikke tilgang til en filressurs over VPN, leser at senking av LmCompatibilityLevel fikser NTLM-problemer, og endrer den på en delt server. Neste morgen feiler andre programmer, og det opprinnelige problemet er der fortsatt. Denne innstillingen har aldri vært en bryter per tunnel; den er en erklæring på maskinnivå om hvilke autentiseringssvar dette systemet sender og godtar. Å endre den for å reparere én innlogging skriver om reglene for hver innlogging maskinen utfører.

Å lese de dokumenterte nivåene er den raskeste måten å slutte å behandle en policyverdi som et magisk tall.

Tre nivåer, tre ulike løfter

Nivå 1 får klienten til å sende LM- og NTLM-svar, og bruker NTLMv2-sesjonssikkerhet når forhandlingen tillater det. Nivå 3 får klienten til å sende bare NTLMv2-svar, noe som ikke er det samme som å avvise hvert eldre svar på mottakersiden. Nivå 5 holder klienten på NTLMv2 og legger til den dokumenterte avvisningen av LM og NTLMv1 fra domenekontrolleren. Tre tall, og forskjellen mellom dem er en policybeslutning og ikke en preferanse.

Disse forskjellene forklarer hvorfor det er upålitelig å kopiere en verdi fra et fungerende tilfelle. Å flytte en feilkonfigurert klient fra 1 til den godkjente grunnlinjen kan være riktig. Å flytte en herdet utrulling fra 5 ned til 3 bare fordi en forumtråd nevnte 3, lemper en grense noen valgte bevisst, og det gjøres for hver tjeneste maskinen snakker med.

Les den effektive policyen, ikke én registerverdi

Et skrivebeskyttet blikk på den lokale verdien er et rimelig utgangspunkt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. En manglende verdi betyr ikke at den effektive policyen er null, fordi en domene- eller lokal sikkerhetspolicy kan sette den andre steder, og maskinens rolle endrer hva den gjør med tallet.

Kontroller den styrte policyen, systemrollen og den faktiske builden før du konkluderer med noe. En arbeidsstasjon og en domenekontroller med samme verdi oppfører seg ulikt i øvre ende, og det er den delen folk glemmer når de sammenligner to maskiner.

Identifiser hvilken autentisering som faktisk feilet

Kerberos-billettproblemer, NTLM-avvisninger og VPN-opptaksfeil trenger ulike bevis. Hold måltjenesten, kontoen og den nøyaktige feilen sammen i ett notat, og se deretter på hva tjenesten ba om i stedet for hva klienten foretrekker. Det ene notatet forhindrer den vanligste feilen, nemlig å endre en klientverdi for å svare på en avvisning på serversiden.

Å senke en policy gjentatte ganger til en generisk innloggingsfeil forsvinner er ikke diagnostikk; det er en endring som skjuler beviset. Hvis programmet bruker Kerberos, er NTLM-kompatibilitetsnivået ikke engang den relevante kontrollen, og du har lempet en grense forgjeves.

Noe protokollstøtte kan ikke gjenopprettes

Windows 11 24H2 og Windows Server 2025 inneholder ikke lenger NTLMv1-nettverksautentisering i det hele tatt. Ingen kompatibilitetstall bringer tilbake en protokoll som builden ikke lenger implementerer, så en nedgradering som hjalp på en eldre versjon, vil rett og slett feile på en nyere. Microsoft dokumenterer den fjerningen separat fra policyinnstillingen, og å blande de to gir råd som ikke kan fungere.

En beslektet, men annen begrensning gjelder for NTLMv1-avledede legitimasjoner som brukes av MSCHAPv2-basert enkeltinnlogging. Det er et spørsmål om avledede legitimasjoner, ikke nettverksprotokollen selv, og ikke denne ene registerverdien. Å behandle alle tre som samme tema er måten organisasjoner ender opp med å svekke én kontroll mens de prøver å reparere en annen.

Endre den gjennom eieren, og test deretter begge retninger

Hvis en korreksjon virkelig er nødvendig, gjør den gjennom policyeieren slik at grunnlinjen forblir sammenhengende, og noter hvorfor. Test deretter et autorisert program under den nye innstillingen og et bevisst forbudt autentiseringstilfelle, fordi en endring som reparerer én deling og stille tillater eldre svar andre steder, ikke er en suksess. En fungerende VPN-forbindelse beviser at opptaket lyktes. Den validerer ikke maskinens autentiseringspolicy, og viser absolutt ikke at hver tjeneste bak den fortsatt oppfører seg som designet.

Hvis tjenesten som feiler er Kerberos-basert, slutt helt å se på denne innstillingen. Hvis det er en eldre enhet som virkelig ikke kan gjøre det bedre, dokumenter det unntaket og avgrens det, fordi alternativet er en stille svekket grunnlinje som ingen husker å ha godkjent.