LmCompatibilityLevel の設定を一定に保つのは本当に面倒な作業です。設定値が希望の値で一定に保たれているように見えても、再起動やポリシーの更新をしてもデフォルトに戻ってしまうことがあります。また、そもそも変更されないこともあります。レジストリやローカルポリシーをいじっても何も変わらない場合は、グループポリシー (GPO) が設定を乗っ取っている可能性があります。このガイドでは、Windows クライアントとサーバーの両方でよくある原因とその解決方法を解説します。
LmCompatibilityLevel が元に戻ったり変更されなかったりする問題を修正する方法
方法1: グループポリシーが設定を上書きしているかどうかを確認する
手動でレジストリを編集しても反映されない場合、グループポリシーが原因となることがよくあります。GPOは複数のマシンにセキュリティ設定を適用する集中管理ポリシーであるため、ローカルで何かを変更しても、リフレッシュや再起動後にGPOがそれを上書きしてしまう可能性があります。ある設定では微調整でうまくいったのに、別の設定ではすぐに上書きされてしまう、といった状況は、本当に面倒です。
- 制御GPOを特定します。Win + R
rsop.mscで実行します。適用されているポリシーを示すポリシーの結果セットレポートが生成されます。 - [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [セキュリティ オプション]に移動します。
- 下にスクロールして「ネットワークセキュリティ：LAN Manager認証レベル」を見つけます。「セキュリティ設定」列に「未定義」と表示されている場合、カスタム設定が上書きされている別の領域を示しています。
定義されていない場合は、ポリシーを適用しているGPOを調整する必要があります。ソースGPOを見つけるには、以下の手順に従ってください。
- コマンドプロンプトを管理者として開き、 と入力します
gpresult /H %USERPROFILE%\Desktop\gpreport.html。HTMLレポートを開き、LanManCompatibility設定の近くにあるWinning GPO名を探します。
GPOを特定したら、管理者でない場合はシステム管理者に連絡し、管理者権限を持っている場合はグループポリシー管理コンソール（`gpmc.msc`）にアクセスします。そのGPOを見つけて編集し、 「ネットワークセキュリティ：LAN Manager認証レベル」に適切な値を設定します。
方法2: ローカルセキュリティポリシーにパッチを適用する
マシンのポリシーが問題の原因となっている場合もあります。特に、セキュリティポリシーを管理しているのがドメインGPOだけではない場合はなおさらです。これを確認するには、ローカルセキュリティポリシーエディター（ secpol.msc ）を開いてみてください。
- 「実行」を開き、
secpol.mscと入力して Enter キーを押します。 - [セキュリティ設定] > [ローカル ポリシー] > [セキュリティ オプション]に移動します。
- 「ネットワークセキュリティ：LAN Manager認証レベル」を見つけます。ダブルクリックして、必要なレベルを選択します（例：「NTLMv2応答のみ送信」）。
- [適用]と[OK]をクリックします。
設定後、再起動してください。場合によっては、完全に再起動しないと設定が反映されないことがあります。HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevelその後、レジストリキーを確認してください。選択した値が反映されているはずです。
方法3: コマンドラインを使用してレジストリ値を強制する
ポリシーが混乱している場合や、すぐに修正が必要な場合は、起動スクリプトを作成することで、レジストリキーを強制的に希望の設定に保つことができます。競合の可能性を許容できる場合を除き、本番環境での使用は絶対にお勧めしませんが、回避策としては便利です。
- レジストリを設定するための簡単な PowerShell スクリプトを作成します。
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f「5」を必要なレベル（例：3、4など）に置き換えてください。これをデスクトップにset_lm.ps1として保存します。次に、 gpedit.msc（ローカルグループポリシーエディター）を開きます。
- [コンピューターの構成] > [Windows の設定] > [スクリプト (スタートアップ/シャットダウン)]に移動します。
- 「スタートアップ」をダブルクリックし、「追加」をクリックして、set_lm.ps1スクリプトを参照します。「適用」して閉じます。
これで、マシンが起動するたびに、そのスクリプトが実行され、必要な値が設定されます。GPO によって後で再度上書きされる可能性があるため完璧ではありませんが、一時的に動作するには十分な場合もあります。
方法4：Windows Serverでポリシーの逆戻りに対処する
Windows Server をご利用で、レジストリ値が何度も元に戻ってしまう場合は、Active Directory の GPO が設定を操作している可能性があります。そのため、その GPO を見つけて変更するか、設定を強制的に適用することで解決できますsecedit。
- 実行し
gpresult /H rsop.htmlてドメインからポリシーを検索します。 - 必要に応じて、ドメイン コントローラーまたは管理ワークステーションからグループ ポリシー管理を開き、関連する GPO を見つけて、[コンピューターの構成] > [ポリシー] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [セキュリティ オプション]で設定を変更します。
- で強制的に更新しますgpupdate /force。
または、 を使って現在のセキュリティポリシーをエクスポートしsecedit /export /cfg current.txt、LmCompatibilityLevel行を変更してから、 を使って再インポートしますsecedit /configure。これは少し高度な方法ですが、頑固なドメインポリシーを上書きする必要がある場合があります。
これらの設定が失敗する原因は何ですか?
多くの場合、問題はポリシーの矛盾に帰結します。特にエンタープライズ環境では顕著です。また、一部のセキュリティポリシーやグループポリシーでは、弱い認証プロトコルを明示的にブロックしたり、高い設定を強制したりしています。パスワードの有効期限切れやサービスプリンシパル名（SPN）の不適切な設定がNTLMエラーの原因となる場合もありますが、これは全く別の問題です。
Windows 11のデフォルトの動作
Windows 11では、デフォルトのLmCompatibilityLevelは3です。つまり、NTLMv2を使用し、そのセキュリティレベルを満たす応答のみを送信します。そのため、正常に動作しない場合は、デフォルト設定が問題の一部となっているか、古いポリシーによって低いセキュリティレベルが強制されている可能性があります。
設定の切り替えにイライラしている人のために、この記事が少しでもお役に立てれば幸いです。少し迷路のようですが、少し辛抱すれば大抵は解決できるはずです。
まとめ
- GPOがローカルレジストリの編集を上書きしていないか確認する
- RSOPとgpresultを使用してポリシーを識別する
- GPMCまたはローカルセキュリティ設定を介してポリシーを直接調整する
- 必要に応じて、スタートアップスクリプトまたはsecEditを使用してレジストリ値を強制します。
- 再起動してレジストリキーを確認し、変更が反映されているか確認します。
まとめ
これは必ずしも迅速ではありません。特にポリシーが厳格にロックされている場合はなおさらです。しかし、上書きの原因を突き止め、適切な調整を行うことができれば、設定は最終的に維持されます。ただし、企業環境でローカルセキュリティポリシーやGPOを変更する際は、慎重に、できれば許可を得て行う必要があることを覚えておいてください。幸運を祈ります。そして、この情報が、誰かが設定を元に戻したり、頭を悩ませたりする事態を回避するのに役立つことを祈っています！