【第1回】LinuxエンジニアのためのM365ハイブリッド認証アーキテクチャ完全解剖（ADDS/ADFS/EntraID/LVS）

最近、企業のITインフラにおいて「LinuxとWindowsの境界線」が急速に曖昧になってきています。特に、Microsoft 365（M365）の導入がエンタープライズ企業で標準化する中、これまでLinuxサーバーの構築・運用を主戦場としてきたエンジニアであっても、Active Directory（ADDS）やEntra IDを絡めたハイブリッド認証基盤の設計、運用、そして高度なトラブルシューティングを求められるケースが急増しています。

ゼロトラストアーキテクチャが主流となる現代において、認証基盤はネットワークの「新しい境界」です。本連載「LinuxエンジニアのためのM365認証」では、普段ターミナルでLinuxコマンドを叩いているインフラ・サーバーサイドエンジニアの視点から、最新のWindows Server 2025をベースとしたM365のハイブリッド認証アーキテクチャをTCP/IPレベルから解読します。さらに、我々の得意とするOSSの超高速ロードバランサーであるLVS（Linux Virtual Server）を組み合わせて、エンタープライズ水準の可用性を実現する実践的な手法を全8回にわたって徹底解説していきます。

---

1. LinuxエンジニアがM365認証を学ぶべき理由と全体像

オープンソーステクノロジーを中心にキャリアを築いてきたLinuxエンジニアにとって、Microsoftテクノロジーの根幹であるActive Directory（AD）やM365の認証基盤は「ブラックボックス」であり、「Windows管理者の仕事」と見なされがちでした。しかし、現代のエンタープライズIT環境において、Linuxサーバー群（Webアプリケーション、データベースサーバー、Kubernetesなどのコンテナオーケストレーション基盤）は単独で存在するわけではありません。

近年、情報セキュリティの考え方は「ファイアウォールによる境界防御」から、すべてのアクセスを疑って検証する「ゼロトラストアーキテクチャ」へと移行しています。このゼロトラストの根幹をなすのが「強力なアイデンティティ（ID）管理」です。社内のRedmine、GitLab、Zabbix、あるいは自社開発のPHP/Laravelアプリケーションであっても、SSO（シングルサインオン）の要求は高まる一方です。これらLinux上のアプリケーションは、SAML 2.0やOIDC（OpenID Connect）を用いて、M365のバックエンドである「Entra ID (旧Azure AD)」に認証を委譲する構成（SP/RPとしての動作）が一般的になりました。

つまり、Linuxエンジニアが構築・運用するシステムも、最終的にはM365の認証インフラに依存することになります。このインフラの根幹アーキテクチャを理解していなければ、システム全体の可用性設計を行うことはできません。万が一認証エラーや遅延が発生した際、それがLinux側のリバースプロキシ（Nginx/Apache）の設定ミスなのか、ネットワーク機器のルーティング問題なのか、それともWindows側のIdP（ADFSやEntra ID）の証明書エラーなのか、パケットレベルでの正確な切り分けが不可能になります。

オンプレミスADとEntra IDの境界線とフェデレーションの概念

長年にわたり、社内LANの認証は「Active Directory Domain Services (ADDS)」が担ってきました。ここで使用されるプロトコルはKerberosやNTLMといったLAN内での利用を前提としたレガシーな仕組みであり、TCP 88番ポート（Kerberos）やTCP/UDP 389番ポート（LDAP）を使用します。しかし、M365のようなインターネット越しのクラウドサービスは、これらのLAN向けプロトコルを直接解釈することができません。

そこでクラウド時代に合わせて登場したのが、インターネット越しでも安全に認証情報をやり取りできるHTTPS（TCP 443）ベースのモダン認証プロトコル（SAML、WS-Federation、OAuth、OIDC）を喋るクラウドディレクトリ「Entra ID」です。現在多くの企業は、既存のオンプレミスADDSとクラウドのEntra IDを同期させる「ハイブリッドアイデンティティ」環境を構築しています。

