LmCompatibilityLevel adalah kebijakan Windows, bukan perbaikan VPN

Seseorang tidak bisa mencapai berbagi pakai melalui VPN, membaca bahwa menurunkan LmCompatibilityLevel memperbaiki masalah NTLM, lalu mengubahnya di server bersama. Keesokan paginya aplikasi lain gagal, dan masalah aslinya masih ada. Setelan ini tidak pernah menjadi sakelar per tunnel; ini pernyataan tingkat mesin tentang respons autentikasi mana yang akan dikirim dan diterima sistem ini. Mengubahnya untuk memperbaiki satu logon menulis ulang aturan bagi setiap logon yang dilakukan mesin.

Membaca tingkat yang didokumentasikan adalah cara tercepat berhenti memperlakukan nilai kebijakan sebagai angka ajaib.

Tiga tingkat, tiga janji berbeda

Tingkat 1 membuat klien mengirim respons LM dan NTLM, menggunakan keamanan sesi NTLMv2 bila negosiasi mengizinkannya. Tingkat 3 membuat klien hanya mengirim respons NTLMv2, yang tidak sama dengan menolak setiap respons lama di sisi penerima. Tingkat 5 menahan klien pada NTLMv2 dan menambahkan penolakan LM serta NTLMv1 oleh pengendali domain yang didokumentasikan. Tiga angka, dan selisih di antaranya adalah keputusan kebijakan, bukan preferensi.

Perbedaan itu menjelaskan mengapa menyalin nilai dari kasus yang berhasil tidak dapat diandalkan. Memindahkan klien yang salah konfigurasi dari 1 ke garis dasar yang disetujui bisa benar. Memindahkan penerapan yang diperketat dari 5 turun ke 3 hanya karena sebuah utas forum menyebut 3 melonggarkan batas yang dipilih seseorang dengan sengaja, dan itu berlaku untuk setiap layanan yang diajak bicara oleh mesin.

Baca kebijakan yang berlaku, bukan satu nilai registri

Melihat nilai lokal hanya-baca adalah titik awal yang wajar: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Nilai yang tidak ada bukan berarti kebijakan yang berlaku nol, karena kebijakan domain atau kebijakan keamanan lokal dapat menyetelnya di tempat lain, dan peran mesin mengubah apa yang dilakukannya dengan angka itu.

Periksa kebijakan terkelola, peran sistem, dan build sebenarnya sebelum menyimpulkan apa pun. Stasiun kerja dan pengendali domain dengan nilai yang sama berperilaku berbeda di ujung atas, dan itulah bagian yang orang lupakan saat membandingkan dua mesin.

Identifikasi autentikasi mana yang sebenarnya gagal

Masalah tiket Kerberos, penolakan NTLM, dan kegagalan penerimaan VPN membutuhkan bukti yang berbeda. Simpan layanan target, akun, dan kesalahan persisnya bersama dalam satu catatan, lalu lihat apa yang diminta layanan, bukan apa yang disukai klien. Satu catatan itu mencegah kesalahan paling umum, yaitu mengubah nilai di sisi klien untuk menjawab penolakan di sisi server.

Menurunkan kebijakan berulang kali sampai kesalahan logon umum hilang bukanlah diagnosis; itu perubahan yang menyembunyikan bukti. Jika aplikasi menggunakan Kerberos, tingkat kompatibilitas NTLM bahkan bukan kontrol yang relevan, dan Anda telah melonggarkan batas tanpa guna.

Sebagian dukungan protokol tidak dapat dipulihkan

Windows 11 24H2 dan Windows Server 2025 tidak lagi menyertakan autentikasi jaringan NTLMv1 sama sekali. Tidak ada angka kompatibilitas yang mengembalikan protokol yang tidak lagi diterapkan oleh build, jadi penurunan versi yang tampak membantu pada rilis lama akan gagal pada rilis baru. Microsoft mendokumentasikan penghapusan itu terpisah dari setelan kebijakan, dan mencampur keduanya menghasilkan saran yang tidak mungkin berhasil.

Pembatasan terkait tetapi berbeda berlaku pada kredensial turunan NTLMv1 yang digunakan oleh logon tunggal berbasis MSCHAPv2. Itu pertanyaan kredensial turunan, bukan protokol jaringan itu sendiri, dan bukan nilai registri ini. Memperlakukan ketiganya sebagai topik yang sama adalah cara organisasi akhirnya melemahkan satu kontrol sambil mencoba memperbaiki yang lain.

Ubah melalui pemiliknya, lalu uji kedua arah

Jika koreksi benar-benar diperlukan, lakukan melalui pemilik kebijakan agar garis dasar tetap koheren, dan catat alasannya. Lalu uji aplikasi yang diizinkan di bawah setelan baru dan kasus autentikasi yang sengaja dilarang, karena perubahan yang memperbaiki satu berbagi pakai dan diam-diam mengizinkan respons lama di tempat lain bukanlah keberhasilan. Koneksi VPN yang berfungsi membuktikan penerimaan berhasil. Itu tidak memvalidasi kebijakan autentikasi mesin, dan jelas tidak menunjukkan bahwa setiap layanan di baliknya masih berperilaku seperti yang dirancang.

Jika layanan yang gagal berbasis Kerberos, berhenti sama sekali melihat setelan ini. Jika itu perangkat lama yang benar-benar tidak bisa berbuat lebih baik, dokumentasikan pengecualian itu dan tentukan cakupannya, karena alternatifnya adalah garis dasar yang diam-diam dilemahkan yang tidak diingat siapa pun pernah menyetujuinya.