NTLM：なぜ今も残り続けているのか？
NTLMプロトコルは、脆弱性が知られていながらも、いまだにWindowsの環境で使われ続けています。では、なぜこれほどまでに残っているのでしょうか？
NTLMは、古い暗号技術に依存しています。たとえば、サーバーがクライアントに応答する際にはHMAC-MD5という方式を使っています。そして最大の弱点は、ユーザーのパスワードを秘密鍵として使うために、MD4アルゴリズムでハッシュ化している点です。
このMD4はエントロピー（予測のしづらさ）が低いため、攻撃者にとって解析しやすく、セキュリティ面で非常に危険な要素となっています。
これらの脆弱性により、なりすましやアカウント乗っ取りといったリスクが現実のものとなります。NTLMにはパスワードのソルト（salt）処理が存在せず、これがオフラインでのパスワード解析や「パス・ザ・ハッシュ攻撃（Pass-the-Hash）」を可能にしています。さらに近年ではハードウェアの性能が飛躍的に向上しており、一般向けのコンシューマー機器でも、こうしたNTLMの弱点を突くことが現実的になってきました。
NTLMにはもう一つ深刻な欠陥があります。サーバー側の認証機能がないため、リレー攻撃（中間者攻撃）が成立してしまうのです。悪意あるサーバーがクライアントと本来のターゲットサーバーの間に割り込み、たとえ安全と思われる環境であってもセキュリティが破られる可能性があります。.
加えて、NTLMはパスワード認証に強く依存しているため、証明書認証や生体認証、多要素認証（MFA）、FIDOキーといった最新の認証技術との互換性もありません。これは、現代のセキュリティ要件において大きな制約となっています。
Kerberos：セキュリティの守護者
NTLMという迷路のような仕組みの中で、Kerberosは安全な認証の砦として際立った存在です。NTLMとは異なり、Kerberosはセキュリティ性が高く、拡張性にも優れたプロトコルです。
Kerberosは、サーバー側の認証を含む強力かつ柔軟な暗号化技術を用いており、安全な通信を実現します。また、パスワードへの依存から脱却し、さまざまな現代的で柔軟な認証情報に対応できる点も大きな特長です。
しかし、Kerberosにはいくつかの複雑さが伴います。認証には、クライアント、対象サーバー（またはアプリケーションサーバー）、そして中央の認証機関であるKDC（キー配布センター）という3つの役割を持つ要素の関与が必要です。
さらに、クライアントはKDCと常に直接通信できる状態にある必要があり、この要件がKerberosの利用を特定のネットワーク構成に限定する要因となっています。
Kerberosアクセスの簡素化
Microsoftは、Kerberosのアクセスを簡素化する必要性を認識し、その実現に向けて2つの拡張機能を導入しました。1つ目は、IAKERB（Initial and Pass-through Authentication for Kerberos）です。これは、クライアントがアプリケーションサーバーには接続できるが、KDC（キー配布センター）には直接アクセスできないという状況に対応するための仕組みです。IAKERBでは、対象サーバーがプロキシとして機能し、クライアントとKDC間のKerberosメッセージを安全に中継します。この機能は特にリモートワークのような環境において、NTLMへの依存を大幅に軽減する可能性があります。
また、IAKERBは、Microsoftが提案するもう一つの革新的な機能であるローカルKDC（Local Key Distribution Center）の前提にもなっています。ローカルKDCは、簡易的なKDCを各Windowsマシン内に組み込むことで、外部のKDCを必要としません。これにより、ワークグループ環境やピアツーピア構成であっても、クライアントが対象デバイスと直接認証を行えるようになります。
NTLMとKerberosの違いや、Microsoftが提案するIAKERBおよびローカルKDCの概要については、以下の動画でわかりやすく解説されています。実際のデモも含まれており、理解を深めるのに役立ちます。
NTLM使用状況への影響
IAKERBおよびローカルKDCは、NTLMの使用に対して即時かつ大きな影響を与えると見られています。これまでNTLMが必須とされていた状況においても、Kerberosの活用範囲が大きく広がることが期待されています。
しかし、いくつかの条件下ではNTLMにフォールバック（自動切り替え）する可能性があります。たとえば：
- Kerberosは、ターゲットサーバーの識別にIPアドレスを使用しません。そのため、環境によってはKerberosが使えず、NTLMが選択される場合があります。これに対応するために、KerberosでIPアドレスを扱えるようにするポリシー設定が可能です。
- クライアントがターゲットサーバーを認識していない場合や、ターゲットが空（null）の場合には、Kerberosによる認証が成立せず、NTLMが使用されることになります。こうしたケースには、今後のWindowsアップデートで対応予定の新機能によって解決が図られる見込みです。
Microsoftのビジョン：より安全な未来へ
Microsoftは、単にNTLMを置き換えることにとどまらず、セキュリティ全体の強化に取り組んでいます。今後リリースされるWindowsのバージョンでは、システム内でNTLMがどのように使われているかを可視化し、その使用を最小限に抑えるための機能が導入される予定です。
この取り組みは、ユーザー自身がNTLMからの脱却を段階的に進められるよう支援することを目的としています。
Microsoftの最終的な目標は、今後複数のWindowsリリースを通じて、Windows全体のエコシステムからNTLMの使用を完全に排除することです。
Negotiateとのシームレスな統合
ここで重要になるのが、「これらの新しい認証方式へどう移行するか」という点です。
IAKERBおよびローカルKDCは、すでに広く使われているSPNEGO（別名 Negotiate）プロトコルのサブプロトコルとして統合される予定です。SPNEGOは、Microsoftが10年以上にわたって推奨してきた認証方式であり、最新のWindowsデバイスでは標準的に採用されています。
Negotiateにはすでにフォールバック機能が備わっており、新機能が実装されると、Windows環境での標準的なNegotiate認証の流れは次のようになります：
まず Kerberos を試行
次に IAKERB（対象に応じてローカルKDCを含む）を試行
それでも失敗した場合、最後の手段として NTLM を使用
このように、Negotiate経由での認証は、より安全なプロトコルを優先的に使用し、NTLMは極力使われないように構成されています。
実装の簡素化と相互運用性
実装方法は、現在の認証設定に応じて異なりますが、管理および運用のパターンは大きく以下の3つに分類されます：
- SPNEGOを利用している場合 – すでにSPNEGO（Negotiate）を使用して認証を行っている環境では、Microsoftのベストプラクティスに沿って構成されているため、システムアップデート後は追加のインストールや管理作業なしに新機能（IAKERBやローカルKDC）の恩恵を受けることができます。
SPNEGOは、可能な場合は自動的にIAKERBやローカルKDCを活用し、それができない場合はNTLMにフォールバックします。ただし、この際に相互運用性の問題が発生する可能性もあります。 - NTLMをハードコードしている場合 – 明示的に「NTLM」を指定してWindows認証を行っているアプリケーションなどでは、「NTLM」を「Negotiate」に置き換えることで、多くの場合NTLMからNegotiateへの移行が比較的簡単に実現できます。複雑な再構築は不要なケースが多いです。
- Windowsと非Windows環境の相互運用 – Windowsと非Windowsシステムの間で認証連携を行う場合は、より慎重な設計と確認が必要です。IAKERBを利用するには、通信の両端でIAKERBが実装されている、もしくはIAKERBに対応している必要があります。ローカルKDCを利用する場合も同様です。非Windows側でIAKERBをサポートしていない場合は、引き続きNTLMによるフォールバックが可能ですが、NTLMの段階的廃止が進んでいることを踏まえると、より現代的で安全な認証プロトコルへの移行を視野に入れた長期的な計画が推奨されます。
IT管理者のためのきめ細かな管理機能
多くの相互運用の課題は、フォールバック機能によって自動的に緩和されることが期待されていますが、Microsoftはこれに加えて、管理者が移行をきめ細かく制御できるよう、さまざまな管理機能も提供しています。
これらの管理機能には、以下のような項目が含まれます：
- 監査と制御：既存のMicrosoftツールを活用することで、NTLMの使用状況を監査し、一部の制御を行うことが可能です。これにより、NTLMに強く依存しているコンポーネントを特定し、特定のNTLMバージョンの使用を個別に禁止することもできます。
- デバイス単位での設定： IAKERBは、デバイスごとの設定が可能です。これにより、環境全体に対する一括管理も、特定のデバイスに対するきめ細かな調整も行えます。
- サービス単位での設定： IAKERBは、サービス単位での有効化や除外設定にも対応しています。これにより、一部のサービスだけを変更対象から除外する柔軟な運用が可能です。
- レジストリおよびグループポリシーによる制御：IAKERBおよびローカルKDCの全体的な挙動は、レジストリキーやグループポリシーを通じてオン／オフを切り替えることができます。これにより、互換性や相互運用性に関する問題に対処するための準備期間を確保することができます。
NTLMの終焉に向けて
改めて強調すべきなのは、NTLMは最終的に廃止される運命にあるという点です。企業は、単にNTLMを無効化するだけでなく、その先を見据えた計画的な対応が求められます。WindowsにおけるNTLMのサポート終了は避けられない流れであり、組織はそれに備える必要があります。今回紹介したIAKERBやローカルKDCは、この大規模な移行プロジェクトの第一フェーズに過ぎません。Microsoftは、実際の使用データに基づいて戦略とスケジュールを策定しており、顧客やパートナーが段階的に対応できるよう配慮しています。
現在でも、NTLMをWindows環境で無効化することは技術的には可能です。ただし、NTLMは他のプロトコルが使用できない一部の状況で今も必要とされているため、機能停止や不具合を引き起こすリスクがあります。Microsoftは今後、NTLMが依然として必要とされるシナリオについての情報も提供していく予定です。
このように、Microsoftの戦略は複数フェーズに分けた段階的なアプローチとなっており、組織は自分たちのペースで移行を進めることができます。そして、Windowsの今後のバージョンでは、NTLMがデフォルトで無効になることが予定されており、IT管理者はこれを見越して事前に対応を進める必要があります。
現在のフェーズでは、多くのユーザーにとって目立った変化はないかもしれませんが、問題が発生した場合は一時的にNTLMを再有効化することも可能です。ただし、最終フェーズではNTLMが完全にWindowsから削除される予定であり、その時期はMicrosoftによって決定されます。
今こそ、NTLMの扱いについて真剣に向き合い、その確実な終焉に備える時です。
NTLMが沈むとき、より明るく安全な未来が私たちを待っています。
Kerberosの強み
老朽化したNTLMのセキュリティとは対照的に、Kerberosは現代的かつ堅牢な認証プロトコルとして高く評価されています。
Kerberosは、最新のアルゴリズムに基づいた強力な暗号技術を採用しており、通信の安全性をしっかりと確保しています。その大きな特長の一つがサーバー認証で、これによりユーザーは意図した正規のサーバーにのみ接続できるため、リレー攻撃などの悪意ある中間者攻撃を防止することができます。さらにKerberosは、証明書、生体認証、多要素認証（MFA）、FIDOキーなど、多様な認証方式に対応しており、業界全体が進めるより高度で安全な認証への移行とも合致しています。Windowsにおけるセキュリティ強化の一環としてNTLMはその役割を終えつつありますが、Kerberosは今後も進化する脅威に立ち向かう堅牢な認証基盤として残り続けます。
Visuality Systems：信頼できるSMBプロトコルパートナー
セキュリティの重要性がますます高まる今、真に安心できるのはプロトコルだけではなく、信頼できるパートナーの存在です。Visuality Systemsは、セキュアなSMB通信の実現に注力し続けており、皆さまの信頼できるパートナーとして最新かつ安全なSMBプロトコルソリューションを提供しています。
SMBは、Microsoftによって開発されたネットワークファイル共有プロトコルで、ファイルやプリンター、その他のリソースをネットワーク上で共有するために広く使用されています。SMBは複数のトランスポートプロトコル上で動作し、そのセキュリティは使用される認証方式（NTLMやKerberos）と深く関係しています。
ネットワーク上でSMBを通じて共有ファイルなどにアクセスする際、どの認証方式を使用するかによって通信の安全性は大きく左右されます。もしKerberosが使えず、KDC（キー配布センター）への接続経路が確保できないためにNTLMが使用される場合でも、SMBはTLSによる暗号化で一定の保護を提供します。ただし、それでもKerberos認証と比べるとセキュリティレベルは劣ります。
Visuality Systemsは、Microsoftとの戦略的パートナーシップを通じて、セキュアなデジタル未来というビジョンを共有しており、Windowsセキュリティという複雑な領域においても、お客様が安心して前進できるようサポートしています。
Raphael Barki, Head of Marketing, Visuality Systems
