【第6回】M365認証トラフィックのトラブルシューティングとパケット解析（Wireshark×イベントログ）

ここまでの連載で、Windows Server 2025をベースとしたADDS（ディレクトリ）、ADFS/WAP（認証・プロキシ）、そしてLVS（高可用性ロードバランサー）、Entra ID Connect（同期エンジン）という、M365ハイブリッド認証を構成するすべてのコンポーネントの構築が完了しました。

しかし、インフラエンジニアの本当の仕事は「システムが動かなくなった時」に始まります。ユーザーから「M365（TeamsやOutlook）にログインできない」「何やら英語のエラー画面が出ている」という曖昧な申告を受けた際、この複雑な複数コンポーネントを経由する認証フローの「どこがボトルネックになっているのか」を即座に特定しなければなりません。

連載第6回となる今回は、OSの垣根を越えた「プロフェッショナルなトラブルシューティング手法」を徹底解剖します。Linuxエンジニアの伝家の宝刀である tcpdump や Wireshark を駆使したパケットレベルのネットワーク解析、ブラウザの開発者ツールを用いたSAMLトークンのデコード、そしてWindows特有のXMLイベントログをPowerShellで抽出する相関分析まで、現場で即戦力となる高度な切り分け技術を網羅的に解説していきます。

---

1. トラブルシューティングの基本原則（OSI参照モデルによる切り分け）

異種OS（LinuxとWindows）が混在し、インターネットと社内LANを跨ぐ認証インフラにおいて、問題解決の最速の近道は「OSI参照モデルの下位レイヤーから疑うこと」です。インフラエンジニアは、障害申告を受けた際、頭の中で以下のフローツリーを描きます。

1. Layer 3/4（ネットワーク・トランスポート層）： ルーティングは正しいか？LVSのDR方式設定（ARPフラックス）は機能しているか？TCPの3ウェイハンドシェイク（SYN -> SYN/ACK -> ACK）は成立しているか？
2. Layer 6（プレゼンテーション層）： TLSのバージョンは一致しているか？証明書の有効期限切れやチェーンの欠損による「TLS Alert」が発生していないか？（Windows Server 2025はTLS 1.2/1.3のみを許可するため、古いクライアントからのアクセスで頻繁に問題になります）
3. Layer 7（アプリケーション層）： HTTPステータスコードは正常（200 OK や 302 Found）か？SAMLトークンの署名やクレーム（UPNやImmutableID）の内容に欠損はないか？

画面に表示される「ログインできません」という結果は同じでも、L4のTCPタイムアウトが原因なのか、L7のSAML署名エラーが原因なのかによって、見るべきログも再起動すべきサービスも全く異なります。

2. tcpdumpとWiresharkによるパケットキャプチャの極意

認証トラブルの際、「サーバーのポートが開いているか」を ping や telnet で確認するのは初歩の初歩です。プロはパケットの「中身」と「シーケンス」を解析します。LVSサーバー（Linux）およびWAPサーバー（Windows上でパケットモニタツールを使用）でトラフィックをキャプチャします。

tcpdumpを用いた効果的なキャプチャ手法

LVSサーバーにおいて、無関係なトラフィックを排除し、特定のクライアントIPとADFSのVIP（例: 10.0.10.50）間の通信のみを抽出し、後でWiresharkで読み込めるpcap形式で保存します。

# LVSマスターノード上で実行 (対象クライアントIP: 192.168.1.100, VIP: 10.0.10.50)
sudo tcpdump -i eth0 -n -nn -e -w /tmp/adfs_auth_issue.pcap host 192.168.1.100 and host 10.0.10.50 and port 443

Wiresharkでの解析ポイント：TLSハンドシェイクの罠

取得した .pcap ファイルをWiresharkで開いた際、プロのエンジニアが真っ先に見るべきフィルタとポイントは以下の通りです。

• フィルタ tcp.flags.reset == 1： 通信が強制切断（RST）されていないかを確認します。SYNを送った直後にRSTが返ってくる場合、LVSのルーティング設定ミスか、Windows側のファイアウォールでブロックされています。
• フィルタ tls.alert_message： TLSのネゴシエーション失敗を探します。例えば Fatal, Description: Handshake Failure (40) が出ている場合、クライアント（古いブラウザやLinuxのcurlコマンド）が提案した「Cipher Suite（暗号化方式）」を、Windows Server 2025（ADFS）側がセキュリティポリシーで拒否した決定的な証拠となります。

Windows Server 2025は、過去の脆弱な暗号（RC4や3DES、CBCモードのAESなど）を完全に排除しています。パケットを見れば「OSのセキュリティレベルが高すぎて通信が拒否された」という事実が10秒で判明します。

3. HTTPヘッダとSAMLトークンの解読（F12開発者ツール）

L4〜L6のネットワークレベルで問題がない（TLSセッションが確立されている）場合、問題はアプリケーション層（L7）、つまりHTTPとSAMLプロトコルの内部にあります。この領域のトラブルシューティングは、クライアント（ユーザーのPC）のブラウザを利用します。

