LmCompatibilityLevel is ’n Windows-beleid, nie ’n VPN-oplossing nie

Iemand kry nie ’n lêerdeling oor die VPN bereik nie, lees dat die verlaging van LmCompatibilityLevel NTLM-probleme oplos, en verander dit op ’n gedeelde bediener. Die volgende oggend misluk ander programme, en die oorspronklike probleem is steeds daar. Die instelling was nooit ’n per-tonnel-skakelaar nie; dit is ’n masjienwye verklaring oor watter verifikasieresponse hierdie stelsel sal stuur en aanvaar. Om dit te verander om een aanmelding reg te maak, herskryf die reëls vir elke aanmelding wat die masjien uitvoer.

Om die gedokumenteerde vlakke te lees is die vinnigste manier om op te hou om ’n beleidswaarde as ’n magiese getal te behandel.

Drie vlakke, drie verskillende beloftes

Vlak 1 laat die kliënt LM- en NTLM-response stuur en gebruik NTLMv2-sessiebeveiliging wanneer die onderhandeling dit toelaat. Vlak 3 laat die kliënt slegs NTLMv2-response stuur, wat nie dieselfde ding is as om elke ouerwetse response aan die ontvangkant te weier nie. Vlak 5 hou die kliënt op NTLMv2 en voeg die gedokumenteerde weiering van LM en NTLMv1 deur die domeinbeheerder by. Drie getalle, en die gaping tussen hulle is ’n beleidsbesluit eerder as ’n voorkeur.

Daardie verskille verduidelik waarom dit onbetroubaar is om ’n waarde uit ’n werkende geval te kopieer. Om ’n verkeerd opgestelde kliënt van 1 na die goedgekeurde basislyn te skuif, kan korrek wees. Om ’n geharde ontplooiing van 5 af na 3 te skuif omdat ’n forumdraad 3 genoem het, verslap ’n grens wat iemand doelbewus gekies het, en dit doen dit vir elke diens waarmee die masjien praat.

Lees die effektiewe beleid, nie een registerwaarde nie

’n Lees-alleen kyk na die plaaslike waarde is ’n redelike beginpunt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. ’n Afwesige waarde beteken nie die effektiewe beleid is nul nie, want ’n domein- of plaaslike sekuriteitsbeleid kan dit elders stel en die masjien se rol verander wat dit met die getal doen.

Kontroleer die bestuurde beleid, die stelselrol en die werklike build voordat jy enigiets aflei. ’n Werkstasie en ’n domeinbeheerder met dieselfde waarde tree aan die bokant anders op, en dit is die deel wat mense vergeet wanneer hulle twee masjiene vergelyk.

Identifiseer watter verifikasie werklik misluk het

Kerberos-kaartjieprobleme, NTLM-verwerping en VPN-toelatingsfoute vereis verskillende bewyse. Hou die teikendiensor, die rekening en die presiese fout saam in een nota, en kyk dan na wat die diens versoek het eerder as na wat die kliënt verkies. Daardie een nota voorkom die mees algemene verkeerde draai, naamlik om ’n kliëntkant-waarde te verander om ’n verwerping aan die bedienerkant te antwoord.

Om herhaaldelik ’n beleid te verlaag totdat ’n generiese aanmeldingsfout verdwyn, is nie diagnose nie; dit is ’n verandering wat die bewyse verberg. As die toepassing Kerberos gebruik, is die NTLM-versoenbaarheidsvlak nie eers die relevante beheer nie, en dan het jy ’n grens verniet verslap.

Sommige protokolondersteuning kan nie herstel word nie

Windows 11 24H2 en Windows Server 2025 sluit nie meer NTLMv1-netwerkverifikasie in nie. Geen versoenbaarheidsgetal bring ’n protokol terug wat die build nie meer implementeer nie, so ’n afgradering wat op ’n ouer weergawe gehelp het, sal eenvoudig op ’n nuwer een misluk. Microsoft dokumenteer daardie verwydering apart van die beleidinstelling, en om die twee te verwar lewer advies wat nie kan werk nie.

’n Verwante maar aparte beperking geld vir NTLMv1-afgeleide geloofsbriewe wat deur MSCHAPv2-gebaseerde enkel-aanmelding gebruik word. Dit is ’n vraag oor afgeleide geloofsbriewe, nie die netwerkprotokol self nie, en nie hierdie een registerwaarde nie. Om al drie as dieselfde onderwerp te behandel, is hoe organisasies een beheer verswak terwyl hulle ’n ander probeer regmaak.

Verander dit deur die eienaar, en toets dan beide kante

As ’n regstelling werklik nodig is, maak dit deur die beleideienaar sodat die basislyn samehangend bly, en teken aan waarom. Toets dan ’n gemagtigde toepassing onder die nuwe instelling en ’n doelbewus verbode verifikasiegeval, want ’n verandering wat een deling regmaak en stilweg ouerwetse response elders toelaat, is nie ’n sukses nie. ’n Werkende VPN-verbinding bewys dat toelating geslaag het. Dit valideer nie die verifikasiebeleid van die masjien nie, en dit wys beslis nie dat elke diens agter dit steeds optree soos ontwerp nie.

As die mislukkende diens op Kerberos gebaseer is, moet jy heeltemal ophou na hierdie instelling kyk. As dit ’n ouerwetse toestel is wat werklik nie beter kan nie, dokumenteer daardie uitsondering en bepaal die omvang daarvan, want die alternatief is ’n stilweg verswakte basislyn wat niemand onthou hulle het dit goedgekeur nie.