【第7回】Linuxエンジニア視点でのパケットフロー解析とM365認証トラブルシューティング

これまでの連載第1回から第6回を通じて、私たちはADDSによるディレクトリの構築、ADFSとWAPによるセキュアなフェデレーション認証、AlmaLinux 9とLVSによる超高速な負荷分散、そしてEntra Connectを用いたM365とのディレクトリ同期を完成させてきました。これにより、強固なエンタープライズ向けハイブリッド認証基盤の構築はコンプリートしました。

しかし、インフラエンジニアの本当の戦いは「システムが稼働した後」に始まります。ある日突然、社内から「M365にログインできない」「認証画面がループする」といった深刻なアラートが飛び込んできたとき、あなたならどこから調査を始めますか？
M365の認証基盤は、クライアントブラウザ、DNS、LVS、WAP、ADFS、ADDS、そしてクラウド（Entra ID）という多数のコンポーネントが複雑に絡み合っています。原因がネットワーク（L4）にあるのか、プロキシ（L7）にあるのか、あるいはSAMLの証明書にあるのか。カンと経験に頼った当てずっぽうの調査は、復旧時間を無駄に引き延ばすだけです。

連載第7回となる今回は、Linuxエンジニアの最強の武器である「パケットフロー解析（tcpdump）」や「ルーティングテーブルの可視化」を起点とし、Windows特有のイベントログ解析、さらにはSAMLトークンのデコードに至るまで、「プロのインフラエンジニアが行う障害切り分け（トラブルシューティング）の全手順」を圧倒的な情報密度で徹底解剖します。

📚 本連載のカリキュラム（全8回）

リナックス先生！今朝から「M365のポータルにログインできない」って問い合わせが殺到してます！画面が真っ白になったり、「サインイン状態を維持しますか？」の画面から先に進まなかったり……。LVSが落ちてるのか、ADFSが死んでるのか、M365自体が障害なのか、コンポーネントが多すぎてどこを見ればいいか分かりません！

落ち着きなさい、コウ君！パニックになった時こそ「パケットの旅路」を最初から順に辿るのよ。ブラウザから出た通信が、DNS、ファイアウォール、LVS、WAP、ADFS、そしてクラウドへ、どの段階でドロップされているかをレイヤー順（L3/L4からL7へ）に切り分けるの。Linuxエンジニアが最も得意とする論理的な切り分け術を、今こそ見せつける時よ！

1. 認証トラフィックの全体パケットフロー（正常時）の理解
- 1-1. HTTPリクエストの連鎖（302リダイレクトの旅）
- 1-2. 障害箇所の「アタリ」をつけるブラウザ開発者ツール
2. LVS（AlmaLinux 9）レイヤーでのネットワーク障害切り分け
3. WAP/ADFS（Windows層）のイベントログ解析術
4. M365 (Entra ID) レイヤーでのSAMLデバッグ
5. 緊急時のフォールバック：フェデレーションの強制解除
6. 第7回の総まとめと次回の予告

📚 本連載のカリキュラム（全8回）

1. 認証トラフィックの全体パケットフロー（正常時）の理解
1. 1-1. HTTPリクエストの連鎖（302リダイレクトの旅）
2. 1-2. 障害箇所の「アタリ」をつけるブラウザ開発者ツール
2. LVS（AlmaLinux 9）レイヤーでのネットワーク障害切り分け
3. WAP/ADFS（Windows層）のイベントログ解析術
4. M365 (Entra ID) レイヤーでのSAMLデバッグ
5. 緊急時のフォールバック：フェデレーションの強制解除
6. 第7回の総まとめと次回の予告
1. ▼ 【認証基盤の検証環境を構築しよう】 ▼

1. 認証トラフィックの全体パケットフロー（正常時）の理解

障害を切り分けるための第一歩は、「正常なパケットがどのような経路で、どのようなHTTPステータスコードを返しながら流れているか」を完全に暗記しておくことです。異常（エラー）は、正常なフローからの逸脱として検知されます。

1-1. HTTPリクエストの連鎖（302リダイレクトの旅）

フェデレーション環境において、ユーザーがM365にログインする際のフローは以下の通りです。