ブラウザによるSAMLレスポンスのキャプチャ

ユーザーにブラウザを開かせ、F12 キーを押して「開発者ツール（Developer Tools）」の「Network（ネットワーク）」タブを開いた状態で、M365へのログインを再現させます。
重要なのは、「Preserve log（ログを保持）」のチェックを必ず入れることです。M365の認証は数回のリダイレクト（HTTP 302）を伴うため、これを入れないと画面遷移の瞬間にログが消えてしまいます。

1. M365（login.microsoftonline.com）へアクセス。
2. ADFS（sts.linuxkoubou.local）へリダイレクト。
3. ADFSで認証後、再度 login.microsoftonline.com に対して HTTP POST リクエストが送信されます。

この最後の「POST」リクエストを選択し、Payload（ペイロード）タブを確認すると、SAMLResponse という巨大なパラメータが存在します。これがADFSが発行した「SAMLトークン」です。

SAMLトークン（Base64）のデコードと解析

このSAMLResponseはURLエンコードおよびBase64エンコードされています。この中身を読まずしてフェデレーションのトラブルシューティングは語れません。Linuxエンジニアであれば、ターミナルから一発でデコード可能です。

# 取得したBase64文字列（SAMLResponse）をデコードしてXMLとして整形表示する
echo "ここに取得したBase64文字列を貼り付けます" | base64 -d | xmllint --format -

デコードされたXML（SAMLアサーション）内で、以下の属性が正しくEntra IDの要求を満たしているか（欠損やフォーマット間違いがないか）を確認します。

• <Issuer>： ADFSの識別子（例：http://sts.linuxkoubou.local/adfs/services/trust）。これがEntra ID側に登録された設定と1文字でも違うと拒否されます。
• <NameID> または UPN (User Principal Name)： ログインしようとしているユーザーのID。オンプレミスADのUPNと、クラウド上のUPNが一致しているかを確認します。
• ImmutableID (ObjectGUID)： Entra ID Connectがユーザーを紐付けるための絶対不変のID。これがトークンに含まれていない場合、ADFSの「クレームルール」の設定が根本的に間違っています。

4. Windowsイベントログの相関解析（Event ID 364, 1200, 411）

ネットワークにもSAMLトークンの送信にも成功しているのに認証が失敗する場合、ADFS内部での処理（ADDSへの資格情報照会や、トークン署名処理など）でエラーが起きています。
Windows Serverの「イベントビューアー」を開き、[アプリケーションとサービスログ] -> [AD FS] -> [Admin] を確認しますが、GUIで数万件のログから該当のものを探すのは非効率極まりありません。インフラエンジニアはPowerShellを用いてログをパース（抽出）します。

注目すべきADFSのエラーイベントID

• Event ID 364（発行失敗）： ADFSがトークンの発行に失敗したことを示します。クレームルールの記述ミスや、ユーザーの属性値が空（NULL）であることが原因の大半です。
• Event ID 1200（プロキシ信頼エラー）： DMZにあるWAPサーバーと、内部のADFSサーバー間の「証明書ベースの信頼関係」が崩壊していることを示します。
• Event ID 411（トークン検証失敗）： 外部（M365側など）から送られてきた要求が不正である場合に出力されます。

PowerShellを用いた高度なイベントログ抽出スクリプト

エラーが発生した「特定のユーザーIPアドレス」や「具体的なエラー詳細」を、XML形式で保存されているイベントログの奥底からピンポイントで抽出するプロ仕様のスクリプトです。

# ADFSサーバー上で管理者として実行
# 直近24時間以内の "Event ID 364" (エラー) を抽出し、XMLデータをパースして詳細な原因を表示する
$StartTime = (Get-Date).AddHours(-24)
$Events = Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; ID=364; StartTime=$StartTime} -ErrorAction SilentlyContinue

foreach ($Event in $Events) {
    # イベントデータをXMLとして読み込む
    $eventXml = [xml]$Event.ToXml()
    $eventData = $eventXml.Event.EventData.Data
    
    # ユーザーのIPアドレスと、例外エラーのメッセージを抽出
    $ClientIP = ($eventData | Where-Object { $_.Name -eq "ClientIp" }).'#text'
    $ExceptionDetails = ($eventData | Where-Object { $_.Name -eq "ExceptionDetails" }).'#text'
    
    Write-Host "発生時刻: $($Event.TimeCreated)" -ForegroundColor Yellow
    Write-Host "クライアントIP: $ClientIP"
    Write-Host "エラー詳細: $ExceptionDetails"
    Write-Host "--------------------------------------------------"
}

このスクリプトを実行することで、「クレームルールの実行中に、Active Directoryから抽出したUPNがNULLであったため、パイプライン処理が停止した」といった、GUIの要約からは見えない根本原因が一瞬で特定できます。

5. 現場で頻発するM365認証トラブルシナリオと解決策

