LmCompatibilityLevel on Windows-käytäntö, ei VPN-korjaus

Joku ei pääse tiedostojakoon VPN:n yli, lukee, että LmCompatibilityLevelin laskeminen korjaa NTLM-ongelmat, ja muuttaa sitä jaetulla palvelimella. Seuraavana aamuna muut sovellukset epäonnistuvat, ja alkuperäinen ongelma on yhä siellä. Asetus ei ollut koskaan tunnelikohtainen kytkin; se on laitetason lausuma siitä, mitä todennusvastauksia tämä järjestelmä lähettää ja hyväksyy. Sen muuttaminen yhden kirjautumisen korjaamiseksi kirjoittaa uudelleen säännöt jokaiselle kirjautumiselle, jonka laite tekee.

Dokumentoitujen tasojen lukeminen on nopein tapa lopettaa käytäntöarvon kohteleminen taikalukuna.

Kolme tasoa, kolme erilaista lupausta

Taso 1 saa asiakkaan lähettämään LM- ja NTLM-vastauksia ja käyttää NTLMv2-istuntoTurvaa, kun neuvottelu sen sallii. Taso 3 saa asiakkaan lähettämään vain NTLMv2-vastauksia, mikä ei ole sama asia kuin kaikkien vanhojen vastausten hylkääminen vastaanottajan päässä. Taso 5 pitää asiakkaan NTLMv2:ssa ja lisää toimialueen ohjaimen dokumentoidun LM:n ja NTLMv1:n hylkäyksen. Kolme lukua, ja niiden välinen ero on käytäntöpäätös eikä mieltymys.

Nämä erot selittävät, miksi arvon kopioiminen toimivasta tapauksesta on epäluotettavaa. Väärin määritetyn asiakkaan siirtäminen tasolta 1 hyväksyttyyn perustasoon voi olla oikein. Kovennetun käyttöönoton siirtäminen tasolta 5 alas tasolle 3 vain siksi, että foorumiketju mainitsi 3, löysentää rajaa, jonka joku valitsi tarkoituksella, ja se tehdään jokaiselle palvelulle, jonka kanssa laite puhuu.

Lue voimassa oleva käytäntö, älä yhtä rekisteriarvoa

Vain luku -katsaus paikalliseen arvoon on järkevä lähtökohta: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Puuttuva arvo ei tarkoita, että voimassa oleva käytäntö on nolla, koska toimialueen tai paikallinen suojauskäytäntö voi asettaa sen muualla, ja laitteen rooli muuttaa sitä, mitä se tekee luvulla.

Tarkista hallittu käytäntö, järjestelmän rooli ja todellinen koontiversio ennen kuin päättelet mitään. Työasema ja toimialueen ohjain samalla arvolla käyttäytyvät eri tavalla yläpäässä, ja juuri sen ihmiset unohtavat vertaillessaan kahta laitetta.

Selvitä, mikä todennus todella epäonnistui

Kerberos-lippuongelmat, NTLM-hylkäykset ja VPN-pääsyn epäonnistumiset tarvitsevat erilaisia todisteita. Pidä kohdepalvelu, tili ja tarkka virhe yhdessä muistiinpanossa ja katso sitten, mitä palvelu pyysi, eikä sitä, mitä asiakas suosii. Tuo yksi muistiinpano estää yleisimmän väärän käännöksen eli asiakaspuolen arvon muuttamisen vastauksena palvelinpuolen hylkäykseen.

Käytännön toistuva laskeminen, kunnes yleinen kirjautumisvirhe katoaa, ei ole diagnoosia; se on muutos, joka kätkee todisteen. Jos sovellus käyttää Kerberosta, NTLM-yhteensopivuustaso ei ole edes relevantti hallinta, ja olet löysentänyt rajaa turhaan.

Osa protokollatuesta ei ole palautettavissa

Windows 11 24H2 ja Windows Server 2025 eivät enää sisällä NTLMv1-verkkotodennusta lainkaan. Mikään yhteensopivuusluku ei tuo takaisin protokollaa, jota koontiversio ei enää toteuta, joten vanhemmalla versiolla auttanut alasajo yksinkertaisesti epäonnistuu uudemmalla. Microsoft dokumentoi kyseisen poiston erillään käytäntöasetuksesta, ja näiden kahden sekoittaminen tuottaa neuvoja, jotka eivät voi toimia.

Läheinen mutta erillinen rajoitus koskee NTLMv1:stä johdettuja tunnistetietoja, joita MSCHAPv2-pohjainen kertakirjautuminen käyttää. Se on johdettujen tunnistetietojen kysymys, ei verkkoprotokolla itse eikä tämä yksi rekisteriarvo. Kaikkien kolmen käsitteleminen samana aiheena on tapa, jolla organisaatiot lopulta heikentävät yhtä hallintaa yrittäessään korjata toista.

Muuta sitä omistajan kautta ja testaa sitten molemmat suunnat

Jos korjaus on todella tarpeen, tee se käytännön omistajan kautta, jotta perustaso pysyy yhtenäisenä, ja kirjaa miksi. Testaa sitten valtuutettua sovellusta uuden asetuksen alla ja tarkoituksella kiellettyä todennustapausta, koska muutos, joka korjaa yhden jaon ja sallii hiljaa vanhat vastaukset muualla, ei ole onnistuminen. Toimiva VPN-yhteys todistaa, että pääsy onnistui. Se ei validoi laitteen todennuskäytäntöä, eikä varmasti näytä, että jokainen sen takana oleva palvelu käyttäytyy edelleen suunnitellusti.

Jos epäonnistuva palvelu perustuu Kerberokseen, lopeta tämän asetuksen katsominen kokonaan. Jos se on vanha laite, joka todella ei pysty parempaan, dokumentoi poikkeus ja rajaa se, koska vaihtoehto on hiljaa heikennetty perustaso, jonka hyväksymistä kukaan ei muista.