Microsoftの認証プロトコル比較｜Kerberos・NTLM・OAuth・OIDC・SAMLを整理する

「認証ってパスワードを確認するやつでしょ？」——こう思っていると、Pass-the-Hash攻撃やKerberoastingの話を聞いても「よくわからない」で終わってしまいます。

認証の仕組みはプロトコルによって大きく異なり、攻撃者はそのプロトコルの弱点を突いてきます。設定画面でポチポチするだけでは対処できない攻撃が、プロトコルレベルで発生しているのが現実です。

この記事では、Microsoft環境で使われる5つの認証プロトコル（Kerberos・NTLM・OAuth・OIDC・SAML）の仕組みと使い分けを整理します。

なぜ認証プロトコルを知っておく必要があるのか

認証プロトコルとは「クライアントとサーバーが『あなたは誰ですか』を確認し合う手順」のことです。プロトコルによって認証の仕組みが異なり、得意な用途・弱点・攻撃されやすいポイントが変わります。

現場でプロトコルの知識が必要になる場面は主に以下の3つです。

認証と認可の基本的な違いについては「IAMとは？」で解説しています。

オンプレAD環境で使われる2つのプロトコル

Kerberosとは——チケットで認証する仕組み

Kerberos（ケルベロス） Active Directory環境で標準的に使われる認証プロトコル。パスワードを直接ネットワークに流さず「チケット」を使って認証する。Windows 2000以降のAD環境でデフォルトで使用される。

Kerberosの認証フローは「チケット発行センター（KDC）」を中心に動きます。

【Kerberos認証の流れ】

① クライアント → KDC（DC）：
   「ログインしたい」とTGT（チケット交付チケット）を要求

② KDC → クライアント：
   TGTを発行（有効期間：デフォルト10時間）

③ クライアント → KDC：
   「サービスAにアクセスしたい」とサービスチケットを要求

④ KDC → クライアント：
   サービスチケットを発行

⑤ クライアント → サービスA：
   サービスチケットを提示してアクセス

KDC（Key Distribution Center） Kerberosにおけるチケット発行機関。Active DirectoryではドメインコントローラーがKDCの役割を担う。

Kerberosが使われる条件：同一ADドメイン内・DNSで名前解決できる・ポート88が通信できる状態が揃っているときに使われます。

NTLMとは——チャレンジ・レスポンスで認証する古い仕組み

NTLM（NT LAN Manager） Kerberos以前から存在するMicrosoft独自の認証プロトコル。パスワードのハッシュ値を使ったチャレンジ・レスポンス方式で認証する。現在も後方互換性のために残されている。

NTLMはKerberosが使えない状況で自動的にフォールバックします。

NTLMが使われる主な状況：

KerberosとNTLMの使い分けと共存

現在のAD環境ではKerberosが優先されますが、NTLMは完全には排除できていないケースが多いです。NTLMを完全無効化するとレガシーシステムやアプリケーションが認証できなくなるリスクがあるためです。

ADの認証基盤全体については「Active Directoryとは？」を参照してください。

クラウド・モダン認証で使われる3つのプロトコル

OAuthとは——「認可」を委譲する仕組み

OAuth 2.0（オーオース） あるサービスが別のサービスのリソースへのアクセス権を、ユーザーの代わりに取得するための「認可」フレームワーク。認証ではなく「何ができるか（権限）」を委譲する仕組み。

OAuthでよく使われる例が「Googleアカウントでログイン」です。厳密には「Googleが持つあなたの情報へのアクセス権を、アプリに委譲する」という認可の仕組みです。

重要な注意点：OAuthは「認可（何ができるか）」のプロトコルであり、「認証（誰であるか）」のプロトコルではありません。OAuthだけでは「このユーザーが誰か」を確認する仕組みが含まれていません。

OIDCとは——OAuthの上に「認証」を乗せた仕組み

OIDC（OpenID Connect：オープンIDコネクト） OAuth 2.0を拡張して「認証」機能を追加したプロトコル。IDトークン（JWT）を使ってユーザーのIDを証明する。Entra IDのモダン認証やシングルサインオンで広く使われる。

OIDCはOAuth 2.0に「IDトークン」を追加することで、「このユーザーは誰か」という認証情報も扱えるようにしました。Microsoft Entra IDの認証はOIDCベースで動いています。

【OIDCの認証フロー（簡略版）】

① ユーザー → アプリ：ログインを要求
② アプリ → Entra ID：認証を依頼
③ ユーザー → Entra ID：ID・パスワード・MFAで認証
④ Entra ID → アプリ：IDトークン＋アクセストークンを発行
⑤ アプリ：IDトークンを検証して「このユーザーは〇〇さん」と確認

条件付きアクセスはこのOIDCの認証フローの中で「アクセストークンを発行するかどうか」を制御しています。詳しくは「条件付きアクセスの設計パターン」を参照してください。

SAMLとは——エンタープライズSSOで使われるXMLベースの認証

SAML（Security Assertion Markup Language：サムル） エンタープライズ向けのシングルサインオン（SSO）で使われるXMLベースの認証・認可プロトコル。IdP（IDプロバイダー）とSP（サービスプロバイダー）の間でアサーションを交換して認証する。

SAMLはOIDCより古いプロトコルですが、エンタープライズのSSOでは現在も広く使われています。Microsoft 365・Salesforce・各種SaaSアプリケーションとEntra IDを連携する際にSAMLが使われることが多いです。

