LmCompatibilityLevel er en Windows-politik, ikke en VPN-reparation

Nogen kan ikke nå en filshare over VPN, læser at en lavere LmCompatibilityLevel løser NTLM-problemer, og ændrer den på en delt server. Næste morgen fejler andre programmer, og det oprindelige problem er der stadig. Indstillingen har aldrig været en kontakt pr. tunnel; den er en erklæring på maskinniveau om, hvilke godkendelsessvar dette system sender og accepterer. At ændre den for at rette ét logon skriver reglerne om for hvert logon, maskinen udfører.

At læse de dokumenterede niveauer er den hurtigste vej til at holde op med at behandle en politikværdi som et magisk tal.

Tre niveauer, tre forskellige løfter

Niveau 1 får klienten til at sende LM- og NTLM-svar og bruger NTLMv2-sessionssikkerhed, når forhandlingen tillader det. Niveau 3 får klienten til kun at sende NTLMv2-svar, hvilket ikke er det samme som at afvise alle ældre svar hos modtageren. Niveau 5 holder klienten på NTLMv2 og tilføjer den dokumenterede afvisning af LM og NTLMv1 fra domænecontrolleren. Tre tal, og forskellen mellem dem er en politikbeslutning snarere end en præference.

De forskelle forklarer, hvorfor det er upålideligt at kopiere en værdi fra et fungerende tilfælde. At flytte en fejlkonfigureret klient fra 1 til den godkendte baseline kan være korrekt. At flytte en hærdet installation fra 5 ned til 3, fordi en forumtråd nævnte 3, lemper en grænse, som nogen valgte med vilje, og det gør det for enhver tjeneste, maskinen taler med.

Læs den effektive politik, ikke én registreringsværdi

Et skrivebeskyttet kig på den lokale værdi er et rimeligt udgangspunkt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. En manglende værdi betyder ikke, at den effektive politik er nul, fordi en domæne- eller lokal sikkerhedspolitik kan sætte den andre steder, og maskinens rolle ændrer, hvad den gør med tallet.

Kontroller den administrerede politik, systemrollen og den faktiske build, før du konkluderer noget. En arbejdsstation og en domænecontroller med samme værdi opfører sig forskelligt i den øvre ende, og det er den del, folk glemmer, når de sammenligner to maskiner.

Identificér, hvilken godkendelse der faktisk fejlede

Kerberos-billetproblemer, NTLM-afvisninger og VPN-adgangsfejl kræver forskellige beviser. Hold måltjenesten, kontoen og den præcise fejl sammen i ét notat, og se derefter på, hvad tjenesten anmodede om, i stedet for hvad klienten foretrækker. Det ene notat forhindrer den mest almindelige fejltagelse, nemlig at ændre en klientværdi for at svare på en afvisning på serversiden.

At sænke en politik gentagne gange, indtil en generisk logonfejl forsvinder, er ikke diagnostik; det er en ændring, der skjuler beviset. Hvis programmet bruger Kerberos, er NTLM-kompatibilitetsniveauet ikke engang den relevante kontrol, og du har lempet en grænse forgæves.

Noget protokolunderstøttelse kan ikke gendannes

Windows 11 24H2 og Windows Server 2025 indeholder slet ikke NTLMv1-netværksgodkendelse længere. Intet kompatibilitetstal bringer en protokol tilbage, som buildet ikke længere implementerer, så en nedgradering, der hjalp på en ældre version, vil simpelthen fejle på en nyere. Microsoft dokumenterer den fjernelse adskilt fra politikindstillingen, og at blande de to producerer råd, der ikke kan fungere.

En beslægtet, men anderledes begrænsning gælder for NTLMv1-afledte legitimationsoplysninger, som MSCHAPv2-baseret single sign-on bruger. Det er et spørgsmål om afledte legitimationsoplysninger, ikke netværksprotokollen selv, og ikke denne ene registreringsværdi. At behandle alle tre som samme emne er måden, organisationer ender med at svække én kontrol, mens de forsøger at rette en anden.

Ændr den gennem ejeren, og test derefter begge retninger

Hvis en rettelse virkelig er nødvendig, så gør det gennem politiksejeren, så baselinen forbliver sammenhængende, og notér hvorfor. Test derefter et autoriseret program under den nye indstilling og et bevidst forbudt godkendelsestilfælde, fordi en ændring, der retter én share og stiltiende tillader ældre svar andre steder, ikke er en succes. En fungerende VPN-forbindelse beviser, at adgangen lykkedes. Den validerer ikke maskinens godkendelsespolitik og viser bestemt ikke, at hver tjeneste bag den stadig opfører sig som designet.

Hvis den fejlende tjeneste er Kerberos-baseret, skal du helt holde op med at kigge på denne indstilling. Hvis det er et ældre apparat, der virkelig ikke kan gøre det bedre, så dokumentér den undtagelse og afgræns den, fordi alternativet er en stille svækket baseline, som ingen husker at have godkendt.