LmCompatibilityLevel estas politiko de Windows, ne VPN-riparo

Iu ne povas atingi dosierujon per la VPN, legas, ke malaltigi LmCompatibilityLevel solvas problemojn de NTLM, kaj ŝanĝas ĝin sur kunhava servilo. La sekvan matenon aliaj aplikaĵoj malsukcesas, kaj la origina problemo ankoraŭ restas. Ĉi tiu agordo neniam estis ŝaltilo por unuopa tunelo; ĝi estas deklaro je maŝina nivelo pri tio, kiujn aŭtentikajn respondojn ĉi tiu sistemo sendos kaj akceptos. Ŝanĝi ĝin por ripari unu ensaluton reskribas la regulojn por ĉiu ensaluto, kiun la maŝino faras.

Legi la dokumentitajn nivelojn estas la plej rapida maniero ĉesi trakti politikan valoron kiel magian nombron.

Tri niveloj, tri malsamaj promesoj

Nivelo 1 igas la klienton sendi respondojn LM kaj NTLM, uzante NTLMv2-kunsidan sekurecon kiam la intertraktado permesas tion. Nivelo 3 igas la klienton sendi nur respondojn NTLMv2, kio ne estas la sama afero kiel rifuzi ĉiun malnovan respondon ĉe la ricevanta flanko. Nivelo 5 tenas la klienton je NTLMv2 kaj aldonas la dokumentitan rifuzon de LM kaj NTLMv1 fare de la domajna regilo. Tri nombroj, kaj la diferenco inter ili estas politika decido, ne prefero.

Tiuj diferencoj klarigas, kial kopii valoron el funkcianta kazo estas malfidinda. Movi malĝuste agorditan klienton de 1 al la aprobita bazlinio povas esti ĝuste. Movi harditan instaladon de 5 malsupren al 3 nur ĉar forumfadeno menciis 3 malstreĉas limon, kiun iu elektis intence, kaj ĝi faras tion por ĉiu servo, kun kiu la maŝino parolas.

Legu la efektivan politikon, ne unu registran valoron

Nurlega rigardo al la loka valoro estas racia komencpunkto: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Mankanta valoro ne signifas, ke la efektiva politiko estas nulo, ĉar domajna aŭ loka sekureca politiko povas starigi ĝin aliloke, kaj la rolo de la maŝino ŝanĝas, kion ĝi faras kun la nombro.

Kontrolu la administritan politikon, la sisteman rolon kaj la realan konstruaĵon antaŭ ol konkludi ion ajn. Laborejo kaj domajna regilo kun la sama valoro kondutas malsame ĉe la supra fino, kaj tion homoj forgesas kiam ili komparas du maŝinojn.

Identigu, kiu aŭtentigo efektive malsukcesis

Problemoj de Kerberos-biletoj, rifuzoj de NTLM kaj malsukcesoj de VPN-akcepto bezonas malsamajn pruvojn. Tenu la celan servon, la konton kaj la precizan eraron kune en unu noto, poste rigardu, kion la servo petis, anstataŭ kion la kliento preferas. Tiu unu noto malhelpas la plej kutiman malĝustan turnon, nome ŝanĝi klientflankan valoron por respondi al servflanka rifuzo.

Ripete malaltigi politikon ĝis ĝenerala ensaluta eraro malaperas ne estas diagnozo; ĝi estas ŝanĝo, kiu kaŝas la pruvon. Se la aplikaĵo uzas Kerberos, la NTLM-kongrueca nivelo eĉ ne estas la koncerna regilo, kaj vi malstreĉis limon vane.

Iu protokola subteno ne povas esti restarigita

Windows 11 24H2 kaj Windows Server 2025 tute ne plu inkluzivas NTLMv1-retan aŭtentigon. Neniu kongrueca nombro revenigas protokolon, kiun la konstruaĵo ne plu realigas, do malsuprengrado, kiu helpis en pli malnova eldono, simple malsukcesos en pli nova. Microsoft dokumentas tiun forigon aparte de la politika agordo, kaj miksado de la du produktas konsilojn, kiuj ne povas funkcii.

Rilata sed malsama limigo validas por legitimiloj derivitaj de NTLMv1, kiujn uzas la unuopa ensaluto bazita sur MSCHAPv2. Tio estas demando pri derivitaj legitimiloj, ne pri la reta protokolo mem, kaj ne pri ĉi tiu unu registra valoro. Trakti ĉiujn tri kiel la saman temon estas la vojo, per kiu organizoj malfortigas unu regilon dum ili provas ripari alian.

Ŝanĝu ĝin per la posedanto, poste testu ambaŭ direktojn

Se korekto vere necesas, faru ĝin per la posedanto de la politiko, por ke la bazlinio restu kohera, kaj registru kial. Poste testu rajtigitan aplikaĵon sub la nova agordo kaj intence malpermesitan aŭtentigan kazon, ĉar ŝanĝo, kiu riparas unu kunhavaĵon kaj silente permesas malnovajn respondojn aliloke, ne estas sukceso. Funkcianta VPN-konekto pruvas, ke la akcepto sukcesis. Ĝi ne validigas la aŭtentigan politikon de la maŝino, kaj certe ne montras, ke ĉiu servo malantaŭ ĝi ankoraŭ kondutas kiel projektite.

Se la malsukcesanta servo bazitas sur Kerberos, tute ĉesu rigardi ĉi tiun agordon. Se temas pri malnova aparato, kiu vere ne povas pli bone, dokumentu tiun escepton kaj limigu ĝin, ĉar la alternativo estas silente malfortigita bazlinio, kiun neniu memoras esti aprobinta.