【第3回】ADFSとWAPの役割、WIDとSQL Serverバックエンドの設計ベストプラクティス

前回の第2回では、Windows Server 2025を用いた認証のコアであるADDS（Active Directory Domain Services）の構築と、Linuxサーバー（Ubuntu/RHEL）からSSSDを用いたセキュアなLDAP/Kerberos連携の手法を解説しました。これで「社内のアイデンティティの源泉」は完成しました。

連載第3回となる今回は、この社内ネットワークの奥深くにあるADDSと、インターネット上のクラウドサービス（Entra ID / M365）を安全に結びつけるための最重要コンポーネント、ADFS（Active Directory Federation Services）とWAP（Web Application Proxy）のアーキテクチャ設計に踏み込みます。

さらに、ADFSファームの構成情報を格納するバックエンドデータベースとして、標準の「WID (Windows Internal Database)」を選択すべきか、あるいはエンタープライズ向けの「SQL Server」を選択すべきか。インフラエンジニアの設計思想が問われるこの選択基準と、IaC（Infrastructure as Code）を意識したPowerShellによるプロフェッショナルな構築手法を徹底的に解剖していきます。

コウ君

リナックス先生！ADDSができたから、あとはM365と同期ツール（Entra ID Connect）で繋ぐだけでいいんじゃないんですか？わざわざADFSサーバーと、さらにDMZにWAPサーバーを立てて、データベースまで用意するなんて……構成が複雑すぎて運用できる気がしません。

リナックス先生

コウ君、その複雑さにはすべて「セキュリティとスケーラビリティ」という明確な理由があるのよ。ADFSはクレーム（要求）を生成する頭脳、WAPは外部の攻撃を弾く堅牢な盾、そしてデータベースはファーム全体の状態を同期するための中枢神経よ。LinuxのWeb3層アーキテクチャ（リバースプロキシ・App・DB）と同じだと考えれば、スッと理解できるはずよ。さあ、それぞれの役割を深く掘り下げていくわよ！

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

1. ADFS（クレームプロバイダー）の高度な役割とクレームルール

ADFS（Active Directory Federation Services）は、Windows環境における最強の「IdP（Identity Provider）」です。前回の記事で構築したADDSは社内ネットワーク（LAN）向けのKerberos/LDAP認証しか理解できませんが、インターネット上に存在するM365（Entra ID）などのSaaSは、SAML 2.0、WS-Federation、OAuth 2.0、OpenID Connect（OIDC）といったモダンなWebプロトコルを要求します。

ADFSの最大の役割は、「社内のKerberos認証」を「外部向けのSAML/WS-Fedトークン（暗号化されたXMLまたはJWT）」に変換することです。このトークンの中には「クレーム（Claims：要求）」と呼ばれるユーザー属性情報が詰め込まれています。

クレームルール言語（Claims Rule Language）の強力さ

なぜパスワード同期（Entra ID Connect単体）ではなく、わざわざADFSを構築する企業が多いのでしょうか。その最大の理由は、ADFSが持つ強力な「クレームルールエンジン」にあります。
クレームルールは、正規表現を利用した特殊なスクリプト言語で記述され、「誰が、どこから、どのような条件でアクセスしてきたか」を極めて細かく制御できます。以下は、プロの現場で実際に使用されるアクセス制御の例です。

  • 社内IPからのアクセス制御： クライアントの送信元IPアドレス（x-ms-forwarded-client-ip）を判定し、社内のグローバルIP以外からのアクセスを一切拒否する。
  • 特定のActive Directoryグループのみ許可： ADDSの特定のセキュリティグループ（例: “M365_Users”）に属しているユーザーにのみ、SAMLトークンを発行する。
  • デバイス証明書認証： 会社が配布したクライアント証明書（TLS相互認証）を持っている端末からのアクセスのみを許可する。

⚠️ Linuxエンジニア視点でのポイント：証明書のライフサイクル管理
ADFSが発行するSAMLトークンは、ADFS自身が持つ「トークン署名証明書（Token-Signing Certificate）」の秘密鍵でデジタル署名されます。Entra ID側はこの証明書の公開鍵を持っており、署名を検証します。
デフォルト設定では、この証明書は有効期限が近づくと自動的に新しいものにロールオーバー（更新）されます。しかし、Entra ID側のメタデータ更新が追いつかないと「署名検証エラー」となり、全社員がM365にログインできなくなる大規模障害（通称：ADFS証明書爆弾）が発生します。監視システム（Zabbix等）でADFSのイベントログ（ID 315 / 316など）をフックする監視設計が不可欠です。

2. WAP（Web Application Proxy）によるDMZ境界防御アーキテクチャ

ADFSは、ADDS（ドメインコントローラー）と直接通信してパスワード検証を行うため、内部ネットワークの非常に深い層に配置されます。これをインターネットに直接公開する（NATでポート443をフォワードする）ことは、セキュリティ上「自殺行為」です。
そこで、外部（インターネット）と内部ネットワークを隔てるDMZ（DeMilitarized Zone：非武装地帯）に配置されるのが WAP（Web Application Proxy） です。

WAPの機能：単なるリバースプロキシではない