M365ポータルへのアクセス： クライアントが https://portal.office.com にアクセス。
Home Realm Discovery (HRD)： ユーザーがID（taro@linuxkoubou.com）を入力。Entra IDはこのドメインがフェデレーションされていることを検知し、ADFS（WAP）のURLへHTTP 302 Redirectを返却します。
例: Location: https://sts.linuxkoubou.com/adfs/ls/?SAMLRequest=...
WAP（LVS）への到達： クライアントはインターネット上のDNSで sts.linuxkoubou.com を引き、DMZのLVS（VIP）へTCP 443で接続。LVSはパケットをバックエンドのWAPへ転送。
ADFSへのプロキシ： WAPはリクエストを受け取り、MS-ADFSPIPプロトコルを通じて内部のADFSサーバーへプロキシします。
ADFSでの認証： ADFSはクライアントに対し、Windows統合認証（社内LANの場合）またはフォーム認証の画面を返します。クライアントが認証情報を送信し、ADDS（ドメインコントローラー）で検証されます。
SAMLトークンの返却： 認証が成功すると、ADFSはSAML Assertion（暗号化された署名付きトークン）を含むHTMLフォーム（自動的にPOSTされるJavaScript付き）をクライアントに返します。
Entra IDへのPOST： クライアントのブラウザが、受け取ったSAMLトークンを https://login.microsoftonline.com/login.srf へHTTP POSTします。
ログイン完了： Entra IDがトークンの署名を検証し、正しければセッションクッキーを発行し、ポータル画面が表示されます。

1-2. 障害箇所の「アタリ」をつけるブラウザ開発者ツール

ユーザーから「ログインできない」と連絡を受けたら、まずユーザーのブラウザで「F12キー」を押して開発者ツールを開き、「Network（ネットワーク）」タブで上記のどのステップで処理が止まっているかを確認します。

sts.linuxkoubou.com への通信がタイムアウト（ERR_CONNECTION_TIMED_OUT）する → LVS、WAP、ファイアウォール、またはDNSの障害（L3/L4）。
ADFSのログイン画面は出るが、パスワードを入れても「認証に失敗しました」と出る → ADFSとADDS間の通信障害、またはADDSのロックアウト（L7）。
ADFSの認証は通るが、その後M365の画面で「AADSTSXXXXX」というエラーコードが出る → 証明書の不一致、またはImmutableIdの同期エラー（SAML/Cloud層）。

このようにアタリをつけることで、調査対象のサーバーを即座に絞り込むことができます。

2. LVS（AlmaLinux 9）レイヤーでのネットワーク障害切り分け

ブラウザで「タイムアウト」が発生している場合、Linuxエンジニアの主戦場であるAlmaLinux 9（LVSサーバー）での調査を開始します。

2-1. `tcpdump` によるスリーウェイハンドシェイクの確認

LVSがパケットを正しく受信し、バックエンドのWAPへ転送しているかを確認するには、tcpdump が最強のツールです。DMZ側（インターネットから入ってくるIF）と、内部側（WAPへ転送するIF）の両方でパケットをキャプチャします。

# クライアントのIPアドレス（例: 203.0.113.10）からのTCP 443パケットを監視
sudo tcpdump -i any host 203.0.113.10 and port 443 -n -nn

正常なスリーウェイハンドシェイクの場合、以下のような出力（[S] -> [S.] -> [.]）が見られます。

10:00:01.123 IP 203.0.113.10.50000 > 192.168.10.100.443: Flags [S], seq 123456...
10:00:01.124 IP 192.168.10.100.443 > 203.0.113.10.50000: Flags [S.], seq 654321 ack 123457...
10:00:01.125 IP 203.0.113.10.50000 > 192.168.10.100.443: Flags [.], ack 1...

2-2. 非対称ルーティング（戻りパケット消失）の検知

もし、tcpdump の結果が Flags [S]（SYNパケット）ばかりが連続して表示され、Flags [S.]（SYN-ACKパケット）が一切返ってこない場合、それは第5回で警告した「非対称ルーティング（Asymmetric Routing）」の典型的な症状です。

クライアントからのパケットはLVSに届き、LVSはNATしてWAPへ転送しています。しかし、WAPの「デフォルトゲートウェイ」がLVSの内部IP（DIP）に向いていないため、WAPからの戻りパケットが別のルーターを経由してインターネットへ出てしまい、クライアント側のファイアウォールで「ステート不一致」として破棄されている状態です。
直ちにWindows Server（WAP）のネットワークアダプタ設定を開き、デフォルトゲートウェイがLVSに向いているか確認してください。

2-3. persistence_timeout破綻によるSAML認証ループの罠

「ログイン画面は出るが、パスワードを入れるとまた最初の画面に戻される（認証ループ）」という事象が発生した場合、LVSのセッションパーシステンス（維持機能）が破綻しています。