【SAMLのSSOフロー（簡略版）】

① ユーザー → SP（Salesforceなど）：アクセスを要求
② SP → ユーザー：IdP（Entra ID）へのリダイレクト
③ ユーザー → IdP（Entra ID）：認証（ID・パスワード・MFA）
④ IdP → SP：SAMLアサーション（XML形式の認証情報）を送信
⑤ SP：SAMLアサーションを検証してアクセスを許可

SAMLアサーション IdPがSPに対して発行する「このユーザーは認証済みで、これらの属性を持つ」という証明書類。XML形式で記述され、デジタル署名で改ざんを防ぐ。

オンプレADとEntra IDのハイブリッド構成でのSAML連携については「Entra IDとオンプレAD連携」で詳しく解説しています。

5つのプロトコルを一覧で比較する

攻撃者はプロトコルの弱点を狙う——知っておくべきリスク

NTLMの弱点——Pass-the-HashとNTLMリレー攻撃

NTLMはパスワードのハッシュ値を使って認証するため、ハッシュ値を盗まれると実際のパスワードを知らなくてもなりすましが可能です。

Pass-the-Hash：攻撃者がメモリからNTLMハッシュを盗み、そのハッシュをそのまま使って別のサーバーに認証する攻撃です。

NTLMリレー攻撃：中間者攻撃の一種。クライアントからのNTLM認証リクエストを攻撃者がキャプチャし、別のサーバーへ転送して認証を成功させます。

対策：NTLMの無効化（影響範囲を確認してから段階的に）・SMB署名の有効化・Protected Usersセキュリティグループへの追加

Kerberosの弱点——KerberoastingとGolden Ticket

Kerberoasting：サービスアカウントのSPNに対してサービスチケットを要求し、オフラインでブルートフォースしてパスワードを解読する攻撃です。

Golden Ticket攻撃：KDCの秘密鍵（krbtgtアカウントのハッシュ）を盗み、任意のユーザーになりすましたTGTを偽造する攻撃です。ドメイン全体が完全に侵害された状態になります。

対策：サービスアカウントに長いランダムパスワードを設定・krbtgtアカウントの定期的なパスワードリセット・特権アカウントのProtected Users追加

AD攻撃手法の詳細と対策については「AD攻撃手法と要塞化」で詳しく解説しています。

よくある失敗パターン——プロトコルの理解不足が招くリスク

① NTLMを無効化したらサービスが止まった

「NTLMは古くて危険だから無効化しよう」と一斉に無効化した結果、NTLMに依存していたレガシーアプリや印刷サーバーが認証できなくなったケースです。無効化前に必ずNTLMの使用状況をイベントログ（イベントID 4776）で調査し、影響範囲を把握してから段階的に進めてください。

② OAuthのスコープを広く設定しすぎた

アプリにOAuthで権限を付与する際、「とりあえず広めに設定した」結果、アプリが必要以上のリソースにアクセスできる状態になったケースです。OAuthのスコープは最小権限の原則に従い、必要な権限のみに絞ってください。

③ SAMLとOIDCを混同して連携が失敗した

SaaSアプリとEntra IDを連携しようとして、アプリがSAML対応なのにOIDC設定をしてしまい認証が失敗するケースです。アプリの対応プロトコルを事前に確認してから設定してください。多くのSaaSはSAMLとOIDCの両方に対応していますが、設定方法が異なります。

④ Kerberosのチケット有効期限を延ばしすぎた

「ユーザーから『頻繁に再認証を求められる』というクレームがある」という理由でチケット有効期限を大幅に延ばした結果、侵害されたチケットが長時間悪用されるリスクが高まったケースです。デフォルトの10時間から大幅に変更する場合は、セキュリティリスクを十分に検討してください。

実務チェックリスト——認証プロトコル設計の確認ポイント

オンプレAD環境

• [ ] Kerberos認証が正常に動作しているか（イベントID 4768・4769）
• [ ] NTLMの使用状況をイベントログで把握しているか
• [ ] NTLMを使用しているレガシーシステムの一覧があるか
• [ ] サービスアカウントのSPNが適切に設定されているか（Kerberoasting対策）
• [ ] krbtgtアカウントのパスワードを定期的にリセットしているか

クラウド・ハイブリッド環境

• [ ] Entra IDのSSOにOIDC/SAMLを適切に使い分けているか
• [ ] OAuthのスコープが最小権限になっているか
• [ ] SAMLアサーションの署名検証が有効になっているか
• [ ] MFAがすべての認証フローに適用されているか

MFAの設定については「MFAとは？」を参照してください。

まとめ——今日確認すべきことは1つです

今日やることは1つだけです。自社のAD環境でNTLMが使われている状況を確認してください。

ドメインコントローラーのセキュリティログでイベントID 4776（NTLMによる認証）の発生頻度を確認し、どのシステムがNTLMを使っているかを把握することが第一歩です。NTLMの使用状況を知ることで、Pass-the-Hash攻撃への対策優先度が明確になります。

あわせてご覧ください

• IAMとは？認証と認可の違いから学ぶアクセス管理の基本
• Active Directoryとは？Windows認証基盤の仕組みと設計の基本
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点
• 条件付きアクセスの設計パターン｜ゼロトラスト実装の実務ガイド
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド