LmCompatibilityLevel is een Windows-beleid, geen VPN-oplossing

Iemand bereikt een bestandsshare niet via de VPN, leest dat het verlagen van LmCompatibilityLevel NTLM-problemen oplost, en wijzigt het op een gedeelde server. De volgende ochtend falen andere toepassingen, en het oorspronkelijke probleem is er nog steeds. Deze instelling is nooit een schakelaar per tunnel geweest; het is een verklaring op machineniveau over welke authenticatieantwoorden dit systeem verstuurt en accepteert. Die wijzigen om één aanmelding te repareren herschrijft de regels voor elke aanmelding die de machine uitvoert.

De gedocumenteerde niveaus lezen is de snelste manier om een beleidswaarde niet langer als magisch getal te behandelen.

Drie niveaus, drie verschillende beloften

Niveau 1 laat de client LM- en NTLM-antwoorden sturen en gebruikt NTLMv2-sessiebeveiliging wanneer de onderhandeling dat toestaat. Niveau 3 laat de client alleen NTLMv2-antwoorden sturen, wat niet hetzelfde is als elk oud antwoord aan de ontvangende kant weigeren. Niveau 5 houdt de client op NTLMv2 en voegt de gedocumenteerde weigering van LM en NTLMv1 door de domeincontroller toe. Drie getallen, en het verschil ertussen is een beleidsbeslissing en geen voorkeur.

Die verschillen verklaren waarom het kopiëren van een waarde uit een werkend geval onbetrouwbaar is. Een verkeerd geconfigureerde client van 1 naar de goedgekeurde basislijn verplaatsen kan juist zijn. Een geharde implementatie van 5 naar 3 terugzetten alleen omdat een forumdraadje 3 noemde, versoepelt een grens die iemand bewust koos, en dat voor elke service waarmee de machine praat.

Lees het effectieve beleid, niet één registerwaarde

Een alleen-lezen blik op de lokale waarde is een redelijk uitgangspunt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Een ontbrekende waarde betekent niet dat het effectieve beleid nul is, want een domein- of lokaal beveiligingsbeleid kan het elders instellen, en de rol van de machine verandert wat hij met het getal doet.

Controleer het beheerde beleid, de systeemrol en de werkelijke build voordat u iets concludeert. Een werkstation en een domeincontroller met dezelfde waarde gedragen zich aan de bovenkant anders, en dat is het deel dat mensen vergeten wanneer ze twee machines vergelijken.

Bepaal welke authenticatie werkelijk is mislukt

Kerberos-ticketproblemen, NTLM-weigeringen en VPN-toelatingsfouten vragen om verschillend bewijs. Houd de doelservice, het account en de exacte fout samen in één notitie, en kijk dan naar wat de service vroeg in plaats van wat de client verkiest. Die ene notitie voorkomt de meest voorkomende verkeerde stap, namelijk een clientwaarde wijzigen om een weigering aan de serverkant te beantwoorden.

Een beleid herhaaldelijk verlagen tot een generieke aanmeldfout verdwijnt is geen diagnose; het is een wijziging die het bewijs verbergt. Als de toepassing Kerberos gebruikt, is het NTLM-compatibiliteitsniveau niet eens de relevante controle, en hebt u een grens voor niets versoepeld.

Sommige protocolondersteuning kan niet worden hersteld

Windows 11 24H2 en Windows Server 2025 bevatten de NTLMv1-netwerkaanmelding helemaal niet meer. Geen enkel compatibiliteitsgetal haalt een protocol terug dat de build niet meer implementeert, dus een downgrade die op een oudere release hielp, zal op een nieuwere gewoon mislukken. Microsoft documenteert die verwijdering apart van de beleidsinstelling, en het door elkaar halen van beide levert advies op dat niet kan werken.

Een verwante maar andere beperking geldt voor van NTLMv1 afgeleide referenties die door MSCHAPv2-gebaseerde single sign-on worden gebruikt. Dat is een kwestie van afgeleide referenties, niet van het netwerkprotocol zelf, en niet van deze ene registerwaarde. Alle drie als hetzelfde onderwerp behandelen is de manier waarop organisaties de ene controle verzwakken terwijl ze een andere proberen te repareren.

Wijzig het via de eigenaar en test dan beide richtingen

Als een correctie echt nodig is, doe die dan via de eigenaar van het beleid zodat de basislijn samenhangend blijft, en leg vast waarom. Test daarna een geautoriseerde toepassing onder de nieuwe instelling en een bewust verboden authenticatiegeval, want een wijziging die één share repareert en elders stilzwijgend oude antwoorden toestaat is geen succes. Een werkende VPN-verbinding bewijst dat de toelating is gelukt. Die valideert het authenticatiebeleid van de machine niet, en toont zeker niet aan dat elke service erachter zich nog gedraagt zoals ontworpen.

Als de falende service op Kerberos is gebaseerd, stop dan helemaal met naar deze instelling te kijken. Is het een oud apparaat dat echt niet beter kan, documenteer die uitzondering en begrens haar, want het alternatief is een stil verzwakte basislijn waarvan niemand zich herinnert die te hebben goedgekeurd.