エグゼクティブサマリー
企業環境からNTLMを排除することは、 重大な課題多くのインフラストラクチャに深く組み込まれており、場合によっては重要なレガシーアプリケーションが依然としてそれに依存しています。これらのアプリケーションを置き換えることは非現実的に思えるかもしれませんが、長年にわたり、これがその理由でした。 NTLM 引き続き使用されていた。 しかし現実は異なる。 ほとんどの組織は実際にはNTLMを必要としておらず、より大きな障害は、内部でのNTLM活動の検出が困難であることだ。 Active Directory環境の規模が大きくなるにつれて、この困難さは増すばかりである。
を考慮して Windows 10 のサポート終了マイクロソフトがNTLMの廃止を発表したことで、この問題が再び浮上しました。組織は、「NTLMなしでどのように運用していくのか」という問いを立て始める必要があります。 認証では、準備のために今、どのような措置を講じるべきでしょうか？
NTLMは必ずしも避けられないものではなく、変更可能です。このガイドでは、NTLMがどのように機能するかを説明します。 Active DirectoryNTLMを段階的に廃止することがなぜ難しいのかを説明し、組織内でNTLMの使用を検出して排除するための実践的な計画を提供します。
パート1：NTLMはどのように機能するのか？
NTLM (NT LAN Manager) は、Microsoft の古い認証プロトコルの 1 つです。元々は初期の Windows ネットワーク向けに構築されました。これは、ユーザーが平文でパスワードを送信することなく本人確認を行えるように設計されており、代わりに チャレンジ・レスポンス・メカニズムこれは1990年代には効果的だったものの、今日の基準からすると時代遅れで安全性が低いと考えられている。
NTLM認証プロセスは、クライアント、サーバー、ドメインコントローラー間の3つのメッセージのやり取りによって行われます。
- NTLM交渉
クライアントは、サーバーに「Negotiate」メッセージを送信することで認証を開始します。このメッセージには、クライアントがサポートするNTLMバージョンなど、クライアントの機能に関する詳細情報が含まれています。
- NTLMチャレンジ
サーバーは、ランダムに生成された16バイトのナンス（チャレンジ）を含む「チャレンジ」メッセージで応答します。これにより、認証試行が単純にリプレイされることを防ぎます。
- NTLM認証
クライアントは、保存されたパスワードハッシュを使用して応答を生成することで、自身の身元を証明します。
- 重要なステップ： クライアントはサーバーの基準に従ってNTLMチャレンジレスポンスを計算します （例：NTLMv1またはNTLMv2）
- NTLMv1では、クライアントはDESを使用してチャレンジを暗号化しますが、DESは脆弱で、総当たり攻撃で簡単に解読されてしまいます。
- NTLMv2では、クライアントはタイムスタンプやクライアントナンスなどの追加データを含めることで、より強力な（ただし完全ではない）応答を生成します。クライアントはこの応答を「認証」メッセージとしてサーバーに返送します。
- 承認または拒否
In Active Directoryサーバーはチャレンジとレスポンスをドメインコントローラーに転送します。ドメインコントローラーは、ユーザーの保存されたパスワードハッシュを検索します。 Active Directoryは、同じ計算を実行し、結果を比較します。結果が一致すれば認証は承認され、一致しなければ拒否されます。
しかし Kerberos は、長らく好ましい認証方法であった Active DirectoryNTLMは依然として広く使用されています。多くの場合、アプリケーションはKerberos認証が失敗した場合にNTLMにフォールバックします。このフォールバック動作は、NTLMの廃止が難しい主な理由の1つです。管理者は、自分の環境でNTLMがまだアクティブになっていることにさえ気づかない可能性があるからです。
パート2：組織におけるNTLMの排除
NTLMの削除は、単なる設定変更ではなく、可視性、計画性、そして慎重な実行を必要とするプロセスです。重要なのは、まずNTLMがまだ使用されている箇所を把握し、段階的に依存度を下げ、最終的に完全に廃止することです。
ステップ1：NTLMを使用するアプリケーションを特定する
見えないものを排除することはできません。最初のステップは 環境全体でNTLMの使用状況を検出する.
NTLMアプリケーションを手動でマッピングするのは容易な作業ではありません。Windowsイベントログ（例えば、イベントID 4624（ログオン成功）と4776（NTLM認証））を精査し、グループポリシーを介してNTLM監査ポリシーを有効にする必要があります。これは可能ですが、時間がかかり、大規模な環境ではさらに複雑になります。
代わりに、現代では アイデンティティセキュリティ この機能を使用すると、環境内のすべてのNTLM使用例を単一のビューにまとめて表示できます。
Silverfort プラットフォームに応じて、環境内でNTLMを使用しているすべてのアプリケーションの包括的なレポートを作成する方法は次のとおりです。
1. 認証ログタブを開きます。
2. NTLMプロトコルフィルタを作成する
- 必要に応じて、追加のフィルター（期間、ユーザー、デバイスなど）を追加してください。
- NTLMv1は、リスク指標を適用することで直接フィルタリングできます。
3. レポートをエクスポートする
- 宛先ごとにデータをグループ化して、どのアプリケーションとサーバーがまだNTLMを使用しているかを特定します。
クライアントがNTLMの計算を担当していることを覚えておくことが重要です。つまり、検出作業はアプリケーションレベルで止まらず、どのクライアントがNTLMにフォールバックしているかを特定する必要があります。NTLMを完全に排除するには、クライアントを継続的に監視し、フォールバックの原因を検出する必要があります。多くの場合、フォールバックはKerberosが確立できないために発生します。たとえば、サービスプリンシパル名（SPN）の設定ミスや、Kerberosが要求するNetBIOSまたはDNSホスト名ではなく、IPアドレスを使用してクライアントがリソースに接続した場合などです。クライアントがNTLMにデフォルト設定されないようにするには、これらの根本原因に対処する必要があります。
Kerberos認証の失敗を調査する際には、ほとんどの場合、Kerberos認証の失敗の直後にNTLM認証が成功することを覚えておいてください。この挙動により、NTLMが環境内で密かに存続しやすくなります。そのため、Kerberos認証の失敗ごとに、サービスプリンシパル名（SPN）の欠落や設定ミス、ホスト名の代わりにIPアドレスを使用していること、その他の実装エラーなど、根本的な原因を特定するために調査を行う必要があります。このような調査を行わないと、NTLMフォールバックが監視されずに継続し、その排除に向けた取り組みが阻害されてしまいます。
Kerberosの障害を調査するには、 Silverfort:
1. 認証ログを開く
2. フィルタを適用：IdP結果：拒否、プロトコル：Kerberos
3.結果を分析します
ステップ2：リスク評価 – NTLMv1 vs NTLMv2
NTLMの使用はすべて同じレベルのリスクを伴うわけではありません。排除計画において重要なのは、NTLMv1とNTLMv2を区別することです。
NTLMv1
NTLMv1はチャレンジ・レスポンスの計算にDESを使用していますが、これは現代の基準からすると非常に脆弱です。攻撃者はレインボーテーブルや最新のGPUベースの総当たり攻撃を用いて、わずか数秒でNTLMv1のレスポンスを解読できます。そのため、NTLMv1はあらゆる環境で直ちにブロックされるべきです。これを容認し続けることは、ユーザー認証情報を不必要に危険にさらすことになります。
NTLMv2
NTLMv2は、HMAC-MD5の導入と認証情報の追加によってセキュリティを向上させています。重要な改善点の1つは、クライアントのタイムスタンプ、ターゲットサーバー名、ターゲット情報などのデータを格納できるAV_PAIRS（属性値ペア）の使用です。これらのフィールドは、応答が特定のサーバーとセッションのコンテキストに関連付けられるため、単純なリプレイ攻撃やリレー攻撃に対する防御に役立ちます。
しかし、保護は完全ではありません。攻撃者がAV_PAIRSを操作または削除できる場合（例えば、ターゲット検証を強制しない構成の場合）、リレー攻撃は依然として可能です。実際には、署名とチャネルバインディングが強制されないシナリオでは、NTLMv2はパスザハッシュ攻撃とNTLMリレー攻撃に対して脆弱なままです。
NTLM排除計画を策定する際には、リスクに基づいて優先順位を付けることが重要です。NTLMv1は、直接的かつ容易に悪用可能な脆弱性を生み出すため、即時のリスクとみなし、遅滞なくブロックする必要があります。 攻撃対象NTLMv2はより強力ではありますが、あくまで一時的な措置として扱うべきです。NTLMv1よりも優れた保護機能を提供しますが、リレー攻撃やハッシュベースの攻撃に対しては依然として脆弱なままです。実際には、まずNTLMv1を排除し、その後NTLMv2を段階的に削減・廃止して、最終的にNTLMを完全に排除していく必要があります。
ステップ3：グループポリシーでNTLMv1をブロックし、その制限事項を理解する
グループポリシーによるNTLMv1のブロックは、あらゆる排除計画において不可欠なステップです。LMCompatibilityLevelポリシー（またはグループポリシーにおける同等のポリシー）を使用すると、ドメインコントローラーがNTLMv1認証を拒否し、NTLMv2のみを受け入れるように構成できます。これは、あらゆるドメインコントローラーに推奨される基本構成です。 Active Directory 環境。
グループポリシーを有効にする方法：
- 店は開いています グループポリシー管理コンソール （GPMC）
- コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → セキュリティ オプションに移動します。
- 設定箇所を特定してください。 ネットワークセキュリティ：LAN Manager認証レベル
- 値を次のように設定します。 NTLMv2応答のみを送信します。LMおよびNTLMを拒否します。
これにより、WindowsシステムはNTLMv2応答のみを生成するように指示され、ドメインコントローラーはNTLMv1認証を拒否することが保証されます。
しかし、この制御だけでは完全に保護されない可能性があることを理解しておくことが重要です。場合によっては、設定が誤っているアプリケーションが、グループポリシーの設定にもかかわらず、NTLMv1認証を強制的に実行してしまうことがあります。これにより、管理者がNTLMv1がブロックされていると誤解するリスクが生じます。実際には、NTLMv1は環境内でアクティブなままなのです。
このようなバイパスがどのように機能し、なぜ発生するのかについての詳細な技術的説明については、私のブログ記事をご覧ください。 NTLMv1バイパス Active Directory – 技術的な詳細分析.
現在の推奨事項は、NTLMv1 を監視して排除し、可能であれば、すべての NTLMv1 認証に対してリスクベースのポリシーを作成することです。 Silverfort.
ステップ4：アプリケーションが他の認証方法をサポートしているかどうかを確認する
NTLMが環境内で依然として使用されている一般的な理由の一つは、特定のアプリケーションがNTLMでしか動作しないという思い込みです。しかし、多くの場合、これは誤りです。アプリケーションがNTLMにフォールバックする原因は、設定ミス、前提条件の不足、あるいは単に管理者がより強力なプロトコルを有効にしていないことなどが考えられます。
アプリケーションを置き換えたり廃止したりする前に、より安全な認証方法を既にサポートしているかどうかを確認してください。
- Kerberos ほとんどの最新のWindowsアプリケーションは、サービスプリンシパル名（SPN）が正しく設定されていれば、Kerberos認証に対応しています。多くのNTLM関連の「依存関係」は、SPNを修正するか、クライアントがIPアドレスではなくDNSホスト名を使用して接続するようにすることで解決できます。
- SAML、OpenID Connect（OIDC）、またはOAuth – Webアプリケーションやクラウド向けサービスは、多くの場合、これらの最新の認証標準をネイティブに、またはIDプロバイダー（IdP）との統合を通じてサポートしています。
- 証明書ベースの認証 ―一部の企業向けアプリケーションでは、スマートカードや証明書に基づくログインが可能であり、NTLM認証が全く不要になる。
応募書類を評価する際：
- 最新バージョンを確認してください ― 最新リリースでは、NTLMへの依存関係が削除されたり、最新の認証プロトコルへの対応が追加されている場合があります。
- 文書を調査する 多くのベンダーはKerberosやフェデレーションIDのサポートを文書化しているが、実際には利用されないことが多い。
- ID構成を確認する 可能な限り、アプリケーションを中央のIDプロバイダーと統合するようにしてください。
その良い例として、公式のmssql-jdbcドライバーを使用してアクセスするMicrosoft SQL Serverが挙げられます。一見すると、多くのデプロイメントはNTLM認証に依存しているように見えます。しかし実際には、ドライバーは完全にサポートしています。 Kerberos認証ただし、サービスプリンシパル名（SPN）が正しく構成され、クライアントがIPアドレスではなくDNSホスト名を使用して接続する場合に限ります。さらに、Microsoftのドキュメントでは、NTLMフォールバックを回避してKerberos用にドライバーを明示的に構成する方法が説明されています。これはNTLMが避けられないケースのように思えますが、ドキュメントを確認し、ID構成を調整することで、管理者はアプリケーションをKerberosに移行し、NTLMの使用を減らすことができます。
加えて、 多要素認証の追加を検討する（MFA) 可能な限り。NTLMまたはKerberosが引き続き使用される場合でも、MFAはリスクを大幅に軽減します。 資格情報の盗難 そして誤用。 Silverfort MFA保護をNTLMやKerberosなどの認証プロトコルに拡張します。これにより、従来型システムと最新システムの両方に、追加の防御層が提供されます。
ステップ5：NTLMベースのアプリケーションをシャットダウンする計画を立てる
NTLMの使用を特定し、NTLMv1をブロックし、可能な場合はより強力な代替手段を有効にしたら、最後のステップは NTLMベースのアプリケーションを完全にシャットダウンする計画を立てるこれが、NTLMがもたらすリスクを完全に排除する唯一の方法です。
この計画には次の内容を含める必要があります。
アップグレード – Kerberosまたは最新の認証規格をサポートする、より新しいバージョンのアプリケーションに移行してください。多くのベンダーは、最近のリリースでNTLMへの依存を解消しています。
リプレイスメント アップグレードが不可能な場合は、自社のアイデンティティ戦略に合致する代替案を検討してください。
廃止 NTLMのみに依存するアプリケーションを廃止するための明確なタイムラインを作成する。
さらに、それを覚えておいてください 顧客はNTLM撲滅において重要な役割を果たすクライアントが NTLM 計算を担当するため、継続的に クライアントがNTLMにフォールバックするかどうかを監視する そしてその理由を特定します。一般的な原因としては、以下のようなものがあります。
ホスト名の代わりにIPアドレスを使用する クライアントがNetBIOSまたはDNSホスト名ではなくIPアドレスで接続する場合、Kerberosは使用できず、NTLMにフォールバックします。
アプリケーションにおける不適切なKerberosの使用 – 一部のアプリケーションは Kerberos を正しく実装できず、代わりに NTLM をデフォルトとして使用します。不適切な使用の好例としては、 KDCスプーフィングの脆弱性が発見されました Silverfort IBM QRadar (CVE-2019-4545) などの複数の製品において、 Cisco ASA (NAIST) と パロアルトネットワークス PAN-OS , Kerberos の処理が不適切だったため、攻撃者は Kerberos を回避して昇格したアクセス権を取得できました (もっとここを読む).
チームと共有できるこれらの手順の簡単なチートシートについては、 こちらをご覧.
これらの問題を検出して対処することは、NTLMが駆除されたと思われた後に、密かに再発するのを防ぐために不可欠です。
Windows 10 のサポート終了 Microsoftの NTLM非推奨化のお知らせ このシャットダウン計画をより広範なIT近代化プロジェクトと連携させる適切な機会を創出しましょう。NTLMの廃止をインフラストラクチャの刷新の一環として捉え、Windows 10のサポートが終了する頃には、環境がNTLMに依存しないようにします。
これらの重要な変更にチームを準備させるには、 オンデマンドのウェビナーをチェックしてください ここでは、NTLM認証を顕在化させる方法と、それを排除するのに役立つ拡張性の高いポリシーを作成する方法について説明します。
