Windowsドメイン環境を運用する上で欠かせない認証プロトコルの設定。しかし、CVE-2022-38023をはじめとする最新の脆弱性対策によってNTLMに支障をきたすケースが増えています。本記事では、対処法や影響回避のポイントを詳しく解説します。
Net Logonプロトコル変更とNTLMへの影響
セキュリティ向上のため、MicrosoftはドメインコントローラーのNet LogonプロトコルでRPC署名/暗号化（Signing/Sealing）を強化するパッチを提供しています。特にCVE-2022-38023対策を含むKB5021130の適用後、NTLM認証環境で問題が発生するケースが報告されています。ここでは、その背景と技術的要点を整理し、具体的な対応策を解説します。
変更の背景
Microsoftが実施したNet Logonプロトコルの強化は、リレー攻撃や権限昇格につながる可能性を防ぐ目的があります。従来よりKerberos認証へ移行を促進していた背景に加え、今回のCVE-2022-38023を通じてNet Logon通信のセキュリティを一段と引き上げる必要性が示されました。しかし、この変更はNTLM依存のシステムに影響を与えやすく、特に古いアプリケーションやレガシークライアントを多く抱える環境ではトラブルの要因となっています。
NTLMが影響を受ける理由
NTLMはWindowsドメイン内で従来から使われてきたチャレンジ・レスポンス方式の認証プロトコルです。Kerberosよりも簡素な仕組みである反面、セキュリティ面での弱点や認証リレー攻撃のリスクが指摘されています。Net LogonのRPC署名/暗号化が強制化されると、NTLM認証の動作においても署名や暗号化の設定が原因で通信不整合が発生し、結果的に認証失敗やサービス障害が起こる可能性があります。
NTLM認証利用環境を把握する重要性
NTLMに依存するシステムは意外と多岐にわたります。以下のようなケースが典型的です。
レガシーアプリケーション
古いファイルサーバーや古いバージョンのクライアントOS、あるいは独自にNTLM認証を利用しているアプリケーションが挙げられます。Kerberos対応が不十分であったり、アプリケーション側がNTLM前提で設計されていることがしばしばです。
複数ドメイン環境
親子ドメインやフォレストを跨ぐ環境、あるいは信頼関係を結んでいる異なるドメイン間でNTLM認証が必要となる場合もあります。移行を計画していても、ユーザー移行やアプリケーション更改に時間がかかるためNTLMが現役で使われ続ける事例があります。
サードパーティ製ツールとの連携
外部ベンダー製ツールやデバイスが、ドメイン環境との連携でNTLMを必須としているケースがあります。これらを無理にKerberos化しようとしてもサポートが得られず、互換性問題が発生することがあります。
問題が起きる原因とロールバックのリスク
RPC署名/暗号化の強制化
MicrosoftはNet Logonを介した認証フローの安全性を高めるため、RPC署名/暗号化をデフォルトで強制する方向へ舵を切りました。これに伴い、対応していないクライアントやサーバーは認証に失敗し、ドメインにログオンできない、あるいはアプリケーション起動ができないという不具合が起こり得ます。
パッチロールバックのデメリット
一時的に影響を回避するため、KB5021130や関連セキュリティアップデートをアンインストール（ロールバック）する選択肢はあります。しかし、これによりCVE-2022-38023で改善されるはずの脆弱性が再び残存することになり、攻撃リスクが高まります。また、将来的にパッチが再度強制適用される可能性を考えると、根本的解決にはなりません。
安全性と互換性を両立させるための手順
ここからは、最新のMicrosoftアップデートを継続的に適用しつつ、NTLM利用者への影響を最小化するための具体的な手順をご紹介します。
1. 影響範囲の評価
まずは自社環境でNTLM認証をどこが利用しているのかを正確に洗い出します。例えばActive Directoryの監査ログを分析し、NTLM認証がいつどこから発生しているかを調査します。以下のようなPowerShellスクリプトを使ってイベントログを検索する方法もあります。
# NTLM認証イベント(イベントID: 4776)を抽出する例
Get-WinEvent -FilterHashtable @{
LogName='Security';
Id=4776
} | Select-Object TimeCreated,Messageこの情報を基に、NTLMを使わざるを得ないアプリケーションやレガシーシステムを特定し、優先順位をつけて対応計画を作成します。
2. Microsoftドキュメントの精読
KB5021130やCVE-2022-38023に関する公式ドキュメントを確認し、既知の不具合や推奨されるワークアラウンドを把握します。特定の環境下でのみ発生する不具合や、特定のグループポリシーを調整することで回避できる事例が紹介されていることもあるため、細かい設定を見落とさないようにしましょう。
主な設定項目の例
下表は、RPC署名/暗号化を緩和するときに関係する可能性のある設定例です。実際にはバージョンや環境によって違いがあるため、必ず公式ドキュメントで最新版を確認してください。
| 設定項目 | レジストリパス | データ型 | 既定値 | 推奨値 | 備考 |
|---|---|---|---|---|---|
| RequireStrongKey for NetLogon | HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey | DWORD (32) | 1 | 1 | 0にすると署名/暗号化を求めない運用に戻るが、セキュリティリスク増大 |
| Restrict NTLM: NTLM authentication in this domain | HKLM\SYSTEM\CurrentControlSet\Control\LSA\MSV1_0\RestrictReceivingNTLMTraffic | DWORD (32) | 0 | 2 | 2はNTLM拒否モード。ただし従来のNTLM接続が不可能になる |
| Domain Controller: LDAP server signing requirements | グループポリシー（[Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options]） | Policy | なし | Require Signing | LDAPやNet Logon含む認証フロー全体の通信保護を促進 |
3. ワークアラウンドとグループポリシー設定
NTLMに対する依存度が高い場合、すぐにすべてをKerberosや他の認証方式に切り替えるのは難しいでしょう。そのため、一時的な対応としてグループポリシーやレジストリでRPC署名/暗号化の要求レベルを緩和することが考えられます。しかし、これはセキュリティのレベルを下げるものであることを強く意識しなければなりません。
- ドメインコントローラーだけ緩和する
影響が大きいドメインコントローラーのみ、一時的に設定を緩めてNTLMが通るようにし、それ以外は安全性を確保するという手法があります。ただし、ドメインコントローラーが侵害されると被害が全体に波及するため、追加のネットワーク監視やアクセス制御が不可欠です。 - 特定ユーザーやグループに限定した許可
ワークアラウンドを適用する範囲を最小限にするため、グループポリシーで「このグループのユーザーだけはNTLM利用を認める」などの制限を設ける方法が考えられます。全ドメインに影響しない形で細かく制御し、セグメント化と合わせてリスクを局所化できます。
4. テスト環境での徹底的な検証
本番環境へ変更を適用する前に、ドメインコントローラーのテスト環境を用意し、十分な検証を行います。異なるOSバージョンやアプリケーション、さらには多拠点・多ドメインのシナリオなどを想定して、以下の点を入念にチェックしましょう。
- NTLM認証のテストシナリオ
クライアントからのファイル共有アクセス、プリンターアクセス、SQL Server接続など、NTLMを用いた認証が関係する操作を一通り試してみます。認証が失敗するケースがあれば、どの設定が起因なのかをログで追跡します。 - イベントログ・監査ログの確認
イベントログ（SecurityやSystem）に警告やエラーメッセージが出ていないかを確認します。とくにRPCのセキュリティ強制が影響している場合は、NetlogonサービスやLSA関連のイベントログが手がかりとなります。 - 他のパッチとの競合
Microsoftのセキュリティパッチは複数のコンポーネントに影響を及ぼす場合があります。別のパッチやグループポリシー設定との組み合わせで予期せぬ不具合が発生する可能性があるため、テスト環境で包括的な検証を実施しましょう。
セキュリティ強化とNTLMの共存策
1. 長期的にはKerberosまたは他の認証への移行を検討
NTLMの廃止がMicrosoftの基本方針であることを鑑みると、いずれはKerberosへの移行や認証プロトコルの最新化が必須となります。新たなシステム導入や既存システムのアップグレードのタイミングで、一歩ずつNTLMから離れる計画を立てるのが望ましいでしょう。
2. ネットワークセグメンテーションによるリスク軽減
もしもNTLMの完全廃止が難しい場合でも、NTLMを利用する端末やサーバーを特定のセグメントに隔離し、外部や他のセグメントとの通信を厳格に制御する方法があります。内部脅威やマルウェアの拡散を抑える手段としても有効であり、段階的に新プロトコルへの移行を進めるための安全策にもなります。
3. ログ監視とリアルタイムアラート
NTLM関連のイベントログやドメインコントローラーのログを常時監視し、不審な認証の試行や連続失敗などをトリガーとするリアルタイムアラートを導入しておくと、万一の攻撃や誤設定をいち早く察知できます。特にNTLMリレー攻撃やパスワードスプレー攻撃などが疑われる際の初動対応を迅速化できます。
Microsoftサポートやコミュニティの活用
NTLMとNet Logonの問題は、多くの企業が直面している課題です。Microsoftの公式サポートやTech Community、セキュリティフォーラムなどから最新情報を入手し、自社環境に適用できる回避策や修正パッチをいち早く見つけることが重要です。
- 公式ドキュメント
Microsoft Docsやセキュリティアドバイザリ、ナレッジベース（KB）記事などを定期的にチェックし、更新日や追記情報を逃さないようにします。 - 専門家への問い合わせ
どうしても解決が難しい場合は、Microsoftサポートへ直接問い合わせるのも選択肢です。特定の環境下でしか発生しない問題や、未公開の修正プログラムが存在する場合もあるため、早期解決につながる可能性があります。 - コミュニティリソース
ITエンジニア向けのフォーラムやユーザーグループ、SNSなどを活用して同様の事例や対処法を探すことも有効です。場合によってはPowerShellスクリプトやGPOの事例、実運用でのノウハウが共有されていることがあります。
まとめと今後の展望
CVE-2022-38023によるNet Logonプロトコルの変更がもたらすNTLM認証への影響は、Windowsドメイン環境のセキュリティ強化という大きな流れの一環といえます。短期的に見るとシステムダウンやサービス停止のリスクがあるため、やむを得ずパッチをロールバックする選択をするかもしれません。しかし、中長期的にはNTLM依存度を下げ、Kerberosや他の安全な認証方式への移行を進める必要があります。
パッチの適用とNTLM依存のバランスを取るためには、まず自社環境の利用状況を正確に把握し、影響範囲を明確にすることが不可欠です。その上でMicrosoftのドキュメントを参考に適切なワークアラウンドを実施し、テスト環境で問題を洗い出してから本番適用するのがリスク回避の鉄則です。どうしてもNTLMを残さなければならない場合は、ログ監視やセグメンテーションなどでセキュリティ対策を強化し、将来的な全面移行を見据えた計画を立てていきましょう。
コメント