# LVSのコネクションとパーシステンス状況を確認
sudo ipvsadm -Lnc

このコマンドを実行し、同じ送信元IPからのパケットが WAP01 と WAP02 にバラバラに振り分けられている（ActiveConn が分散している）場合、/etc/keepalived/keepalived.conf の persistence_timeout 1800（30分）の設定が抜け落ちているか、Keepalivedの再起動が漏れています。SAML認証のトランザクションが別のWAPに引き継がれると、セッションの整合性が取れずに破棄されるため、この設定は極めて重要です。

3. WAP/ADFS（Windows層）のイベントログ解析術

ネットワーク（L3/L4）に問題がない場合、原因はアプリケーション層（Windowsのサービス）にあります。Linuxにおける /var/log/messages に相当するのが、Windowsの「イベントビューアー」です。

3-1. PowerShellを用いた高度なイベントログ抽出

GUIでイベントビューアーを開いて何万件ものログを目視するのは非効率です。Linuxエンジニアなら grep する感覚でPowerShellを使いこなしましょう。

# ADFSサーバーの「AD FS/Admin」ログから、直近1時間のエラー（Level 2）を抽出
Get-WinEvent -LogName "AD FS/Admin" -MaxEvents 50 | Where-Object {$_.Level -eq 2 -and $_.TimeCreated -gt (Get-Date).AddHours(-1)} | Format-List TimeCreated, Id, Message

# WAPサーバーの「Web Application Proxy/Admin」ログからエラーを抽出
Get-WinEvent -LogName "Microsoft-Windows-WebApplicationProxy/Admin" -MaxEvents 50 | Where-Object {$_.Level -eq 2} | Format-List TimeCreated, Id, Message

おおっ！Linuxの journalctl --since "1 hour ago" -p err みたいなことがPowerShellでも簡単にできるんですね！これなら調査スピードが格段に上がりそうです。でも、イベントIDって数字の羅列で意味が分かりません……。どれを気をつければいいんですか？

Windowsのイベントログは、エラーの種類ごとに「Event ID」が決まっているのが便利なところよ。M365認証の障害対応において、SREが絶対に覚えておくべき頻出のEvent IDを教えるわね。これを知っているだけで解決までの時間が何時間も縮まるわよ！

3-2. Event ID 422/364：プロキシ信頼（Proxy Trust）の喪失

WAPサーバー側で最も恐ろしいエラーが Event ID 422（Web Application Proxy / Admin） と、それに連動してADFS側で発生する Event ID 364（AD FS / Admin） です。

エンジニアが最初に読むべき Linuxサーバの教科書【電子書籍】[ 大津真 ]

価格:3740円
(2026/7/17 19:14時点)
感想(0件)

原因： WAPとADFS間の「プロキシ信頼証明書」が失効しているか、ADFSサーバーとWAPサーバーの間で時刻（NTP）がズレているため、セキュアな通信チャネルが確立できていません。
対応： WAPサーバー側で以下のコマンドを実行し、ADFS管理者権限でプロキシ信頼を強制的に再構築します。

# WAPサーバーで実行し、Proxy Trustを再確立
$cred = Get-Credential
Install-WebApplicationProxy -CertificateThumbprint "証明書のハッシュ値" -FederationServiceName "sts.linuxkoubou.com" -WebApplicationProxyCredential $cred

3-3. ADFSのEvent ID 411/511：トークン発行エラーとクレームの不一致

ADFSサーバー側で Event ID 411 や 511 が発生している場合、ユーザーのパスワードは合っているのに「SAMLトークンの発行」に失敗しています。

原因： Entra Connectで同期している属性（UPNやImmutableId）が、ADFS側で設定されている「要求規則（クレームルール）」と合致していない、あるいは対象のユーザーアカウントがAD上でロック・無効化されています。
対応： ADFSの「証明書利用者信頼（Relying Party Trust）」の設定を開き、M365向けの要求規則で「User-Principal-Name」と「objectGUID（またはmS-DS-ConsistencyGuid）」が正しくマッピングされて送信される設定になっているか確認します。

4. M365 (Entra ID) レイヤーでのSAMLデバッグ

ここまでの調査でエラーがない場合、問題は「クラウド側」にあります。ADFSは正常にSAMLトークンを発行してブラウザに渡しているのに、M365（Entra ID）がそのトークンを拒否している状態です。

4-1. SAML Tracerを用いたAssertionのデコードと検証

このようなケースでは、ブラウザの拡張機能である「SAML Tracer」を使用して、POSTされるSAML Assertion（XML）の生データをキャプチャしてデコードします。