この両者をつなぎ、企業が「クラウド側にパスワード情報を一切持たせたくない」「社内のADベースの細かいアクセス制御（時間帯制限や特定端末の証明書認証など）をクラウドサービスに対しても適用したい」という高度なセキュリティ要件を満たすために導入されるのが、ADFS（Active Directory Federation Services）というフェデレーション（信頼関係）サーバーです。

2. M365ハイブリッド認証のコアコンポーネント詳細

ここでは、最新OSである「Windows Server 2025 Standard」を前提とした、ハイブリッド認証基盤を構成する主要コンポーネントを定義します。それぞれの役割と、通信要件（ポート番号など）をプロのインフラエンジニアの視点で正確に把握しましょう。

ADDS (Active Directory Domain Services)

企業内のユーザー、グループ、コンピューターオブジェクトを階層的に管理し、認証と認可の最終的な源泉（Source of Truth）となるディレクトリサービスです。内部的にはLDAPデータベースプロトコルを使用しています。
Windows Server 2025では、次世代のセキュリティ標準への対応として、TLS 1.3のサポート強化や、古い暗号化スイート（RC4やDESなど）のデフォルト無効化が図られています。Linuxクライアント（sssdやrealmd）からLDAPS（TCP 636）やKerberos連携を行う際、この最新の暗号化要件を満たせないと暗号化ネゴシエーションに失敗し認証エラーに陥るため、互換性のチューニングには細心の注意が必要です。

ADFS (Active Directory Federation Services)

ADDSと連動し、外部サービスに対するクレームベースの認証を提供するサーバーです。通常は内部ネットワークに配置されます。
ユーザーがM365にアクセスすると、認証リクエストはEntra ID経由でこのADFSにリダイレクトされます。ADFSは内部のADDSに対してKerberosやNTLMでユーザーの資格情報を確認し、成功するとユーザーの属性情報（UPNやグループ情報など）を含むデジタルトークン（主にWS-FederationやSAML 2.0形式のXML）を生成し、秘密鍵で署名します。
エンタープライズ環境では複数台のADFSサーバーで「ファーム」を構成します。ファームの設定情報を共有するデータベースとして、Windows Internal Database (WID) または外部のSQL Serverが使用されます。Linuxエンジニアであれば、WIDは「軽量な組み込みSQLite的なもの」、SQL Serverは「MySQLやPostgreSQLのような本格RDBMS」と捉えるとスケーラビリティの設計がしやすくなります。

WAP (Web Application Proxy)

ADFSは社内の重要情報（ADDSへの直接通信権限）を持つため、インターネット上に直接公開することはセキュリティ設計上絶対に許されません。そこで外部と内部の境界であるDMZ（非武装地帯）ネットワークに配置されるのがWAPです。
WAPはADFSのリバースプロキシとして機能し、外部（インターネット）からのHTTPSリクエスト（TCP 443）を終端し、内部ネットワークのADFSファームへ安全に転送します。Linuxエンジニアにとっては「NginxやHAProxyのようなL7リバースプロキシに、Microsoft独自のフェデレーション事前認証機能（Pre-Authentication）が組み込まれたアプライアンスサーバー」と考えると理解が早いでしょう。WAPは内部のADFSに対してのみ通信（TCP 443）できればよく、ADDSと直接通信する必要はありません。

Entra ID (旧 Azure Active Directory)

Microsoftが提供するグローバルなクラウドベースのIDおよびアクセス管理サービスであり、M365の認証のフロントドア（玄関）です。オンプレミス環境の内部ネットワークに「Entra ID Connect (またはクラウド同期エージェント)」という同期専用サーバーを配置し、オンプレミスのADDSからユーザーのオブジェクト情報（UPN、メールアドレスなど）をEntra IDへ定期同期させることで、真のハイブリッド環境が完成します。フェデレーション環境の場合、パスワード自体はクラウドに同期させず、認証のトランザクションはすべてオンプレミスのADFSにリダイレクトして処理させます。

3. 認証トラフィックのフローとプロトコルのパケットレベル解剖

アーキテクチャ設計に入る前に、ユーザーが社外のインターネット環境からM365（例えばTeamsやOutlook on the web）にアクセスした際の、フェデレーション認証のトラフィックフローをHTTP/TCPレベルで解剖します。パケットの動きを時系列で理解することで、後にロードバランサーを導入する際の「なぜパーシステンス（セッション維持）設定が必要なのか」が見えてきます。

