【第1回】LinuxエンジニアのためのM365認証基盤構築：ADFS・WAPとAlmaLinux 9 LVSの全体アーキテクチャ

近年、多くの企業がオンプレミス環境からクラウドへと業務基盤を移行しており、その中心となるのが「Microsoft 365 (M365)」です。これに伴い、社内のActive Directory（AD）とクラウド上のEntra ID（旧Azure AD）を連携させる「ハイブリッド認証環境」の構築が、エンタープライズインフラにおける必須要件となっています。

「Windowsサーバーの認証周りは、Windowsエンジニアの仕事だろう」と考えるLinuxエンジニアも多いかもしれません。しかし、M365の認証トラフィックを安全かつ高速に処理するためのフロントエンドには、強固なリバースプロキシやロードバランサー（L4/L7スイッチ）が不可欠です。ここで、Linuxカーネルに組み込まれた極めて高性能な負荷分散技術である「LVS (Linux Virtual Server)」と、安定性に定評のある「AlmaLinux 9」の知識が強力な武器となります。

本連載「LinuxエンジニアのためのM365認証」では、全8回にわたり、Windows Server 2025を用いた最新のADDS/ADFS/WAP環境の構築から、AlmaLinux 9を用いた高可用性LVSロードバランサーの実装、そして監視・トラブルシューティングに至るまで、インフラエンジニアとして知っておくべき「認証と負荷分散のベストプラクティス」をプロの視点で徹底的に解説します。第1回となる今回は、ハイブリッド認証の全体像と、各コンポーネントの役割、そしてアーキテクチャ設計の要諦を紐解いていきます。

---

1. M365ハイブリッド認証の基礎と全体像

企業がMicrosoft 365（Exchange Online、SharePoint Online、Teamsなど）を導入する際、最も重要となるのが「ユーザーがどのようにログインするか」という認証の設計です。クラウド上のEntra ID（旧Azure AD）に直接ユーザーを作成してパスワードを管理する「クラウドオンリー」構成もありますが、一定規模以上の企業では、社内のActive Directory（オンプレミスAD）とパスワードやアカウント情報を一元管理する「ハイブリッド認証」が標準的に採用されます。

1-1. なぜLinuxエンジニアがWindowsの認証基盤を学ぶのか

「Linuxサーバーしか触らないからADは関係ない」というのは、現代のインフラエンジニアとしては非常に危険な思考です。現在、Linux環境で稼働するApacheやNginx、各種Webアプリケーション（GitLab、Redmine、Zabbixなど）においても、SAML 2.0やOpenID Connect（OIDC）を利用した「M365（Entra ID）経由のシングルサインオン（SSO）」を実装することが当たり前になっています。

つまり、M365の認証基盤がダウンすれば、Windows PCへのログインだけでなく、Linux上の業務システムへのアクセスもすべて停止してしまうのです。インフラ全体の可用性を担保するSRE（Site Reliability Engineer）として、ハイブリッド認証のトラフィックフローと障害ポイントを正確に理解しておくことは、システム障害時の迅速な切り分け（トラブルシューティング）において致命的な差を生みます。

1-2. M365における「フェデレーション認証」の仕組み（SAML/WS-Fed）

オンプレミスADとM365を連携させるハイブリッド認証には、主に「パスワードハッシュ同期（PHS）」「パススルー認証（PTA）」「フェデレーション認証（ADFS）」の3つの方式があります。本連載では、エンタープライズ企業で最も高度なセキュリティポリシー（クライアント証明書認証、アクセス元のIP制限、デバイス制御など）をオンプレミス側で強制できる「フェデレーション認証（ADFS方式）」をターゲットとします。

フェデレーション（Federation：信頼関係）認証とは、M365（Entra ID）自体ではパスワード認証を行わず、「認証の処理を社内のADFSサーバーに丸投げ（リダイレクト）する」方式です。
ユーザーがブラウザでM365にアクセスすると、Entra IDは「あなたの会社のADFSで認証して、発行されたSAMLトークン（またはWS-Federationトークン）を持ってきなさい」と指示し、ユーザーのブラウザを社内のWAP/ADFSへとリダイレクトさせます。この「トークン（暗号化された証明書のようなもの）の受け渡し」によってSSOが成立します。このトラフィックはすべてHTTPS（TCP 443）で行われるため、プロトコルレベルでの理解がLinuxエンジニアにも容易に適用できるのです。

1-3. ADDS, ADFS, WAP, Entra ID の役割と連携メカニズム