Linuxエンジニアであれば、WAPを「NginxやHAProxyのようなL7リバースプロキシ」と捉えると理解しやすいでしょう。インターネットからの HTTPS (TCP 443) トラフィックはすべてWAPで終端（SSL Offloadまたは再暗号化）され、WAPが内部のADFSへプロキシします。
しかし、WAPは単なるプロキシではありません。以下の強力なセキュリティ機能を備えています。

  1. 事前認証（Pre-Authentication）： バックエンドのWebアプリケーション（社内ポータル等）を公開する際、WAPの段階でADFSと連携し、認証されていない不正なパケットを内部ネットワークに一切通しません。
  2. エクストラネット スマートロックアウト（ESL）： 外部から大量のパスワードブルートフォース攻撃を受けた際、社内のADDSアカウントがロックされてしまうのを防ぐため、WAP/ADFSのレイヤーで攻撃元のIPアドレスを一定時間ブロック（ソフトロックアウト）します。
  3. SNI（Server Name Indication）の厳密なルーティング： WAPはTLSの拡張仕様であるSNIを解釈し、ヘッダ内のホスト名（例: sts.linuxkoubou.local）がADFS公開名と一致しない不正なリクエストをドロップします。

ネットワーク要件として、WAPから内部ネットワークのADFSに対しては TCP 443 (HTTPS) のみが許可されていればよく、ADDSへのアクセス（TCP 389/88等）は一切不要です。これにより、ファイアウォールのルールを極限まで絞り込むことができます。

3. ADFSバックエンドDB設計：WID vs SQL Serverの完全比較

ADFSファーム（複数台のADFSサーバー群）を構築する際、インフラエンジニアは最初の構築ウィザードで非常に重要な決断を迫られます。構成情報や証明書情報、リプレイ検出のキャッシュを保存するデータベースとして、WID（Windows Internal Database） を使うか、SQL Server を使うか、という選択です。

Linux環境における「組み込みのSQLiteを使うか、外部のPostgreSQLクラスタを使うか」という選択に似ていますが、ADFSにおいては機能面で明確な差異が生じます。

WID (Windows Internal Database) の特徴

WIDは、Windows Serverに標準で組み込まれている軽量なリレーショナルデータベースです。

  • アーキテクチャ： 1台目のADFSサーバーが「プライマリノード（Read/Write）」となり、2台目以降は「セカンダリノード（Read Only）」となります。セカンダリノードは定期的にプライマリノードからHTTP（またはTCP 443）経由でデータをプル（Pull）して同期します。
  • メリット： ライセンス費用が不要。別途DBサーバーを構築・運用する手間が省け、非常にシンプル。
  • デメリット： プライマリノードがダウンすると、残ったセカンダリノードで認証処理自体は継続できますが、ADFSの設定変更や証明書の更新が一切できなくなります。また、ノード数は最大30台までという制限があります。

SQL Server の特徴

外部に構築したSQL Server（Always On 可用性グループ等で冗長化）を利用する構成です。

PR

［試して理解］Linuxのしくみ　-実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 [ 武内 覚 ]

価格:3520円
(2026/7/17 18:56時点)
感想(1件)

  • アーキテクチャ： すべてのADFSノードがSQL Serverに対して直接Read/Writeを行います。プライマリ・セカンダリという概念が存在しません。
  • メリット： 高度なスケーラビリティ。また、「SAMLアーティファクト解決（Artifact Resolution）」と「トークンリプレイ検出（Token Replay Detection）」という高度なセキュリティ機能は、SQL Server環境でしかサポートされません。（WIDではノード間で即時同期ができないため、リプレイ攻撃を防ぎきれないためです）。
  • デメリット： SQL Serverの高可用性設計（フェールオーバークラスタリングやAlways On）の手間と、高額なライセンス費用がかかります。
コウ君

なるほど……WIDはシンプルだけどプライマリが落ちると設定変更ができなくなる。SQL Serverは強力だけどコストが高いんですね。一般的な企業ではどちらを選ぶべきなんでしょうか？

リナックス先生

プロの現場におけるベストプラクティスとしては、ユーザー数が数万人規模であったり、セキュリティ要件でSAMLアーティファクトバインディングが必須でなければ、圧倒的に「WID」が推奨されるわ。M365へのフェデレーション用途であればWIDの機能で十分事足りるし、何よりDBレイヤーの障害ポイントを減らすことで、全体の可用性（SLA）を高く保てるからね。

4. セキュリティベストプラクティス：gMSA（グループ管理サービスアカウント）の導入

ADFSを構築する際、ADFSサービス（Windowsのバックグラウンドプロセス）を実行するための権限アカウントが必要になります。
過去には、通常のドメインユーザーアカウント（例: adfs_svc）を作成し、「パスワードを無期限にする」という運用が横行していました。しかし、これはゼロトラスト時代において重大な脆弱性となります。