1. サービスアクセス： ユーザーがブラウザで `portal.office.com` (M365の入り口) にアクセスします。ブラウザはMicrosoftのサーバーとTLSハンドシェイクを完了し、GETリクエストを送信します。
2. ホームレルムディスカバリ (HRD)： ログイン画面でユーザーがメールアドレス（例: user@linuxkoubou.local）を入力します。Entra IDはドメイン名（linuxkoubou.local）をルックアップし、「このドメインはオンプレミスのADFSでフェデレーション管理されているドメインだ」と判断します。
3. HTTPリダイレクト (302 Found)： Entra IDはユーザーのブラウザに対し、オンプレミスのADFS公開URL（例: https://sts.linuxkoubou.local/adfs/ls/）に対するWS-Federationプロトコルのパラメータ（wtrealm等）を含めた HTTP 302 リダイレクトレスポンスを返します。
4. WAPでのトラフィック終端 (TCP 443)： ブラウザはリダイレクト指示に従い、`sts.linuxkoubou.local` をDNS解決します。社外からのアクセスのため、グローバルIPアドレスが返り、DMZに配置されたWAP（厳密にはWAPの前に配置されたLVSの仮想IP: VIP）に到達します。ここでクライアントとWAPの間でTLSセッションが確立されます。
5. WAPからADFSへのプロキシ転送： WAPは受信したHTTPリクエストを暗号化されたまま内部ネットワークのADFSファームへリバースプロキシ転送します。
6. ユーザー認証の実行： ADFSはブラウザに対してログインフォーム（HTML）を返します。ユーザーがIDとパスワード（およびMFAワンタイムパスワードなど）を入力してPOSTすると、ADFSはADDSに対してLDAP/Kerberosで資格情報を検証します。
7. トークンの発行と自動POST： 検証が成功すると、ADFSはEntra ID向けに暗号化署名されたセキュリティトークンを生成し、HTMLの非表示フォームに埋め込んでブラウザに返します。同時に、JavaScript等を利用してブラウザからEntra IDのエンドポイント（https://login.microsoftonline.com/...）へ自動的にPOSTさせます。
8. M365へのログイン完了： Entra IDが受け取ったトークン内の暗号化署名をADFSの公開鍵で検証し、改ざんがなく正当であればOAuth/OIDCのセッショントークンを発行し、M365のダッシュボードが表示されます。

ここで重要なネットワークエンジニア的視点は、「ADFSとEntra IDは直接通信しない（すべてユーザーのブラウザを介したリダイレクトとPOSTである）」こと、「トラフィックはすべてHTTPS（TCP 443）である」こと、そして「MFA（多要素認証）などを含むフォームベース認証プロセスでは複数回のHTTPリクエストが発生するため、一連の認証が完了するまで同一クライアントは同一のADFS/WAPノードと通信し続けるべき要件（パーシステンス）が発生する」ということです。途中でロードバランサーが別のノードにパケットを振り分けてしまうと、認証セッションが破棄されエラー（ループ）になります。

4. LVSによるADFS/WAPの超高可用性負荷分散アーキテクチャ

WAPやADFSの可用性を高めるためには、サーバーを複数台並べた「ファーム」を構成し、その手前にトラフィックを分散するロードバランサーを配置します。Windows Serverには標準でNLB（ネットワーク負荷分散）機能がありますが、ARPのブロードキャスト問題やMACアドレスのマルチキャストにおけるネットワークスイッチ（Ciscoなど）との相性問題、そして何よりパフォーマンスの限界から、エンタープライズ環境では専用のハードウェアアプライアンス（F5 BIG-IP等）や、堅牢で実績のあるOSSであるLVS (Linux Virtual Server) と Keepalived の組み合わせが強力な選択肢となります。

LVS (Keepalived) を採用する最大のメリット：Layer4の超高速処理

