【特別付録・第1回】LinuxエンジニアのためのM365認証の基礎：ゼロから解き明かすフェデレーションの真髄

本編「LinuxエンジニアのためのM365ハイブリッド認証アーキテクチャ」全8回を通じて、Windows Server 2025をベースとしたADDS/ADFSの構築から、LVSによる高可用性ロードバランシング、Entra ID Connectによるプロビジョニング、そしてゼロトラストとMFAの統合まで、エンタープライズの現場で通用する実践的なインフラ構築手法を解説してきました。

しかし、実際の運用現場において「そもそもなぜSAMLやOAuthといったプロトコルが必要なのか？」「なぜ社内のADDSだけではM365にログインできないのか？」という、プロトコルレベルの根源的な疑問に直面するエンジニアは少なくありません。
そこで今回は【特別付録・第1回】として、設定手順から一歩退き、M365認証の根底に流れる「モダン認証プロトコル（SAML / OAuth 2.0 / OpenID Connect）」と「フェデレーション（信頼関係）」の基礎理論を、Linuxエンジニアの視点から徹底的に解剖します。

---

1. 認証 (Authentication) と認可 (Authorization) の分離

M365の認証基盤を理解する上で、最も重要かつ最初に理解しなければならないのが、「認証（Authentication）」と「認可（Authorization）」という2つの概念の明確な分離です。日常会話では同じように使われがちですが、インフラセキュリティの世界では全く異なるプロセスを指します。

認証 (Authentication = AuthN)

認証とは、「あなたは誰ですか？（Who are you?）」という問いに対する答えをシステムに証明するプロセスです。
LinuxにSSHログインする際のパスワード入力や公開鍵の提示、あるいはスマートフォンの顔認証などがこれに当たります。「ユーザー名＝kou-kun」と「秘密の情報（パスワード）」を照合し、本人であることを確定させます。M365ハイブリッド環境においては、ADFS（Active Directory Federation Services）がこの「認証」の主役を担います。

認可 (Authorization = AuthZ)

認可とは、「あなたは何ができますか？（What can you do?）」という問いに対するシステム側のアクセス制御プロセスです。
認証が成功して「kou-kun」であることが確定した後に、そのユーザーが「Exchange Onlineのメールボックスを読み取れるか」「Teamsで外部ゲストを招待できるか」「Linuxサーバーの /var/log ディレクトリに読み取り権限（r）があるか」を判定します。M365環境においては、Entra ID（および各M365アプリケーション）がこの「認可」の主役となります。

この「AuthN」と「AuthZ」を分離し、別々のシステム（オンプレミスのADFSとクラウドのEntra ID）で分担して処理するアーキテクチャこそが、セキュアなエンタープライズITの基本構造なのです。

2. レガシー認証プロトコルの限界（LDAP / Kerberos / NTLM）

Linuxエンジニアであれば、社内の認証基盤としてLDAPサーバー（OpenLDAPなど）やKerberosを構築した経験があるでしょう。WindowsのActive Directory（ADDS）も、内部的にはこれらのプロトコルを使用しています。しかし、これらは「社内LAN（閉域網）」で使われることを前提としたレガシー認証プロトコルであり、クラウドサービス（M365）では直接利用できません。その理由を技術的に紐解きます。

なぜLDAPやKerberosはクラウドで使えないのか？

1. ネットワークポートとファイアウォールの問題：
   LDAPはTCP 389（または636）、KerberosはTCP/UDP 88を使用します。インターネット越しにこれらのポートを開放することは、セキュリティ上自殺行為に等しく、エンタープライズのファイアウォールを通過することはできません。Webの世界は TCP 443 (HTTPS) で通信が完結する必要があります。
2. ステートフル vs ステートレス：
   KerberosはクライアントとKDC（ドメインコントローラー）間で密接なセッションを確立し、厳密な時刻同期（5分以内）を要求します。しかし、HTTPプロトコルは基本的に「ステートレス（状態を持たない）」であり、世界中のどこから、どのタイミングでアクセスしてくるか分からないクラウドサービスとは相性が最悪です。
3. パスワードの直接送信リスク：
   LDAPによるバインド（認証）では、ユーザーのパスワードをシステム（M365）側に送信して照合させる必要があります。ゼロトラストの観点から、「社外のクラウドサービスに、社内の生パスワードを絶対に送信したくない」というセキュリティ要件を満たせません。

これらの限界を打破し、インターネットの標準プロトコルであるHTTP(S)の上で、パスワードをクラウドに渡すことなく安全に認証・認可を行うために生まれたのが、モダン認証プロトコル（SAML、OAuth、OIDC）なのです。

3. モダン認証プロトコル徹底解剖①：SAML 2.0の仕組み

エンタープライズのSSO（シングルサインオン）において、現在最も広く普及しているのが SAML 2.0（Security Assertion Markup Language） です。M365とオンプレミスADFSのフェデレーション連携でも、標準でこのSAML（またはWS-Federation）が使用されます。

SAMLの登場人物

SAMLの世界には、3つの明確な役割（エンティティ）が存在します。

• ユーザー（Principal）： ブラウザを操作してサービスにアクセスしたい人間。
• SP（Service Provider：サービスプロバイダー）： ユーザーが利用したいサービス。M365（Entra ID）、Salesforce、あるいは社内のLinux上のGitLabなどが該当します。
• IdP（Identity Provider：アイデンティティプロバイダー）： ユーザーの身元を確認し、「この人は確かに〇〇さんです」という証明書（トークン）を発行する信頼された機関。ハイブリッド環境における ADFS がこれに該当します。

SAML認証フロー（SP-Initiated）のパケットシーケンス

ユーザーがM365にログインする際の、SAMLプロトコルの動き（SP起点のフロー）を追ってみましょう。

1. アクセス要求： ユーザーのブラウザがSP（M365のログイン画面 login.microsoftonline.com）にアクセスします。
2. SAML AuthnRequestの生成とリダイレクト： SPは「誰か分からないので、IdPで認証してきてください」という要求（SAML AuthnRequest）を生成し、ブラウザに対してIdP（ADFSの公開URL sts.linuxkoubou.local）へのHTTP 302リダイレクトを指示します。
3. IdPでの認証： ブラウザはIdP（ADFS）にアクセスします。ADFSはログインフォームを表示し、社内ADDSに問い合わせてパスワード認証（またはMFA）を行います。※この時、パスワードは社内のADFSで完結し、SP（M365）には一切送られません。
4. SAMLアサーション（SAMLResponse）の発行： 認証が成功すると、ADFSは「このユーザーは kou-kun@linuxkoubou.local です」という情報（クレーム）をXML形式で記述し、ADFSの秘密鍵でデジタル署名を付与した「SAMLトークン」を生成します。
5. 自動POSTによるトークン提出： ADFSはブラウザに対し、このSAMLトークンをSP（Entra IDのエンドポイント）へ自動的にHTTP POSTで送信（サブミット）させます。
6. 署名の検証とログイン完了： SP（Entra ID）は受け取ったSAMLトークンのデジタル署名を、事前に共有されているADFSの公開鍵で検証します。改ざんがなければ、トークン内のユーザー情報を信用し、M365のセッションを発行します。

4. モダン認証プロトコル徹底解剖②：OAuth 2.0 と OpenID Connect (OIDC)

SAMLはエンタープライズのWebブラウザSSOとして強力ですが、XMLベースであるためペイロードが重く、モバイルアプリやAPI間通信（SPA：Single Page Application）には不向きでした。そこで台頭してきたのが、OAuth 2.0 と OpenID Connect (OIDC) です。

OAuth 2.0（認可のためのプロトコル）

誤解されがちですが、OAuth 2.0 は「認証（AuthN）」のプロトコルではなく、「認可（AuthZ）」のプロトコルです。パスワードを渡すことなく、あるアプリケーションが別のアプリケーションのデータにアクセスする「権限」を委譲する仕組みです。
例えば、「Linux工房のポータルアプリ（クライアント）」が、ユーザーに代わって「M365のOutlook（リソースサーバー）」からメールを読み取る権限を得るために使われます。
この時発行されるのが アクセストークン（Access Token） です。アクセストークンは「〇〇の操作を許可する」というチケットに過ぎず、「ユーザーが誰であるか」を証明する機能はありません。

OpenID Connect (OIDC)（認証のためのプロトコル）

OAuth 2.0のアクセストークンだけでは、「ユーザーが誰か」が分かりません。そこで、OAuth 2.0の拡張仕様として作られたのが OpenID Connect (OIDC) です。現在、M365の最新のアプリケーションや、AWS、Google CloudへのSSOなどでは、SAMLに代わってOIDCが主流になりつつあります。

OIDCでは、アクセストークンに加えて IDトークン（ID Token） が発行されます。このIDトークンの実体は、XMLではなく JWT（JSON Web Token：ジョット） という非常に軽量なフォーマットです。

# JWT (JSON Web Token) の構造イメージ（ピリオドで3つのパーツに分かれている）
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.  <-- 1. Header (アルゴリズムの種類)
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IktvdSBKdW4iLCJpYXQiOjE1MTYyMzkwMjJ9. <-- 2. Payload (クレーム/ユーザー情報)
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c <-- 3. Signature (デジタル署名)

インフラエンジニアとしては、SAML（XML）であれOIDC（JWT）であれ、「IdPがユーザーを認証し、その結果を暗号化署名付きのトークンとしてSPに渡す」という根本的なアーキテクチャは全く同じであることを理解しておけば、どちらのプロトコルでもトラブルシューティングが可能です。

5. フェデレーション（信頼関係）のメカニズムとデジタル署名

フェデレーション（Federation）を直訳すると「連邦」や「連合」となりますが、ITインフラにおけるフェデレーションとは、「異なる組織（ドメイン）間で、お互いの認証結果を信用し合うための事前の契約と技術的設定」を指します。

ADFS（オンプレミス）とEntra ID（クラウド）の間でフェデレーションを構築する際、裏側で極めて重要な情報の交換が行われています。それが「フェデレーションメタデータ（Metadata XML）」の交換です。

メタデータに含まれる超重要情報

フェデレーションメタデータには、相手を信用するための以下の情報が記載されています。

1. エンティティID（Entity ID）： IdPやSPの一意な名前。これが1文字でも間違っていると通信は拒否されます。
2. エンドポイントURL： 認証要求（AuthnRequest）やトークンを送るべき正確なHTTPSのURL。
3. 公開鍵（Public Key / X.509証明書）： トークンの「デジタル署名」を検証するための鍵。

デジタル署名による偽造防止のメカニズム

コウ君が疑問に思った「トークンの偽造」が不可能な理由は以下の通りです。

• ADFS（IdP）は、トークンを発行する際、自身が持つ「トークン署名証明書の秘密鍵（Private Key）」を用いて、トークン全体のハッシュ値を暗号化し、署名として付与します。
• Entra ID（SP）は、事前にメタデータ交換で受け取っていたADFSの「公開鍵（Public Key）」を用いて、この署名を復号・検証します。
• もし途中で攻撃者がトークンの中身（例：ユーザー名を一般社員から社長へ変更）を改ざんした場合、ハッシュ値が一致しなくなるため、Entra IDは「署名が無効である（改ざんされている）」と判断し、ログインを強硬に拒否します。

本編の連載第6回で「ADFS証明書爆弾」として解説したのは、このADFS側の秘密鍵（証明書）が有効期限切れ等で更新されたにも関わらず、新しい公開鍵を記載したメタデータをEntra ID側に同期し忘れた結果、署名の検証が数学的に不可能になり、全社員のログインが停止する大規模障害のことです。フェデレーションとは、この「鍵の同期」に他なりません。

6. HTTPトランザクションとトークンの受け渡し（POST Binding）

最後に、Linuxエンジニアがネットワークトラブルシューティングを行う上で知っておくべき、SAMLトークンの「物理的な運搬方法」について解説します。
ADFSとEntra IDは、インターネットを挟んで存在しています。双方がバックグラウンドのAPI通信で直接トークンをやり取りしているわけではありません。「ユーザーのWebブラウザを運び屋として利用している」という点が、Web SSOの最大の特徴です。

SAML POST Bindingの流れ

1. ADFSでの認証が成功すると、ADFSはブラウザに対して、HTTP 200 OK のレスポンスと共に、以下のような「非表示のHTMLフォーム（<form type="hidden">）」を返します。
2. このフォームの送信先（action 属性）は、Entra IDのエンドポイントURLになっています。
3. フォームの内部パラメータ（<input name="SAMLResponse" value="...">）として、Base64エンコードされたSAMLトークンがセットされています。
4. ADFSが返すHTMLには、JavaScriptの document.forms[0].submit(); といったコードが埋め込まれており、ブラウザはユーザーがクリック操作をしなくても、自動的にEntra IDに対してHTTP POSTリクエストを送信します。

<!-- ADFSがブラウザに返す自動POSTフォームの概念コード -->
<html>
  <body onload="document.forms[0].submit()">
    <noscript>
      <p>ブラウザのJavaScriptが無効になっています。「続行」ボタンをクリックしてください。</p>
    </noscript>
    <form method="post" action="https://login.microsoftonline.com/login.srf">
      <input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2lvbj..." />
      <input type="hidden" name="RelayState" value="https://portal.office.com/" />
      <noscript><input type="submit" value="続行" /></noscript>
    </form>
  </body>
</html>

インフラエンジニアがトラブルシューティングをする際、ブラウザの「F12 開発者ツール」を開き、「Network」タブの「Preserve log（ログを保持）」にチェックを入れる理由はここにあります。この自動POSTによる一瞬の画面遷移をキャプチャし、運搬されている SAMLResponse の中身を覗き見るためなのです。

7. 付録第1回の総まとめと次回予告

本記事では、「特別付録・第1回」として、M365ハイブリッド認証の根底で動いているプロトコルの基礎理論を、Linuxエンジニアの視点で徹底解説しました。

• 認証と認可の分離： 「誰であるか」を証明するAuthN（ADFS）と、「何ができるか」を制御するAuthZ（Entra ID）の役割分担がモダンインフラの基本である。
• モダン認証プロトコル： インターネット（HTTPS）越しの安全な連携を実現するため、ステートフルなKerberosに代わり、SAML（XML）やOIDC（JWT）が利用される。
• フェデレーションの正体： メタデータによる公開鍵の交換と、秘密鍵によるデジタル署名によって、トークンの偽造を数学的に不可能にする信頼関係の仕組み。
• ブラウザは運び屋： トークンはHTTPリダイレクトと自動POST（POST Binding）によって、ユーザーのブラウザを経由してIdPからSPへ運ばれる。

これらの基礎理論を理解した今、本編でなぜADFSの証明書管理が重要視されていたのか、なぜLVSのパーシステンス（セッション維持）設定が不可欠だったのか、その本質的な理由がパケットレベルで腑に落ちたはずです。

次回の【特別付録・第2回】では、ADFSをインターネットの脅威から守る「WAP（Web Application Proxy）」の境界防御の仕組みと、なぜWindows標準のNLBやNginxではなく、「LVS（Linux Virtual Server）」によるLayer4負荷分散が絶対に「必要」なのかという、ネットワークアーキテクチャの真髄に迫ります。インフラエンジニア必見のディープなネットワーク回となりますので、お楽しみに！