SAML Tracerでキャプチャしたデータを開き、<saml:Assertion> 内の <saml:Attribute> を確認します。

<saml:Attribute Name="IDPEmail">
    <saml:AttributeValue>taro@linuxkoubou.com</saml:AttributeValue>
</saml:Attribute>

この属性値が、実際にM365側に登録されているユーザーのUPNと1文字でも異なっていれば（大文字小文字の違いや、末尾のスペース混入など）、認証は弾かれます。

4-2. ImmutableId（ソースアンカー）不一致エラー（AADSTS51004）

M365の画面に 「AADSTS51004」 というエラーコードが表示された場合、これは「オンプレミスADのユーザー」と「クラウド上のユーザー」が紐付いていない（ソースアンカーが不一致）という致命的なエラーです。

原因： 第6回で解説した通り、オンプレミスのADでユーザーを誤って削除し、同名で作り直した場合などに発生します。ObjectGUID が変更されたため、SAMLトークン内のIDとクラウドのIDが合致しません。
対応： この場合、インフラエンジニアはPowerShellを用いて、クラウド上のユーザーの ImmutableId を強制的に上書きする必要があります。

# 新しいオンプレミスユーザーのObjectGUIDをBase64に変換し、M365のImmutableIdに上書きする（復旧コマンド）
Set-MsolUser -UserPrincipalName "taro@linuxkoubou.com" -ImmutableId "新しいBase64文字列"

4-3. 署名証明書のロールオーバー失敗による全断障害

M365にアクセスした「全員」が同時に 「AADSTS50008: SAML トークンが無効です」 等のエラーで弾かれる場合、十中八九「トークン署名証明書のロールオーバー（更新）に伴う同期漏れ」が原因です。

原因： ADFSが自動生成した新しいトークン署名証明書の公開鍵が、Entra ID側に同期されていません。ADFSは新しい鍵で署名しているのに、M365は古い鍵で検証しようとしているためエラーになります。
対応： 一刻を争うため、即座にADFSサーバー上で以下のコマンドを実行し、クラウド側のフェデレーション信頼情報を最新化します。

# ADFSサーバーで実行（障害発生時の緊急復旧コマンド）
Update-MSOLFederatedDomain -DomainName "linuxkoubou.com" -SupportMultipleDomain

5. 緊急時のフォールバック：フェデレーションの強制解除

もし、ADFSサーバー自体がハードウェア障害などで完全にクラッシュし、復旧までに数日かかるという最悪のシナリオが発生した場合、全社員の業務が停止してしまいます。
この場合の「最終手段（Bプラン）」として、第6回で「パスワードハッシュ同期（PHS）」を併用設定しておいたことが活きてきます。

ADFSを使わず、クラウド上のパスワードハッシュを使って認証させる（フェデレーションを解除する）には、M365のグローバル管理者権限を持った端末から以下のコマンドを実行します。

# ドメインの認証方式をフェデレーションからマネージド（クラウド単独認証）へ強制変更
Set-MsolDomainAuthentication -Authentication Managed -DomainName "linuxkoubou.com"

このコマンドがクラウド全体に伝播するまでに数時間かかる場合がありますが、伝播が完了すれば、ADFSが完全にダウンしていても、ユーザーはM365の画面にパスワードを入力することで業務を継続（フェイルオーバー）することが可能になります。

6. 第7回の総まとめと次回の予告

本記事では、M365認証基盤において障害が発生した際の、Linuxエンジニアならではの論理的なパケットフロー解析から、Windowsのイベントログ、そしてSAMLのデコードまで、実践的なトラブルシューティング手法を解説しました。

障害対応において最も重要なのは「エラーメッセージを闇雲にググること」ではありません。ブラウザからクラウドに至るまでの「パケットの旅路」を正確にイメージし、tcpdump や ipvsadm、PowerShellのログ抽出を駆使して「どこまでは正常で、どこから異常か」を確実に見極めることです。この切り分け能力こそが、プロのインフラエンジニア（SRE）の真の価値です。

次回の【第8回・最終回】認証基盤の監視・ログ収集と自動化（Zabbix / Ansible連携）では、これまでの連載で構築してきた全てのコンポーネントに対し、「障害を未然に防ぐ」ための監視システム（Zabbix）を導入し、証明書の有効期限切れやログの異常を検知してAnsibleで自動修復する「次世代の自動化運用アーキテクチャ」の総仕上げを行います。感動の最終回をお見逃しなく！