LVSはLinuxカーネルレベル（IPVSモジュール）でルーティングとパケット転送を行うため、圧倒的なスループットを誇ります。NginxやHAProxyのようなリバースプロキシ型（Layer 7）のように、ユーザー空間でTCPコネクションを受け取り、SSL/TLSの暗号化を解読し、再度バックエンドへコネクションを張る、というオーバーヘッドが一切ありません。
Layer 4（トランスポート層）で動作するLVSは、パケットのIPアドレスとTCPポート番号だけを見てルーティングを行うため、ADFSやWAP自身が持つ強固なSSL/TLS処理能力をそのまま活かすことができます。

ルーティング方式の選定とプロのアーキテクチャ設計

LVSには主に3つのパケット転送方式（NAT, DR, TUN）があります。M365ハイブリッド認証基盤において、プロが推奨する構成は以下の通りです。

• DMZにおけるWAPの負荷分散（NAT方式またはL7プロキシへの移行）：
  DMZ環境では、インターネットからの不特定多数のアクセスを受けます。ルーティングの複雑さを回避し、グローバルIPからプライベートIPへの変換をシンプルに行うため、NAT（Network Address Translation）方式を採用するのが現場のベストプラクティスです。最近ではセキュリティ要件により、WAPの前段にWAF（Web Application Firewall）を兼ねたNginx等のL7プロキシを配置するケースも増えています。
• 内部ネットワークにおけるADFSの負荷分散（DR方式：Direct Routing）：
  社内のADFSファームへの通信には、Direct Routing (DR / DSR: Direct Server Return) 方式が圧倒的に有利です。ロードバランサー（LVS）はクライアントからの要求パケットの宛先MACアドレスだけをADFSノードのMACアドレスに書き換えて転送します。ADFSからクライアントへの大容量の応答パケット（SAMLトークンを含む）は、LVSを経由せずにADFSから直接クライアントへ返されるため、ロードバランサーのネットワーク帯域がボトルネックになることが物理的にあり得ません。

Linuxエンジニアが直面する罠：DR方式における「ARPフラックス問題」の解決

DR方式を採用する場合、LinuxエンジニアがWindowsインフラと連携する際に必ず直面し、対処しなければならない高度なネットワークの罠があります。それが「ARPフラックス（ARP Flux）問題」です。

DR方式を成立させるためには、LVSが持つ仮想IPアドレス（VIP）と全く同じIPアドレスを、バックエンドのWindows Server（ADFSノード）にも設定し、パケットを自分宛てのものとして受信させる必要があります。Windowsでは「Microsoft KM-TEST Loopback Adapter（ループバックインターフェース）」を追加してVIPを設定します。
しかし、そのままではWindowsサーバー自身がLAN上に「私がそのVIPを持っています！」とARP応答を返してしまい、LVSのVIPとIP競合を起こし、パケットがLVSをバイパスして通信が完全に破綻します。

これを防ぐため、Windows Server側でループバックアダプタに対して「ARPリクエストには絶対に応答しないが、受信したパケットは処理する」というストロングホストモデル（Strong Host Model）の無効化設定が必須となります。プロの現場では、以下のPowerShellコマンドを用いてARP応答を抑制します。

# Windows Server 2025 (ADFSノード) 側でのARP応答無効化・パケット転送設定
# "Loopback" は追加したループバックアダプタのインターフェース名
Set-NetIPInterface -InterfaceAlias "Loopback" -WeakHostReceive Enable -WeakHostSend Enable -DadTransmits 0

# IPv4インターフェースのメトリック調整（物理NICを優先）
Set-NetIPInterface -InterfaceAlias "Loopback" -InterfaceMetric 254

Keepalived.confの実践的な設定例（ADFS向け Layer4 / DR方式）

以下は、ADFSノード2台に対するLVS（Keepalived）のDR方式の設定コードです。SSLヘルスチェック、タイムアウトチューニング、および認証途中のセッション切れを防ぐパーシステンス（セッション維持）設定を組み込んだ、エンタープライズの本番環境でそのまま適用できるプロ仕様のスニペットです。