Windows Server 2025環境において、フェデレーション認証基盤は以下の4つのコンポーネントで構成されます。それぞれの役割を正確に把握してください。

• ADDS（Active Directory Domain Services）:
  オンプレミスネットワークの内部に配置される、認証の「源泉」です。ユーザー名、パスワード、所属グループなどのデータベースを持ちます。ここが全ての権限のマスターとなります。
• ADFS（Active Directory Federation Services）:
  内部ネットワークに配置される「クレームプロバイダー（トークン発行局）」です。ADDSと連携してユーザーのパスワードが正しいかを確認し、正しければ「このユーザーは認証済みである」という署名付きのトークン（SAML/WS-Fed）を発行してブラウザに返します。
• WAP（Web Application Proxy）:
  DMZ（非武装地帯）に配置されるリバースプロキシです。インターネット上にいるユーザーからの認証リクエストを最初に受け止め、内部のADFSへ安全に中継（プロキシ）します。絶対にADFSを直接インターネットに公開してはいけません。
• Entra ID（旧 Azure AD）:
  Microsoftクラウド側のディレクトリサービスです。ADFSから渡されたトークン（署名）が、事前に登録されている証明書と一致するかを検証し、M365の各サービスへのアクセス権を付与します。

2. 認証基盤の要、WAP（Web Application Proxy）とは

インターネットから社内ネットワークへの入り口を守る門番、それがWAP（Web Application Proxy）です。Windows Serverの標準機能（リモートアクセスロールの一部）として提供されています。

2-1. ADFSを直接公開しない理由とリバースプロキシの役割

前述の通り、ADFSサーバーはドメイン参加が必須であり、ADDS（ドメインコントローラー）と密接に通信します。もしインターネットから直接ADFSが攻撃を受け、脆弱性を突かれて侵入された場合、攻撃者はそこを踏み台にしてADDSを掌握（ドメインの乗っ取り）することが可能になってしまいます。

WAPは、ADFSの「プロキシ（代理）」としてDMZに配置されます。WAP自体はADドメインに参加する必要がない（ワークグループ環境で動作可能）ため、万が一WAPが侵害されても、社内ADへの直接的な被害を食い止めることができます。WAPは外部からのHTTPS通信を受信し、パケットを検証した上で、内部のADFSに対して新しいHTTPSセッションを張り直します。

2-2. WAPを通じたパススルー認証と事前認証の動作原理

WAPは単なるリバースプロキシ（例えばNginxの proxy_pass や、Apacheの ProxyPass）以上の機能を持ちます。M365認証においてWAPは主に「パススルー」モードで構成され、ADFS宛のトラフィック（/adfs/ls/ など）を透過的に内部へ転送します。

さらに高度な使い方として、社内のWebアプリケーションを外部公開する際に「事前認証（Pre-Authentication）」を行うことも可能です。これは、ユーザーがWebアプリにアクセスしようとした際、WAPがまずADFSにリダイレクトさせて認証を行わせ、認証が成功したユーザーだけを社内Webアプリへ通す仕組みです。これにより、脆弱なレガシーWebアプリをインターネットの脅威から守ることができます。

2-3. エクストラネットロックアウトによるセキュリティ対策

WAPを導入する最大のセキュリティ上のメリットの一つが「エクストラネットロックアウト（Extranet Lockout）」機能です。
悪意のある攻撃者が、インターネットから社員のアカウントに対してパスワードの総当たり攻撃（ブルートフォース攻撃）やパスワードスプレー攻撃を仕掛けてきたとします。もしこの認証要求がそのまま内部のADDSに到達してしまうと、ADDSの標準機能である「アカウントロックアウト」が発動し、当該社員が社内ネットワークからも一切ログインできなくなってしまいます（サービス拒否攻撃：DoS状態）。

WAPとADFSを連携させることで、「インターネット（エクストラネット）からの間違ったパスワード入力」を独自のしきい値でカウントし、ADDSのアカウントロックアウトが発動する手前で、WAP側で認証要求を遮断（ロックアウト）することができます。これにより、社内からの正常なアクセスは保護されつつ、外部からの攻撃のみを無効化するという高度な防御が実現します。最新のWindows Server 2025環境では、このエクストラネットロックアウト機能がより高度化され、スマートロックアウトとしてEntra IDのセキュリティインテリジェンスと連携することも可能です。

3. WAPの負荷分散にAlmaLinux 9 + LVSを採用する理由

