NTLM と Kerberos を理解する：主な違いと活用例

NTLM と Kerberos の概要

共有のために、会社のすべてのリソースをネットワークで接続することには価値があります。しかし、許可されたユーザーやデバイスだけがそれらのリソースにアクセスできることを確認する方法が必要です。認証は、ユーザーやデバイスが自分の身元を証明するための手段を提供することで、この目的を果たします。

Windows 環境では、主に 2 つの認証プロトコルが使用されます。NTLM（New Technology LAN Manager）と Kerberos です。

• NTLM は、古いチャレンジ・レスポンス方式の認証プロトコルであり、レガシー システムやフォールバック（代替）シナリオでもまだ使われています。
• Kerberos は、チケットと暗号化を活用して Active Directory（AD）環境での身元を検証する、より安全で効率的な認証プロトコルです。

この記事では、NTLM と Kerberos の違いを解説し、可能であれば Kerberos を導入することが重要である理由を示します。

NTLM とは何ですか？

NTLM は、ユーザー認証とデータの完全性および機密性を保護するために Microsoft が開発した一連のセキュリティプロトコルです。かつては古い Windows バージョンの既定の認証プロトコルでしたが、現在では作業グループ環境、ローカル アカウント、レガシー アプリケーションなどの限られたシナリオに限定されています。

NTLM 認証は、次のようなチャレンジ応答（challenge response）メカニズムによって機能します。

1. クライアントがユーザー名とパスワードを使ってログオン要求を送信します。
2. サーバーはチャレンジ（16 バイトのランダムな数値）で応答します。
3. クライアントは、ユーザーのハッシュ化されたパスワードを暗号化キーとして使用してチャレンジを暗号化し、それをサーバーに送り返します。
4. サーバーは、Security Account Manager (SAM) データベースに保存されている資格情報と照合して応答を検証します。応答が正しければ、認証が許可されます。

バリアント：NTLMv1 vs NTLMv2

NTLMには2つのバージョンがあります。NTLM v1 はより弱いハッシュアルゴリズムを取り入れているため、セキュリティ侵害に対して脆弱になっています。より単純なチャレンジ-レスポンス方式は パス・ザ・ハッシュ攻撃 とレインボーテーブル攻撃の両方にさらされます。この1993年のプロトコルのもう1つの弱点は、クライアントがサーバーの身元を検証できないため、いわゆる中間者攻撃（man-in-the-middle）が可能になる点です。

NTLMv2 は後に NTLMv1 のアップグレードとして開発されました。より強力な暗号化（56ビットではなく128ビット）を備え、可変長のチャレンジやクライアント側タイムスタンプなど、いくつかのセキュリティ強化機能も追加されています。これらの改善にもかかわらず、Microsoft は NTLM から完全に移行する方針で、2023 年 10 月には NTLMv2 を含むすべての NTLM バージョンを近日中に非推奨（deprecate）にする計画を発表しました。

Kerberosとは何ですか？

Kerberos は、秘密鍵暗号方式によってクライアント・サーバーアプリケーションに強固なセキュリティを提供することを目的としたネットワーク認証プロトコルです。ユーザーのパスワードをネットワーク上に送信するのではなく、有効期限が限られた暗号化チケットを使用します。このプロトコルはドメインコントローラー上で動作し、Windows 2000 以降、Windows ドメインの既定の認証プロトコルとなっています。なお、このプロトコルは、ギリシャ神話における冥界の番犬として三つの頭を持つケルベロス（Cerberus）にちなんで名付けられており、堅牢なセキュリティを提供する役割を表しています。

Kerberos は「Single Sign-On」（SSO）の原則に基づいて動作し、チケット発行システムを用いてユーザーを認証することで、パスワードをネットワーク上に何度も送信することなくリソースにアクセスできるようにします。認証が完了すると、ユーザーはリソースにアクセスしたいたびに、自分に割り当てられたチケットを提示する必要があります。ここでは認証プロセスを示します。

