LmCompatibilityLevel は Windows のポリシーであり、VPN の修正ではありません
1 つのレジストリ値がマシン全体のネットワーク ログオンを左右します。トンネルだけの話ではありません。修正として扱う前に、各レベルが何を送り、何を拒否するのかを確認してください。
VPN 経由でファイル共有に到達できない人が、LmCompatibilityLevel を下げれば NTLM の問題が直るという記事を読み、共有サーバーでその値を変更する。翌朝には他のアプリケーションが失敗し、元の問題はそのまま残っている。この設定はトンネルごとのスイッチだったことは一度もありません;これはこのシステムがどの認証応答を送信し、受け入れるかについてのマシン全体の宣言です。ひとつのログオンを直すために変更すると、マシンが行うすべてのログオンのルールが書き換えられます。
文書化されたレベルを読むことが、ポリシー値を魔法の数として扱うのをやめる最速の方法です。
三つのレベル、三つの異なる約束
レベル 1 はクライアントに LM 応答と NTLM 応答を送らせ、ネゴシエーションが許す場合は NTLMv2 セッション セキュリティを使用します。レベル 3 はクライアントに NTLMv2 応答だけを送らせますが、これは受信側ですべての従来の応答を拒否することと同じではありません。レベル 5 はクライアントを NTLMv2 に保ち、ドメイン コントローラーによる LM と NTLMv1 の拒否を文書どおりに追加します。三つの数であり、その間の差は好みではなくポリシーの判断です。
これらの違いが、動作している事例から値をコピーしても信頼できない理由を説明します。設定を誤ったクライアントを 1 から承認済みのベースラインに移すのは正しい場合があります。フォーラムのスレッドが 3 に触れていたからといって、強化された展開を 5 から 3 に下げるのは、誰かが意図的に選んだ境界を緩めることであり、しかもマシンが通信するすべてのサービスに対してそうすることになります。
ひとつのレジストリ値ではなく、有効なポリシーを読む
ローカルの値に対する読み取り専用の確認は妥当な出発点です: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel。ドメイン ポリシーやローカル セキュリティ ポリシーが別の場所で設定できるうえ、マシンの役割によってその数値の扱いが変わるので、値がないことは有効なポリシーがゼロであることを意味しません。
結論を出す前に、管理ポリシー、システムの役割、実際のビルドを確認してください。同じ値でもワークステーションとドメイン コントローラーでは上端の挙動が異なり、ふたつのマシンを比較するときに人々が忘れるのはまさにその部分です。
実際に失敗した認証を特定する
Kerberos チケットの問題、NTLM の拒否、VPN の受け入れ失敗にはそれぞれ別の証拠が必要です。対象のサービス、アカウント、正確なエラーを ひとつのメモにまとめ、クライアントが好むものではなくサービスが要求したものを見てください。サーバー側の拒否に応えるためにクライアント側の値を変えるという最もよくある間違いを、そのひとつのメモが防ぎます。
一般的なログオン エラーが消えるまでポリシーを何度も下げるのは診断ではなく、証拠を隠す変更です。アプリケーションが Kerberos を使っているなら、NTLM の互換レベルは関係する制御ですらなく、境界を無駄に緩めたことになります。
復元できないプロトコル サポートもある
Windows 11 24H2 と Windows Server 2025 には NTLMv1 ネットワーク認証がまったく含まれなくなりました。ビルドが実装しなくなったプロトコルを互換番号で戻すことはできないため、古いリリースで助けになったダウングレードは新しいリリースでは単に失敗します。Microsoft はその削除をポリシー設定とは別に文書化しており、両者を混同すると機能し得ない助言になります。
関連するが別の制限が、MSCHAPv2 ベースのシングル サインオンが使う NTLMv1 由来の資格情報に適用されます。これは派生資格情報の話であり、ネットワーク プロトコル自体の話でも、このひとつのレジストリ値の話でもありません。三つを同じ話題として扱うことが、組織が一方の制御を弱めながら他方を直そうとする理由です。
所有者を通じて変更し、そのうえで両方向をテストする
本当に修正が必要なら、ベースラインの一貫性を保つためにポリシーの所有者を通じて行い、理由を記録してください。次に、新しい設定のもとで許可されたアプリケーションと、意図的に禁止された認証ケースをひとつの共有を直して別の場所で従来の応答を黙って許可する変更は成功ではないので、次に、新しい設定のもとで許可されたアプリケーションと、意図的に禁止された認証ケースをテストしてください。VPN 接続が機能することは、受け入れが成功した証拠です。それはマシンの認証ポリシーを検証するものではなく、背後のすべてのサービスが設計どおりに動作し続けていることを示すものでもありません。
失敗しているサービスが Kerberos ベースなら、この設定を見るのは完全にやめてください。本当にそれ以上できない古い機器であれば、誰も承認した覚えのないベースラインが静かに弱められたままになるので、その例外を文書化して範囲を限定してください。