Az LmCompatibilityLevel Windows-szabályzat, nem VPN-javítás

Valaki nem ér el egy fájlmegosztást a VPN-en keresztül, olvassa, hogy az LmCompatibilityLevel csökkentése megoldja az NTLM-problémákat, és átállítja egy megosztott kiszolgálón. Másnap reggel más alkalmazások hibáznak, és az eredeti probléma továbbra is fennáll. Ez a beállítás soha nem volt alagútonkénti kapcsoló; gépszintű kijelentés arról, milyen hitelesítési válaszokat küld és fogad el ez a rendszer. Megváltoztatása egyetlen bejelentkezés javításáért újraírja a szabályokat minden bejelentkezéshez, amelyet a gép végrehajt.

A dokumentált szintek elolvasása a leggyorsabb módja annak, hogy abbahagyja egy szabályzatérték varázsszámként való kezelését.

Három szint, három különböző ígéret

Az 1. szint arra készteti az ügyfelet, hogy LM- és NTLM-válaszokat küldjön, NTLMv2-munkamenet-biztonságot használva, amikor az egyeztetés engedi. A 3. szint arra készteti az ügyfelet, hogy csak NTLMv2-válaszokat küldjön, ami nem ugyanaz, mint minden régi válasz elutasítása a fogadó oldalon. Az 5. szint NTLMv2-n tartja az ügyfelet, és hozzáadja a tartományvezérlő dokumentált LM- és NTLMv1-elutasítását. Három szám, és a köztük lévő különbség szabályzatdöntés, nem preferencia.

Ezek a különbségek magyarázzák, miért megbízhatatlan egy érték másolása egy működő esetből. Egy hibásan beállított ügyfél 1-ről a jóváhagyott alapvonalra mozgatása helyes lehet. Egy megerősített telepítés 5-ről 3-ra mozgatása csak azért, mert egy fórumtéma megemlítette a 3-at, lazít egy határon, amelyet valaki szándékosan választott, és ezt minden szolgáltatásra megteszi, amellyel a gép beszél.

A tényleges szabályzatot olvassa, ne egy beállításjegyzék-értéket

A helyi értékre tett csak olvasható pillantás ésszerű kiindulópont: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. A hiányzó érték nem jelenti azt, hogy a tényleges szabályzat nulla, mert egy tartományi vagy helyi biztonsági szabályzat máshol is beállíthatja, és a gép szerepe megváltoztatja, mit tesz a számmal.

Ellenőrizze a felügyelt szabályzatot, a rendszer szerepét és a tényleges buildet, mielőtt bármit megállapítana. Egy munkaállomás és egy tartományvezérlő ugyanazzal az értékkel másképp viselkedik a felső végén, és éppen ezt felejtik el az emberek, amikor két gépet összehasonlítanak.

Állapítsa meg, melyik hitelesítés hibázott valójában

A Kerberos-jeggyel kapcsolatos problémák, az NTLM-elutasítások és a VPN-belépési hibák különböző bizonyítékokat igényelnek. Tartsa egy jegyzetben a célszolgáltatást, a fiókot és a pontos hibát, majd azt nézze, mit kért a szolgáltatás, ne azt, mit részesít előnyben az ügyfél. Ez az egy jegyzet akadályozza meg a leggyakoribb rossz fordulatot, vagyis egy ügyféloldali érték megváltoztatását egy kiszolgálóoldali elutasításra válaszul.

Egy szabályzat ismételt csökkentése addig, amíg egy általános bejelentkezési hiba el nem tűnik, nem diagnózis; ez olyan változtatás, amely elrejti a bizonyítékot. Ha az alkalmazás Kerberost használ, az NTLM kompatibilitási szint nem is a releváns ellenőrzés, és feleslegesen lazított egy határon.

Egyes protokolltámogatás nem állítható vissza

A Windows 11 24H2 és a Windows Server 2025 már egyáltalán nem tartalmazza az NTLMv1 hálózati hitelesítést. Egyetlen kompatibilitási szám sem hoz vissza olyan protokollt, amelyet a build már nem valósít meg, ezért a régebbi kiadáson segítő visszalépés egyszerűen meghiúsul az újabbon. A Microsoft ezt az eltávolítást a szabályzatbeállítástól elkülönítve dokumentálja, és a kettő összekeverése olyan tanácsot eredményez, amely nem működhet.

Kapcsolódó, de eltérő korlátozás vonatkozik az MSCHAPv2-alapú egyszeri bejelentkezés által használt, NTLMv1-ből származtatott hitelesítő adatokra. Ez a származtatott hitelesítő adatok kérdése, nem magáé a hálózati protokollé, és nem ezé az egy beállításjegyzék-értéké. Mindhármat ugyanazon témaként kezelni az az út, amelyen a szervezetek meggyengítenek egy ellenőrzést, miközben egy másikat próbálnak javítani.

A tulajdonoson keresztül módosítsa, majd mindkét irányt tesztelje

Ha valóban szükség van javításra, a szabályzat tulajdonosán keresztül tegye meg, hogy az alapvonal egységes maradjon, és jegyezze fel, miért. Ezután teszteljen egy engedélyezett alkalmazást az új beállítás mellett és egy szándékosan tiltott hitelesítési esetet, mert egy megosztást javító és máshol csendben régi válaszokat engedélyező változtatás nem siker. Egy működő VPN-kapcsolat bizonyítja, hogy a belépés sikerült. Nem érvényesíti a gép hitelesítési szabályzatát, és biztosan nem mutatja meg, hogy minden mögötte lévő szolgáltatás még mindig a tervezett módon viselkedik.

Ha a hibázó szolgáltatás Kerberos-alapú, hagyjon fel teljesen ennek a beállításnak a nézegetésével. Ha viszont egy régi eszköz, amely valóban nem tud jobbat, dokumentálja ezt a kivételt és határolja be, mert az alternatíva egy csendben meggyengített alapvonal, amelynek jóváhagyására senki sem emlékszik.