WAPはインターネットからのすべての認証トラフィックを受け止めるため、1台のWAPサーバーではパフォーマンスの限界があり、また単一障害点（SPOF：Single Point of Failure）となってしまいます。そこで、複数台のWAPサーバーの前段にロードバランサー（負荷分散装置）を配置します。

3-1. 商用ハードウェアロードバランサー vs Linux Virtual Server (LVS)

エンタープライズ環境において、F5 BIG-IPやCitrix ADC（NetScaler）といった商用のハードウェアアプライアンスを導入するのは一般的です。しかし、これらは数百万〜数千万円の莫大なコストがかかります。クラウド（IaaS）上であればAWS ALB等を利用できますが、オンプレミス環境やプライベートクラウド環境において、「単にWAPへのTCP 443（HTTPS）通信を負荷分散したいだけ」の要件に対して商用機器はオーバースペックです。

そこで白羽の矢が立つのが、Linuxカーネル（Netfilter）に組み込まれたネイティブの負荷分散モジュールである「IPVS (IP Virtual Server)」をコア技術とするLVS (Linux Virtual Server)です。AlmaLinux 9上でLVSを構築し、Keepalived デーモンを用いて冗長化（Active/Standby構成）することで、商用アプライアンスに匹敵する、いやそれ以上のパケット処理性能を持つロードバランサーを「OSSのみ・コストゼロ」で構築することが可能です。

3-2. L4ロードバランシング（IPVS）の圧倒的なパフォーマンス

NginxやHAProxyのようなL7ロードバランサーは、ユーザーモード（ユーザー空間）のプロセスとして動作し、一度TCPコネクションを終端（Terminate）してから、バックエンドのサーバーへ新しいコネクションを張ります。これにはCPUリソースとメモリを消費します。

一方、LVS（IPVS）はLinuxカーネル空間で動作するL4スイッチです。IPアドレスとポート番号（レイヤ4）だけを見て、パケットの内容（HTTPヘッダーなど）を開かずにそのままバックエンド（WAP）へルーティングするため、パケット処理のオーバーヘッドが極小化されます。M365の朝の始業時間帯など、数万人の社員が一斉にログインを試みる「ログインストーム」が発生しても、AlmaLinux 9のLVSであればCPU使用率数%で余裕でさばき切ることができます。

3-3. DSR（Direct Server Return）方式か、NAT方式かのアーキテクチャ選択

LVSで負荷分散を行う際、ネットワークのルーティング方式として主に「NAT方式（VS/NAT）」と「DSR方式（VS/DR）」の2つがあります。設計上、ここが最もLinuxエンジニアの腕の見せ所となります。

• NAT方式 (Virtual Server via NAT):
  クライアントからLVS（VIP：仮想IP）宛に届いたパケットの宛先IPを、WAP（DIP：実サーバーIP）に書き換えて転送します。WAPからの戻りパケットも必ずLVSを経由し、LVSが送信元IPをVIPに書き換えてクライアントに返します。ネットワーク構成はシンプルになりますが、すべての戻りトラフィックがLVSを経由するため、LVS自体がボトルネックになる可能性があります。
• DSR方式 (Virtual Server via Direct Routing):
  クライアントからLVSに届いたパケットの宛先MACアドレスだけを書き換え、WAPへ転送します。WAPはLVSと同じVIPをループバックインターフェース等に持たせておき、パケットを処理します。最大の利点は、WAPからの戻りパケットがLVSを経由せず、直接クライアント（またはデフォルトゲートウェイ）に返される点です。M365認証において、ADFSから発行されるSAMLトークンはサイズが大きくなることがありますが、DSR方式であればLVSのネットワーク帯域を消費せず、極めて高いスループットを実現できます。

本連載では、構築の難易度はやや上がりますが、エンタープライズ環境でベストプラクティスとされる「NAT方式」を基本として解説を進めます。理由は、WAP（Windows Server）側にループバックアダプタを設定し、ARP応答を抑制する設定（Linuxでいう arp_ignore, arp_announce の調整）がWindows環境では運用上煩雑になりやすいため、安定稼働を優先してNAT方式（またはインライン構成）を選択するのが現場での定石だからです。

4. Windows Server 2025とAlmaLinux 9の混在環境設計ベストプラクティス

全体のコンポーネントが出揃ったところで、具体的なネットワーク設計と証明書の配置について、アーキテクチャの要件を定義します。

4-1. ネットワークセグメントの分離（DMZと内部ネットワーク）