Windows Server 2025においてプロのエンジニアが必ず採用するのが「gMSA（Group Managed Service Account：グループ管理サービスアカウント）」です。
gMSAを使用すると、以下の圧倒的なメリットが得られます。

  • パスワードの自動管理： 120文字の複雑なパスワードをADDSが自動生成し、30日ごとに自動で変更（ローテーション）してくれます。人間がパスワードを知る必要は一切ありません。
  • 複数サーバーでの共有： ADFSファーム内のすべてのノードで同じgMSAを安全に使い回すことができます。
  • SPN（サービスプリンシパル名）の自動管理： Kerberos認証に必須となるSPNの登録・更新を自動で行ってくれます。

gMSAを利用しないADFS構築は、エンタープライズの現場では「設計不良」と見なされるため、必ず導入しましょう。

5. PowerShellによるADFSファーム（WID版）の構築手順（IaC）

それでは、ここまでの設計思想をコードに落とし込みます。WIDをバックエンドとし、gMSAを利用したADFSファーム（プライマリノード）の構築をPowerShellで実行します。GUIウィザードは使用せず、IaC（Infrastructure as Code）の観点からコマンドラインで完結させます。

ステップ1：KDSルートキーの生成（初回のみ）

gMSAを作成するためには、ADDS（ドメインコントローラー）側でKDS（Key Distribution Service）ルートキーを生成する必要があります。ドメインコントローラー上で一度だけ実行します。

# ドメインコントローラー上で実行（検証環境用に即時有効化するコマンド）
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

ステップ2：gMSAの作成と権限付与

ADFSサーバー群が利用するgMSAアカウントを作成します。

# ドメインコントローラー上で実行
# ADFSサーバーのコンピューターオブジェクトをグループにまとめている前提 (例: ADFS_Servers_Group)
New-ADServiceAccount -Name "adfs_gmsa" -DNSHostName "sts.linuxkoubou.local" -PrincipalsAllowedToRetrieveManagedPassword "ADFS_Servers_Group"

ステップ3：ADFSサーバーでのインストールと初期構成

ここからはADFSサーバー（例: adfs01.linuxkoubou.local）での作業です。事前に公的認証局（または内部CA）から発行されたSSL証明書（ワイルドカードまたは sts.linuxkoubou.local）をIISにインポート（秘密鍵付きの.pfx形式）しておく必要があります。

# 1. ADFSのサーバー役割をインストール
Install-WindowsFeature -Name ADFS-Federation -IncludeManagementTools

# 2. SSL証明書のThumbprint（拇印）を取得（事前にインポート済みであること）
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.linuxkoubou.local"}
$thumbprint = $cert.Thumbprint

# 3. ADFSファームのプライマリノードをWIDとgMSAを用いて構築
# 実行後、システムが自動的にWIDのデータベースを構成し、サービスを起動します。
Install-AdfsFarm `
    -CertificateThumbprint $thumbprint `
    -FederationServiceName "sts.linuxkoubou.local" `
    -GroupServiceAccountIdentifier "linuxkoubou\adfs_gmsa$" `
    -OverwriteConfiguration:$true

コマンドが正常に終了すると、バックグラウンドでWID（##SSEE または MICROSOFT##WID インスタンス）が構築され、ADFSサービスが起動します。構築が成功したかを確認するためには、ブラウザでADFSのメタデータエンドポイントにアクセスします。

# ADFSメタデータの確認URL（ブラウザでXMLが表示されれば構築成功）


https://sts.linuxkoubou.local/FederationMetadata/2007-06/FederationMetadata.xml
sts.linuxkoubou.local

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

本記事では、M365認証の要となるADFSとWAPのアーキテクチャ、およびバックエンドデータベースの設計について、プロのインフラエンジニア視点で解説しました。

  • ADFSの役割： 社内のKerberos認証をクラウド向けにSAML/WS-Fedトークンに変換し、高度なクレームルールでアクセス制御を行う頭脳。
  • WAPの役割： インターネット境界（DMZ）で事前認証とSNIルーティングを行い、内部のADFSを攻撃から守る堅牢なリバースプロキシ。
  • WID vs SQL Server： エンタープライズにおける一般的なM365連携であれば、可用性の観点からもシンプルで堅牢な「WID（Windows Internal Database）」の採用がベストプラクティス。
  • セキュリティの鉄則： ADFSのサービスアカウントには、自動でパスワードがローテーションされる「gMSA」を必ず利用すること。

ここまでで、IdPとして機能するADFSファームの「単一ノード」が立ち上がりました。しかし、このままではこのサーバーがダウンした瞬間に全社員の認証が停止してしまいます。

次回の【第4回】では、今回構築したADFS/WAPに対して、我々Linuxエンジニアの最強の武器であるLVS (Linux Virtual Server) と Keepalived を前段に配置し、Layer4 (DR方式) による「超高可用性ロードバランシング」を実装する手順に踏み込みます。ARPフラックス問題の回避や、正確なSSLヘルスチェックのチューニングなど、ネットワークエンジニア垂涎のディープな技術解説をお届けしますので、ご期待ください！

▼ 【インフラ環境を構築しよう！スキルアップを目指すエンジニアへ】 ▼

Windows/Linux両対応！検証に最適な
「高コスパおすすめVPS」

VPSランキングを見る

ハイブリッド環境の知見を活かそう
「ITエンジニア専門転職」

転職エージェントを見る

コメント