• ユーザーがログインすると、クライアントはドメインコントローラー（DC）上でホストされている Key Distribution Center（KDC）に Authentication Service Request（AS-REQ）を送信します。
• KDC はユーザーの身元を確認し、暗号化された Ticket Granting Ticket（TGT）を含む Authentication Service Response（AS-REP）を返します。
• TGT は KDC の秘密鍵で暗号化され、一定時間のみ有効です（通常は 10 時間）。
• クライアントがサービスにアクセスする必要がある場合、TGT を使って Ticket Granting Service（TGS）からサービスチケットを要求します。
• TGS は特定のサービス向けのチケットを発行し、そのチケットはサービスの秘密鍵で暗号化されます。
• クライアントはこのチケットをサービスに提示して、認証を行いアクセスを得ます

ご覧のとおり、Key Distribution Center（KDC）は Kerberos 認証の仕組みの中で重要な役割を担っています。KDC を、まずあなたの身元を確認し、その後さまざまなリソースにアクセスするために必要な特定の通行証を渡してくれるセキュリティのチェックポイントだと考えてください。

NTLM と Kerberos の主な違い

NTLM と Kerberos はどちらも認証プロトコルですが、セキュリティとパフォーマンスに影響する非常に異なる仕組みとセキュリティ機能を備えています。両者がどのように異なるのか、いくつか見ていきましょう。

認証メカニズム

NTLM は、ユーザーがネットワーク リソースにアクセスするたびにチャレンジ・レスポンス方式でユーザーの身元を確認します。一方 Kerberos は、チケットを使って動作します。いったんログインすると、ユーザーは Ticket Granting Ticket（TGT）を取得します。何かにアクセスする必要があるときは、この TGT を提示してサービス チケットを取得します。そして、そのサービス チケットを使用してパスワードを一度も送ることなくネットワーク リソースにアクセスします。

セキュリティ機能

NTLM は、パスワード ハッシュを保存するために MD4 または MD5 のハッシュ アルゴリズムを使用し、相互認証はサポートしていません（クライアントのみがサーバーに対して認証を行うためです）。このようなセキュリティ機能が不足しているため、NTLM は複数の種類の攻撃に対して脆弱です。Kerberos は、次の仕組みによりはるかに強力なセキュリティを提供します：

• より優れた保護のための AES 暗号化
• クライアントとサーバーの両方が互いを検証する相互認証
• 解読（クラック）試行に耐えるためのパスワード ソルト
• リプレイ攻撃を防ぐ有効期限付きの認証トークン
• パスワードがネットワーク上を通過しないため、pass-the-hash 攻撃を防止

パフォーマンスと効率

セキュリティ上の弱点が多い一方で、NTLM は Kerberos よりも必要リソースが少なくて済みます。初回認証では一般的により高速で、小規模で単純なネットワーク環境では通常、効率も高くなります。より多くのリソースが必要ではあるものの、Kerberos はキャッシュされたチケットを使って後続の認証時間を大幅に節約できるため、大規模で複雑な環境により適しています。

委任となりすまし（impersonation）のサポート

NTLM はインピァーソネーション（impersonation）のみをサポートしており、サーバー プロセスがローカル システム上でクライアントのセキュリティ コンテキストを一時的に引き受けられるようにします。Kerberos は impersonation と認証の委任（delegation）の両方をサポートします。委任（delegation）により、サービスはドメイン ユーザーに代わって他のサービスへアクセスできます。

Windows 環境での互換性と実装

Kerberos は、現代の Windows Active Directory ドメインにおけるデフォルトの認証プロトコルであることを理解しておきましょう。Microsoft は、現在は Kerberos が利用できない場合に限って制限的に使われている NTLM を、Kerberos に完全に置き換える意図を持っています。

セキュリティ上の影響

NTLM の脆弱性

NTLM の脆弱性について、そしてなぜその利用は大きく制限すべきなのかを、もう少し詳しく掘り下げてみましょう。

• NTLM はパス・ザ・ハッシュ（pass-the-hash）攻撃に対して脆弱です。攻撃者はキャプチャしたパスワードハッシュを使って実際のパスワードを知らなくても認証できます。
• NTLM、特に NTLMv1 は MD4 ハッシュアルゴリズムを使用しています。MD4 は弱いと考えられており、レインボーテーブル攻撃に対して脆弱です。この弱さにより、攻撃者がパスワードハッシュを解読し、未授权アクセスを得ることが容易になります。
• NTLM のチャレンジ・レスポンス（challenge-response）プロセスは予測可能なため、署名や暗号化などの追加のセキュリティ対策が実装されていない場合、リプレイ攻撃（replay attacks）に対して脆弱になります。

Kerberos がより安全な理由

Kerberos は、前身の課題を補う強化されたセキュリティ機能を備えた、より現代的な認証プロトコルです。その機能の一部は次のとおりです。

• チケットベース認証により、ネットワーク上でパスワードを送信する必要がなくなり、パスワードの傍受リスクが低減されます。
• AES 暗号化などの高度な暗号化により、ブルートフォース攻撃のような未授权アクセス試行に対する全体的な耐性が向上します
• 多要素認証（MFA）サポートにより、Kerberos がスマートカードや生体認証などの追加認証要素を使用できるようになり、パスワードだけに頼る場合よりもさらにもう一段階のセキュリティ層を追加します

以下は、NTLM と Kerberos の違いをまとめたチャートです。

NTLM と Kerberos を使い分けるタイミング

Kerberos は推奨される認証方式ですが、いくつかのシナリオでは依然として NTLM が必要になります。たとえば、サーバーがドメイン コントローラーとの接続を失った場合は、ローカル ログオン認証が必要になります。中央集約型のドメイン コントローラーがない小規模オフィスやホームオフィス環境では、スタンドアロン マシン上での基本的なアカウント セキュリティのために NTLM にも依存します。多くのレガシー アプリケーションは、現在も NTLM 認証に依存しています。NTLM は、例外的な状況におけるフォールバック（代替）オプションだと考えてください。Windows Active Directory 環境で作業している場合は、可能な限り NTLM の使用を避け、Kerberos 認証を強制して、セキュリティを向上させ、委任をサポートし、サービス間でシームレスな認証を可能にするべきです。

使用中のプロトコルを特定する

Windows イベント ビューアー（Event Viewer）は、個々のサーバーやドメイン環境における認証アクティビティを調査するための定番ツールです。認証の種類を判断するには、「セキュリティ（Security）」のイベント ログを確認してください。各イベントには一意のイベント ID があります。たとえばイベント ID 4776 は NTLM 認証を示します。このイベント ログの項目には、使用されたアカウントや認証元など、認証の試行に関する詳細が記載されます。下のスクリーンショットは、スタンドアロン マシンのローカル Administrator アカウントに対する NTLM 認証のイベント ID 4776 を示しています。

ドメイン コントローラーでは、Kerberos を示すイベント ID 4768 を探せます。下のスクリーンショットは、ドメイン コントローラーでの例です。

コマンド プロンプトを開いて「klist」と入力することもできます。これにより、Kerberos のチケットが存在するかどうかが表示されます。存在する場合は、下に示すとおり Kerberos が使用されていることが分かります。

Wireshark のようなパケット解析ツールを使って、ネットワーク トラフィックをキャプチャして分析することもできます。Kerberos のトラフィックは通常ポート 88 を使用し、NTLM は一般的に NetBIOS ポートを使用します。

NTLM から Kerberos への移行

Windows マシンで NTLM を無効化するとセキュリティが向上しますが、業務に支障をきたさないと完全に確信できる場合にのみ、その手順を実行してください。前のセクションで説明したとおり、イベント ビューアーを使用して、NTLM がどのように使われているかを確認します。少なくとも一部のマシンで NTLM が不要だと確信できる場合は、無効化の手順を開始できます。

Group Policy Management コンソールを開き、次の場所に移動します。コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定 > ローカル ポリシー > セキュリティ オプション。次に、以下のポリシーを変更します：