強固なセキュリティを担保するため、ネットワークは明確に2つのセグメントに分離します。

1. DMZ（非武装地帯）セグメント：
   インターネットからアクセス可能なセグメントです。ここにAlmaLinux 9で構築した「LVS（ロードバランサー）」の仮想IP（VIP）を配置し、さらにその後段に「WAPサーバー（複数台）」を配置します。インターネットからのファイアウォール（境界ルーター）では、LVSのVIPに対する TCP 443 (HTTPS) のみを許可します。（※証明書の失効リスト確認等のために HTTP TCP 80 を許可する場合もありますが、基本は443のみです）。
2. 内部ネットワークセグメント：
   インターネットからは完全に遮断されたセグメントです。ここに「ADFSサーバー（複数台）」と「ADDS（ドメインコントローラー）」を配置します。内部向けにもADFS用のロードバランサー（内部LVS）を配置するのがベストです。

DMZから内部ネットワークへの通信（WAPからADFSへの通信）は、DMZと内部ネットワークを隔てる内部ファイアウォールにおいて、TCP 443 (HTTPS) のみを開放します。WAPはADドメインに参加しないため、RPCダイナミックポートなどの複雑なポートを開放する必要はありません。

4-2. SSL/TLS証明書の管理とLVSのトランスペアレント（透過的）通信

M365の認証（SAMLフェデレーション）において、証明書の扱いは極めて重要かつトラブルの温床になりやすいポイントです。
M365（Entra ID）側には「あなたの会社のADFSの公開URL（フェデレーションサービス名。例：sts.linuxkoubou.com）」を登録し、そのURLに対するSSL/TLS証明書が必要になります。

この証明書は、LVSにはインストールしません。なぜなら、LVSはL4（トランスポート層）で動作するため、SSLの暗号化を解読（ターミネーション）せず、TCPパケットのまま透過的（トランスペアレント）にWAPへ受け流すからです。証明書をインストールし、SSLターミネーションを行うのは「WAP」および「ADFS」サーバー上です。

Linuxエンジニアは、NginxやApacheでSSLを設定することに慣れていますが、このアーキテクチャでは「AlmaLinux 9 (LVS) 側では証明書を持たず、証明書の更新作業はWindows Server (WAP/ADFS) 側で一元管理される」という設計思想を理解しておく必要があります。これにより、インフラチームの運用境界が明確になります。

4-3. ファイアウォール（firewalld）とルーティングの厳格な要件

AlmaLinux 9側（LVS）の設定において、最も注意すべきは firewalld とカーネルのIPフォワード設定です。LVS（IPVS）はカーネルのルーティング機能を活用してパケットを転送するため、AlmaLinux 9自身がルーターとして機能するよう、カーネルパラメータを変更する必要があります。

# LVSとして動作させるためにAlmaLinux 9のIPフォワードを有効化する設定例
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-ipforward.conf
sysctl -p /etc/sysctl.d/99-ipforward.conf

また、KeepalivedによるVRRP（Virtual Router Redundancy Protocol）通信を許可するために、firewalld に対してVRRPプロトコルの通過を許可するリッチルールを追加しなければ、LVSの冗長構成（スプリットブレインの防止）が正常に動作しません。これらは第5回のLVS構築編で詳細なコマンドとともに解説します。

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

本記事では、「LinuxエンジニアのためのM365認証」連載の第1回として、Windowsベースの認証コンポーネント（ADDS、ADFS、WAP）の役割と、それをフロントで支えるAlmaLinux 9ベースのLVS（ロードバランサー）の全体アーキテクチャについて解説しました。

ハイブリッド認証環境は、単一のサーバーで完結するものではありません。SAML認証というプロトコルの上で、Linuxのネットワーク制御技術（IPVSパケットルーティング）とWindowsの高度な認証機能（ADFS、エクストラネットロックアウト）が美しく連携することで、初めて数万人規模のエンタープライズに耐えうる堅牢なシステムが完成します。OSの違いに固執せず、適材適所で最高の技術を組み合わせる「アーキテクト」の視点を持つことが、次世代のインフラエンジニアには求められています。

次回、【第2回】Windows Server 2025：ADDSドメインコントローラーの構築と設計では、全ての認証の源泉となる「Active Directory」の構築に入ります。最新のWindows Server 2025を対象に、Linuxエンジニアにも分かりやすくドメインの概念から具体的な構築手順までを解説していきます。お楽しみに！