# /etc/keepalived/keepalived.conf (LVSマスターサーバー用)
# ADFSファーム用仮想IP: 10.0.100.50
virtual_server 10.0.100.50 443 {
    delay_loop 5            # ヘルスチェックのインターバル(秒)
    lb_algo rr              # 負荷分散アルゴリズム: ラウンドロビン (Round Robin)
    lb_kind DR              # 転送方式: Direct Routing (DSR)
    persistence_timeout 300 # セッション維持: 300秒(5分) MFA等のフォーム認証中断を防止
    protocol TCP

    # ADFS Node 1 (物理IP: 10.0.100.11)
    real_server 10.0.100.11 443 {
        weight 100          # 重み付け
        SSL_GET {
            url {
              path /adfs/probe
              status_code 200
            }
            connect_timeout 3
            retry 3                 # 3回失敗でノード切り離し
            delay_before_retry 3    # 再試行間の待機時間
        }
    }

    # ADFS Node 2 (物理IP: 10.0.100.12)
    real_server 10.0.100.12 443 {
        weight 100
        SSL_GET {
            url {
              path /adfs/probe
              status_code 200
            }
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }
}

5. M365認証基盤におけるセキュリティと可用性チューニング

アーキテクチャの構築だけでなく、運用フェーズを見据えたセキュリティチューニングもインフラエンジニアの重要な責務です。M365認証基盤において、特に考慮すべきポイントを2つ挙げます。

エクストラネット スマートロックアウト（ESL）の有効化

ADFSをインターネットに公開（WAP経由）すると、悪意のある攻撃者からパスワードリスト攻撃やブルートフォース攻撃を受けます。ADFSがすべてのリクエストをADDSに転送してしまうと、社内のADアカウントが次々とロックアウトされ、出社した社員がPCにログインできなくなるという大障害に発展します。
これを防ぐため、Windows ServerのADFSには「エクストラネット スマートロックアウト（Extranet Smart Lockout）」機能が備わっています。これは、外部（WAP経由）からの認証失敗が一定回数に達した場合、内部のADDSをロックアウトさせるのではなく、ADFSのレベルでそのIPからの要求を遮断（ソフトロックアウト）する強力な防波堤機能です。

TLS証明書（SSL証明書）の運用設計

ADFSは3つの異なるデジタル証明書を使用します。
1. **Service Communications（サービス通信証明書）：** HTTPS通信のための一般的なSSL/TLS証明書。WAPとADFSの両方にインストールし、公的な認証局（CA）から発行されたものを使用します。
2. **Token-Decrypting（トークン暗号化解除証明書）：** クレームを暗号化する際に使用。
3. **Token-Signing（トークン署名証明書）：** 発行したSAML/WS-Fedトークンが改ざんされていないことをEntra IDに証明するための最重要証明書。
2と3はデフォルトで自己署名証明書（有効期限1年）が自動生成され、有効期限の数週間前に自動でロールオーバー（更新）される仕組みを持っています。しかし、Entra ID側と適切にメタデータを同期設定していないと、トークン署名証明書が切り替わった瞬間にEntra IDがトークンを検証できなくなり、M365へのログインが全社的に停止します。このライフサイクル管理をIaC等で自動化することが可用性維持の鍵となります。

6. 生成AIを活用したインフラ設計の比較とアプローチ

近年、私たちインフラエンジニアの業務において「生成AI（Generative AI）」の活用は避けて通れないテーマとなっています。M365認証基盤のように、Windows（PowerShell/イベントログ）とLinux（Bash/LVS設定/tcpdump）が混在し、さらに高度なネットワーク設計が求められる複雑な環境において、AIは単なるチャットツールを超えた「ペアプログラミング・パートナー」となります。代表的な生成AIモデルをどのように使い分けるべきか、プロの視点でアプローチを解説します。

1. GPT-4o：Windows/M365エコシステムのIaCコード生成

ADFSやWAPの構築には、大量のPowerShellコマンドレット（Install-WindowsFeature, Add-AdfsFarmNode, Install-WebApplicationProxyなど）を使用します。Microsoft製品の膨大な公式ドキュメントや最新のモジュール仕様を深く学習しているGPT-4oは、このコード生成領域で圧倒的な強みを持ちます。

【効果的なプロンプト例】
「あなたはWindows Serverのシニアインフラエンジニアです。Windows Server 2025において、既存のADFSファーム（プライマリノードはadfs01.local）にセカンダリノード（adfs02.local）を追加するPowerShellスクリプトを作成してください。実行時の前提条件として、gMSAアカウント（DOMAIN\adfs_gmsa$）を使用し、エラー発生時のTry-Catch構文と詳細なログ出力（C:\logs配下）を必ず含めてください。」

2. Claude 3.5 Sonnet：複雑なトラブルシューティングとログの相関解析

「LVSのDR方式でパケットが戻ってこない」「ADFSのイベントログ（ID 364や1200）でSAMLトークンの発行に失敗している」といった、OSレイヤーを跨いだ複雑な障害解析には、Claude 3.5 Sonnetの高い論理的推論力とコード解釈能力が非常に有用です。

【効果的なプロンプト例】
「現在M365へのSSOが失敗しています。以下にLinux側のLVSマスターノードで取得した `tcpdump -n -i eth0 port 443` の出力結果（SYNは飛んでいるがACKが返らない）と、WindowsのADFSサーバーで抽出したイベントビューアのXMLエラーログ（ID 364）を貼り付けます。ネットワークルーティング（ARPフラックスやファイアウォール）の問題か、それとも証明書のチェーン検証失敗（TLSハンドシェイク失敗）のどちらに根本原因があるか、パケットのシーケンスとログを照らし合わせて論理的に分析してください。」

3. Gemini 1.5 Pro：超大容量コンテキストを用いたアーキテクチャ全体のレビュー

Gemini 1.5 Proは、最大200万トークンという桁違いのコンテキストウィンドウを持っています。これは、設計書や公式ドキュメントを「丸ごと」読み込ませて分析させる用途に最適です。

自社の「詳細ネットワーク構成図（PDF）」「LVSの全設定ファイル（keepalived.conf, sysctl.conf）」「MicrosoftのADFS展開・セキュリティベストプラクティスガイド（PDF）」をすべて同時にプロンプトへアップロードし、「この現在の設計構成におけるトラフィックのボトルネック、SPOF（単一障害点）、およびサイバー攻撃（DDoSやパスワードスプレー攻撃）に対するセキュリティ上の脆弱性を網羅的にリストアップし、改善案を提示して」といった、シニアコンサルタントレベルの包括的なシステムレビューを依頼することが可能です。

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

本記事では、LinuxエンジニアがM365ハイブリッド認証を本格的に学ぶための第一歩として、以下の重要なアーキテクチャ要件と技術的本質を解説しました。

• ハイブリッド環境の境界とIdP/SPモデル： M365（Entra ID）と既存のオンプレミスADDSをセキュアに連携させるためには、ADFSやWAPといった中継コンポーネントが必須であり、これらはIdPとして機能する。
• 認証トラフィックとプロトコルの変換： レガシーな社内認証（Kerberos/LDAP）を、クラウドサービスが理解できるモダンな認証トークン（SAML/WS-Fed）へ安全に変換・署名するプロセスがフェデレーションの正体である。
• Linux技術の高度な応用（LVS/DR方式）： ADFSファームの超高可用性を担保するためには、LinuxのIPVS技術（LVS/Keepalived）によるLayer4での精緻なロードバランシングが極めて有効。DR方式におけるWindows側のARPフラックス回避（ストロングホスト設定）と、/adfs/probe を用いた正確なL7ヘルスチェックがインフラの明暗を分ける。
• 生成AIの戦略的活用とプロンプトエンジニアリング： OSを跨ぐ複雑なインフラ設計やトラブルシューティングにおいて、GPT-4o、Claude 3.5、Gemini 1.5といったAIモデルをそれぞれの強みに合わせて適材適所で使い分けることが、モダンなインフラエンジニアの必須スキルである。

次回の【第2回】では、いよいよ検証環境として「Windows Server 2025 Standard」を用いて、すべての認証のコアとなる「ADDS（Active Directory Domain Services）」をゼロから実際に構築し、そこにLinuxサーバー（Ubuntu/RHELベース）からLDAPおよびKerberosで連携を行う、より実践的でコマンドヘビーな手順に踏み込んでいきます。ハイブリッドインフラ基盤の確固たる土台を固める非常に重要なフェーズですので、ぜひご期待ください！