• ネットワーク セキュリティ：NTLM を制限：受信する NTLM トラフィック > 下のスクリーンショットのとおり「すべてのアカウントを拒否」に設定します。

これは大きなステップなので、下のポップアップ ウィンドウに示すように、Windows が意図を確認するよう求めます:

さらに、もう 2 つのポリシーも設定する必要があります。

• ネットワーク セキュリティ：Restrict NTLM：このドメインでの NTLM 認証 >［すべてのアカウントを拒否］に設定。
• ネットワーク セキュリティ：LAN Manager 認証レベル >［NTLMv2 応答のみ送信］に設定。以下のスクリーンショットに示すように LM & NTLM を拒否します:

最初はテスト環境、または本番環境以外でポリシーを展開し、厳密にテストしてください。ポリシーをすべてのコンピューターに一度に展開しないでください。業務の中断がないことを確認するため、展開を段階的に段取りよく行ってください。イベント ログを必ず監視してください。

移行におけるよくある課題への対処

Kerberos に対応していない可能性のあるレガシー アプリケーションがあるかもしれません。Kerberos の互換性を可能にする更新があるかどうか調査してください。アプリケーションがどうしても NTLM を使用する必要がある場合は、その NTLM アクセスを特定のアカウントまたはホストに限定します。

Kerberos 認証には、正確な DNS 解決と、ネットワーク全体での時刻同期が必要です。すべてのドメイン コントローラー、クライアント、およびサービスが、適切な DNS 設定と NTP による時刻同期で構成されていることを確認してください。また、認証プロセスの変更点、特に Single Sign-On (SSO) 機能に関して、ユーザーに対して教育が必要になる場合があります。

認証プロトコルを保護するためのベストプラクティス

• NTLM の使用を本当に必要な場合に限定する
• 異常な認証パターンやログイン失敗の試行がないか、ログを継続的に監視し、Windows Event Viewer のようなツールを使って、認証に関連する Event ID を追跡してください
• 脆弱性を軽減するために、認証プロセスに関与するすべてのシステムへ、定期的にセキュリティパッチとアップデートを適用してください。
• セキュリティ評価を実行して Kerberos の強制適用ポリシーを検証し、承認されていない NTLM の使用を検出してください。
• 複雑な パスワードポリシー を導入し、それを多要素認証で補完することでアカウントのセキュリティを強化してください。
• サービスプリンシパル名（SPN）を定期的に監査する

実世界でのユースケースと例

企業が拡大し、複雑性が高まっていく中で、Kerberos もそれに合わせてスケールできるよう設計されています。ユーザーは Single Sign-On（SSO）の恩恵を受け、1 回の認証で複数のサービスにアクセス可能です。このプロトコルは相互認証を提供し、クライアントとサーバーの両方が互いの身元を検証します。また、チケットベースの仕組みにより、資格情報の直接送信を防ぎます。このアプローチはセキュリティを強化するだけでなく、サービス委任もサポートし、複雑な多層アプリケーションがユーザーに代わってリソースに安全にアクセスできるようにします。

Kerberos とハイブリッド環境

Microsoft は、ハイブリッド ネットワーク アーキテクチャが増えているという傾向を認めており、オンプレミスとクラウド基盤にまたがる、より柔軟で複雑なネットワーク環境をサポートするために Kerberos を適応させています。クラウドベースの SSO ソリューションを導入する組織では、Kerberos を最新の認証プロトコルと併用することで、オンプレミスとクラウドの両方のリソースにシームレスにアクセスできます。別の例として、Windows Hello for Business では、ハイブリッド デバイスの構成を必要とせず、クラウドに参加したワークステーションから Kerberos 認証を使用してオンプレミス リソースにアクセスできるようにしています。

レガシー アプリケーション

Kerberos が広く採用される前に開発されたレガシーアプリケーションは、いまでも存在しており、そのため NTLM が必要になります。これらのアプリケーションでは、最新の Kerberos 認証を自社（自分自身）では完全にサポートできない Windows 2003 または 2008 サーバー上で実行することを検討してください。レガシーアプリの例には次のようなものがあります:

• 一部のエンタープライズ向けリソース管理（ERP）や人事アプリケーション（特に 2000 年代以前に開発された場合）
• NTLM をデフォルトにする、古いバージョンの IIS または SMB 上で動作するレガシーの Windows ベースのファイルサーバーやイントラネットポータル。
• Kerberos の委任 Kerberos delegation

結論

IT ソリューションを選定する際には、セキュリティを最優先の検討事項とすべきです。Kerberos と NTLM のどちらを選ぶかという観点では、Kerberos が明らかに優れた選択肢です。とはいえ、NTLM が必要になる可能性のある具体的なシナリオを理解しておくことは、包括的なネットワーク管理のために重要です。

よくある質問（FAQs）

NTLM と Kerberos の違いは何ですか？

NTLM と Kerberos はどちらも Windows の認証プロトコルですが、大きな違いがあります。NTLM は、クライアントがパスワードのハッシュを使ってサーバーに対して身元を証明する、単純なチャレンジ・レスポンス方式を採用しています。相互認証がなく、さまざまな種類の攻撃に対して脆弱です。これに対して Kerberos は、相互認証を可能にする、より高度なチケットベースの仕組みです。強力な AES 暗号化を使用し、シングルサインオン（SSO）機能を提供し、パスワードがネットワーク全体に送信されることを防止します。NTLM はレガシー システムでも引き続きサポートされていますが、セキュリティ機能とパフォーマンスに優れるため、Kerberos は現代の Windows Active Directory ドメインで標準の認証プロトコルになっています。

Microsoft はなぜ NTLM から Kerberos に切り替えたのですか？

Microsoft は、より強力なセキュリティ、優れたスケーラビリティ、そして現代のエンタープライズ環境における効率性の向上が必要だったため、NTLM から Kerberos へ移行しました。NTLM のチャレンジ・レスポンス方式は、パス・ザ・ハッシュ（pass-the-hash）やリレー攻撃（relay attacks）といった攻撃に対して脆弱でした。一方、Kerberos はより強力な暗号化、相互認証、チケットベースの認証を導入し、セキュリティ上のリスクを低減するとともにパフォーマンスを向上させました。さらに Kerberos は、委任（delegation）、シングル サインオン（Single Sign-On, SSO）、多要素認証（Multi-Factor Authentication, MFA）との統合といった高度な機能にも対応しており、NTLM にはそれがありません。これにより、Kerberos は今日のモダナイズされたハイブリッド ネットワークにより適しています。

NTLM はもう使われていませんか？

現在では NTLM の使用は強く推奨されませんが、次のような限られたシナリオでは必要になる場合があります。

• 古い Windows ワークグループ環境
• Kerberos をサポートしないレガシー アプリケーション
• ローカルマシンの認証
• Kerberos 認証が失敗した場合のフォールバック認証
• スタンドアロンのマシン

NTLM はローカル認証に使用されますか？

次のシナリオでは、NTLM はローカルの Windows マシン ログオンの主要な認証プロトコルのままです:

1. ローカル マシン ログオン：ドメイン コントローラーのないワークグループ環境、またはスタンドアロンの Windows システムでは、NTLM は引き続き主要な認証プロトコルです。
2. ワークグループ環境：ドメイン構造が導入されていない小規模ネットワークや在宅オフィスでは、NTLM によりマシン間のピアツーピア認証が可能になります。
3. 最小権限のシナリオ：組織はしばしば、NTLM で認証されるローカル アカウントを使用して 最小権限の原則を実装します。このアプローチでは、アカウントのアクセス権をローカル マシンのみに制限することで、侵害されたアカウントが及ぼし得る影響を抑えます。

フォールバック認証：ドメイン環境では、Kerberos 認証が失敗した場合に NTLM がフォールバック手段として機能し、リソースへのアクセスを継続できるようにします。