LmCompatibilityLevel er ein Windows-policy, ikkje ei VPN-reparasjon

Nokon får ikkje tilgang til ein filressurs over VPN, les at senking av LmCompatibilityLevel fiksar NTLM-problem, og endrar han på ein delt server. Neste morgon feilar andre program, og det opphavlege problemet er der framleis. Denne innstillinga har aldri vore ein brytar per tunnel; ho er ei fråsegn på maskinnivå om kva autentiseringssvar dette systemet sender og godtek. Å endre henne for å reparere éi innlogging skriv om reglane for kvar innlogging maskinen utfører.

Å lese dei dokumenterte nivåa er den raskaste måten å slutte å handsame ein policyverdi som eit magisk tal.

Tre nivå, tre ulike lovnadar

Nivå 1 får klienten til å sende LM- og NTLM-svar, og brukar NTLMv2-sesjonssikkerheit når forhandlinga tillèt det. Nivå 3 får klienten til å sende berre NTLMv2-svar, noko som ikkje er det same som å avvise kvart eldre svar på mottakarsida. Nivå 5 held klienten på NTLMv2 og legg til den dokumenterte avvisinga av LM og NTLMv1 frå domenekontrolløren. Tre tal, og skilnaden mellom dei er ei policyavgjerd og ikkje ei preferanse.

Desse skilnadene forklarar kvifor det er upåliteleg å kopiere ein verdi frå eit fungerande tilfelle. Å flytte ein feilkonfigurert klient frå 1 til den godkjende grunnlinja kan vere rett. Å flytte ein herda utrulling frå 5 ned til 3 berre fordi ein forumtråd nemnde 3, lempar ei grense nokon valde med vilje, og det blir gjort for kvar teneste maskinen snakkar med.

Les den effektive policyen, ikkje éin registerverdi

Eit skriveverna blikk på den lokale verdien er eit rimeleg utgangspunkt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Ein manglande verdi tyder ikkje at den effektive policyen er null, fordi ein domene- eller lokal tryggingspolicy kan setje han andre stader, og rolla til maskinen endrar kva han gjer med talet.

Kontroller den styrte policyen, systemrolla og den faktiske builden før du konkluderer med noko. Ein arbeidsstasjon og ein domenekontrollør med same verdi oppfører seg ulikt i øvre ende, og det er den delen folk gløymer når dei samanliknar to maskinar.

Identifiser kva autentisering som faktisk feila

Kerberos-billettproblem, NTLM-avvisingar og VPN-opptaksfeil treng ulike prov. Hald måltenesta, kontoen og den nøyaktige feilen saman i eitt notat, og sjå deretter på kva tenesta bad om i staden for kva klienten føretrekkjer. Det eine notatet hindrar den vanlegaste feilen, nemleg å endre ein klientverdi for å svare på ei avvising på serversida.

Å senke ein policy gong på gong til ein generisk innloggingsfeil forsvinn er ikkje diagnostikk; det er ei endring som skjuler provet. Viss programmet brukar Kerberos, er NTLM-kompatibilitetsnivået ikkje eingong den relevante kontrollen, og du har lempa ei grense forgjeves.

Noko protokollstøtte kan ikkje gjenopprettast

Windows 11 24H2 og Windows Server 2025 inneheld ikkje lenger NTLMv1-nettverksautentisering i det heile. Ingen kompatibilitetstal bringar tilbake ein protokoll som builden ikkje lenger implementerer, så ein nedgradering som hjelpte på ein eldre versjon, vil rett og slett feile på ein nyare. Microsoft dokumenterer den fjerninga separat frå policyinnstillinga, og å blande dei to gir råd som ikkje kan fungere.

Ei nærskyld, men anna avgrensing gjeld for NTLMv1-avleidde legitimasjonar som blir brukte av MSCHAPv2-basert einskildinnlogging. Det er eit spørsmål om avleidde legitimasjonar, ikkje nettverksprotokollen sjølv, og ikkje denne eine registerverdien. Å handsame alle tre som same tema er måten organisasjonar endar med å svekkje éin kontroll medan dei prøver å reparere ein annan.

Endre han gjennom eigaren, og test så begge retningar

Viss ei retting verkeleg er nødvendig, gjer ho gjennom policyeigaren slik at grunnlinja held seg samanhengande, og noter kvifor. Test deretter eit autorisert program under den nye innstillinga og eit medvite forbode autentiseringstilfelle, fordi ei endring som reparerer éi deling og stille tillèt eldre svar andre stader, er ikkje ein suksess. Ei fungerande VPN-tilkopling bevisar at opptaket lukkast. Ho validerer ikkje autentiseringspolicyen til maskinen, og viser absolutt ikkje at kvar teneste bak han framleis oppfører seg som designa.

Viss tenesta som feilar er Kerberos-basert, slutt heilt å sjå på denne innstillinga. Viss det er ein eldre eining som verkeleg ikkje kan gjere det betre, dokumenter det unntaket og avgrens det, fordi alternativet er ei stille svekt grunnlinje som ingen hugsar å ha godkjend.