これまでの解析手法を用いて、エンタープライズの運用現場で頻発する「3つの代表的なトラブルシナリオ」と、その具体的な復旧コマンド（解決策）を解説します。

シナリオ1：WAPのプロキシ信頼関係崩壊（Event ID 1200）

【症状】 外部（インターネット）からのM365アクセス時のみ、ADFSのログイン画面すら表示されずに「HTTP 503 Service Unavailable」になる。社内LANからのアクセスは正常。
【解析】 WAPサーバーのイベントログに Event ID 1200 が大量に出力されている。
【原因】 WAPは内部のADFSと証明書ベースの信頼関係を結んでいますが、長期間通信が途絶えたり、ADFS側の証明書が更新された際にこの信頼が切れる（非同期になる）ことがあります。
【解決策】 WAPサーバー上で、ローカル管理者のPowerShellを開き、ADFSとの信頼関係を強制的に再構築（再インストール）します。既存の設定は引き継がれます。

# WAPサーバー上で実行し、ADFSファームとの信頼を再構築する
$cred = Get-Credential "linuxkoubou\Administrator"
Install-WebApplicationProxy -CertificateThumbprint "ここにWAPのSSL証明書拇印" -FederationServiceName "sts.linuxkoubou.local" -TrustADFSCredentials $cred

シナリオ2：ADFS証明書爆弾（トークン署名証明書のロールオーバー失敗）

【症状】 全社員が一斉にM365にログインできなくなる。画面には AADSTS50008: SAML token is invalid というEntra ID側からのエラーが表示される。
【解析】 F12で取得したSAMLResponseのデコード結果に問題はないが、Entra IDがその署名を検証できていない。
【原因】 第3回で警告した「ADFS証明書爆弾」です。ADFSのトークン署名証明書（有効期限1年）が自動更新されたにも関わらず、M365（Entra ID）側にその新しい公開鍵のメタデータが同期されていないため、暗号化署名の検証に失敗しています。
【解決策】 Entra ID Connectサーバー（またはADFSサーバー）からMSOnlineモジュール（またはMicrosoft Graph PowerShell）を用いて、クラウド側のフェデレーション信頼情報を強制更新します。

# Microsoft 365 (Entra ID) 側のフェデレーション情報を強制アップデート
Connect-MsolService
Update-MsolFederatedDomain -DomainName linuxkoubou.com -SupportMultipleDomain

シナリオ3：ADDSとLinuxクライアント間のClock Skew（時刻ズレ）

【症状】 Linuxサーバー（Ubuntu等）上のWebアプリ（Redmine等）が、ADDSのLDAP/Kerberos連携を利用してSSOを行おうとすると認証に失敗する。Windowsクライアントは正常。
【解析】 Linux側で tcpdump を見ると、ADDS（KDC）からKerberosの KRB_ERROR パケットが即座に返却されている。
【原因】 Kerberosプロトコルの絶対的ルールである「KDCとクライアント間の時刻のズレが5分以内」という条件に違反しています（Clock Skew Too Great）。仮想基盤（VMwareやHyper-V）上で動くLinuxマシンのNTP同期が一時的に失敗し、時刻がズレたことが原因です。
【解決策】 Linux側の chrony を再起動し、即時同期（makestep）を実行します。

# Linuxクライアント上でNTPの強制同期を実行
sudo chronyc -a makestep
sudo systemctl restart chronyd

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

本記事では、M365認証基盤において障害が発生した際の、Linux/Windowsの垣根を越えた高度なトラブルシューティング手法を解説しました。

• L3/L4のネットワーク解析： LVSやWAPで tcpdump を用い、TLSハンドシェイクの失敗やTCPのリセット（RST）など、暗号化通信の基盤レベルのエラーをWiresharkで可視化する。
• L7のSAML解析： ブラウザの開発者ツール（F12）で SAMLResponse をキャプチャし、Base64デコードを行って「UPN」や「Issuer」「ImmutableID」などのクレームの妥当性を検証する。
• イベントログの相関分析： WindowsのイベントビューアーのGUIに頼らず、PowerShellを用いてXMLデータをパースし、エラーの根本原因（Event ID 364, 1200等）をピンポイントで抽出する。
• OSを跨ぐ知識の統合： ネットワーク、プロトコル、暗号化、OSの知識を総動員して論理的に原因を切り分けることこそが、プロのインフラエンジニアの真価である。

ここまで、設計・構築・トラブルシューティングという、インフラエンジニアとして必要な「守りの技術」をすべて網羅しました。
次回の【第7回】では、運用フェーズに入った認証基盤をさらに進化させる「攻めの技術」にフォーカスします。生成AI（ChatGPT/Claude/Gemini）を活用したIaC（Infrastructure as Code）の生成や、日常的な運用タスク（ログ監視、障害時の自動復旧スクリプト、証明書期限の自動検知）を自動化する、モダンなインフラ運用のベストプラクティスを大公開します！AIを相棒にして、運用を劇的に効率化する手法にご期待ください。