【第3回】Windows Server 2025：ADFS（フェデレーションサーバー）の構築と証明書管理

前回の第2回では、すべての認証の源泉となる「Active Directory Domain Services (ADDS)」をWindows Server 2025上に構築し、Linuxエンジニアの視点からFSMO（操作マスター）やマルチマスター・レプリケーションといったディレクトリサービスのコアアーキテクチャを解き明かしました。

今回は、いよいよM365（Entra ID）とオンプレミス環境をつなぐ「架け橋」であり、シングルサインオン（SSO）の要となる「ADFS（Active Directory Federation Services：フェデレーションサーバー）」の構築フェーズへと進みます。

ADFSは、社内のADDSの認証情報を「SAML（Security Assertion Markup Language）」や「WS-Federation」といったインターネット標準のプロトコルに変換し、クラウドサービスへ安全に引き渡す「IdP（Identity Provider）」の役割を果たします。Linux環境で言えば「Keycloak」や「Shibboleth」に相当するミドルウェアです。本記事では、エンタープライズのベストプラクティスである「gMSA（グループ管理サービスアカウント）」の導入から、厳格なSSL/TLS証明書の管理、そしてPowerShellを用いた完全自動化構築まで、プロのインフラエンジニアに求められる高度な設計と実装を圧倒的な情報密度で徹底解説します。

---

1. ADFS (Active Directory Federation Services) とは何か？

ハイブリッド認証アーキテクチャの中核を担うADFSですが、その実態は一体何なのでしょうか。まずは、SAML認証のプロトコルレベルからADFSの役割を解剖します。

1-1. M365における「トークン発行局（IdP）」としての役割

ADFSは、M365（Entra ID）などのクラウドサービス（Relying Party：RP、またはService Provider：SPと呼ばれます）に対して、ユーザーの身元を保証するIdentity Provider (IdP)として機能します。

ユーザーがブラウザでM365（ポータルサイトやOutlook on the webなど）にアクセスすると、M365は「あなたの認証情報はあなたの会社のADFSにあるはずだから、そこで認証してきなさい」とリダイレクト（HTTP 302）させます。ADFSは社内のADDS（ドメインコントローラー）と通信してユーザー名とパスワード（または証明書）を検証し、正しければ「クレーム（Claims：ユーザーの属性情報）」を含んだ暗号化されたデジタルトークンを発行します。ユーザーのブラウザはこのトークンをM365に提示し、晴れてログインが完了します。この「パスワードをクラウドに渡さず、署名付きトークンだけを渡す」というメカニズムが、フェデレーション（信頼関係）認証の根幹です。

1-2. Linuxエンジニアから見たADFS（Keycloak / Shibbolethとの比較）

Linux環境でOSSを用いて同様のSSO（シングルサインオン）基盤を構築する場合、Red Hatが支援する「Keycloak」や、学術機関で広く使われている「Shibboleth」が代表的です。

これらとADFSを比較した場合、ADFSの最大の強みは「Windows統合認証（WIA：Windows Integrated Authentication）」とのシームレスな連携にあります。社内LANに接続された社給のWindows PC（Active Directory参加済み）からADFSにアクセスした場合、ユーザーはブラウザでID・パスワードを手入力することなく、Kerberosチケットを用いて「意識させずに（サイレントに）」M365へログインさせることが可能です。この圧倒的なユーザー体験（UX）の向上こそが、企業がADFSを選択する最大の理由です。

一方で、設定ファイル（XML等）を直接編集するKeycloak等とは異なり、ADFSの設定はすべてSQL Server（またはWID：Windows Internal Database）に格納され、PowerShellコマンドレットまたはGUIの管理ツール経由で操作するという特徴があります。インフラのコード化（IaC）を行う上では、この「PowerShellによるAPI操作」を前提としたアプローチが必要です。

1-3. SAML 2.0とWS-Federationプロトコルの基礎構造

ADFSは複数の認証プロトコルをサポートしていますが、M365との連携においては主に「WS-Federation」または「SAML 2.0」が使用されます。

SAMLプロトコルにおけるメッセージ（SAML Assertion）は、XML形式で記述され、以下の重要な要素を含みます。

• Subject: 誰に関する情報か（例：ユーザーのUPN taro@linuxkoubou.com）
• Conditions: このトークンの有効期限（NotBefore, NotOnOrAfter）
• Issuer: 誰がこのトークンを発行したか（ADFSの識別子URL）
• Signature: データの改ざんを防ぐためのデジタル署名（後述する「トークン署名証明書」の秘密鍵で署名される）

Linuxエンジニアとしては、トラブルシューティングの際に「ブラウザの開発者ツール（F12）」やSAML Tracer等の拡張機能を用いて、このXMLペイロードのBase64エンコードをデコードし、署名（Signature）の不一致や時刻のズレ（Conditions）をパケットレベルで解析するスキルが求められます。

2. ADFS構築の前提条件と証明書（SSL/TLS）の厳格な設計

ADFSをインストールする前に、設計段階で絶対に間違えてはいけないのが「ファーム名」と「SSL/TLSサーバー証明書」の設計です。ここを誤ると、後戻りのできない再構築が必要になることがあります。

2-1. ADFSファーム名とDNSレコードの設計原則

ADFSは通常、複数台のサーバーで構成される「ファーム（Farm）」として構築し、前段にLVS等のロードバランサーを配置します。そのため、クライアント（ユーザーのブラウザ）がアクセスするURLは、個別のサーバー名（例：adfs01.linuxkoubou.local）ではなく、ロードバランサーのVIPに向く「サービス通信名（ファーム名）」となります。

一般的に、このファーム名には sts.ドメイン名 または fs.ドメイン名 が用いられます（stsはSecurity Token Serviceの略）。

• 例：sts.linuxkoubou.com

この名前は、社内DNS（ADDS）では「社内のLVSの内部VIP」を指し、インターネット上のパブリックDNSでは「DMZに配置されるWAPの外部VIP」を指すように、スプリットブレインDNSとして設計する必要があります。

2-2. サーバー証明書の要件（ワイルドカード vs SANs）

ADFSサーバーには、HTTPS通信を暗号化するためのSSL/TLS証明書（サービス通信証明書）が必要です。この証明書の「サブジェクト名（CN）」または「サブジェクト代替名（SAN：Subject Alternative Name）」には、必ず上記のファーム名（sts.linuxkoubou.com）が含まれている必要があります。

さらに、ADFSには「Device Registration Service（デバイス登録サービス）」という機能が内包されており、これを利用する場合は証明書のSANに enterpriseregistration.linuxkoubou.com も追加しておくことがMicrosoftのベストプラクティスとされています。

証明書の種類としては以下の2パターンが考えられます。

1. ワイルドカード証明書（*.linuxkoubou.com）： 運用は楽ですが、万が一秘密鍵が漏洩した場合、すべてのサブドメインが危険に晒されるため、ゼロトラストを前提とする現代のエンタープライズセキュリティ基準では非推奨とされることが多いです。
2. SANs（マルチドメイン）証明書： CNに sts.linuxkoubou.com、SANに enterpriseregistration.linuxkoubou.com を明示的に指定した証明書。こちらが推奨です。

2-3. 自己署名証明書の罠とパブリックCAの必要性

Linux環境の検証でよく使う openssl req -x509 で生成した「自己署名証明書（オレオレ証明書）」や、社内のプライベート認証局（エンタープライズCA）から発行した証明書は、ADFSの「サービス通信証明書」としては絶対に使用してはいけません。

理由は単純です。ADFSのログイン画面には、インターネット上のあらゆるデバイス（社員の自宅PC、スマートフォンなど）からアクセスが来ます。これらのデバイスは社内CAのルート証明書を信頼していないため、ブラウザで「この接続ではプライバシーが保護されません」という致命的なセキュリティ警告が表示され、M365アプリからのアクセスもブロックされます。必ず、GlobalSign、DigiCert、Let’s Encrypt等のパブリックな認証局（Public CA）から発行された正規の証明書を用意してください。証明書は .pfx 形式（秘密鍵付き）でエクスポートし、ADFSサーバーの「ローカルコンピューターの個人ストア」にインポートしておきます。

3. エンタープライズの鉄則：gMSA（グループ管理サービスアカウント）の導入

ADFSを動かすための「Windowsサービス」の実行アカウント（Run As）設計は、セキュリティ上極めて重要です。

3-1. なぜ通常のドメインユーザーではなくgMSAを使うのか？

これまで、多くのシステム管理者は「ADFS_Service」といった通常のドメインユーザーを作成し、「パスワードを無期限にする」にチェックを入れてサービスの実行アカウントに指定していました。しかし、これは「Pass-the-Hash（ハッシュ情報の使い回し）」攻撃や、退職者によるパスワードの持ち出しリスクがつきまとう、非常に脆弱な設計です。

そこで導入されたのがgMSA（Group Managed Service Account：グループ管理サービスアカウント）です。gMSAは、Active Directory自身が「複雑な120文字のパスワードを自動生成し、30日ごとに自動で変更（ローテーション）する」という特殊なアカウントです。パスワードは人間には一切分かりません。Linuxにおける「ログイン不可のシステムアカウント（useradd -s /sbin/nologin）」をネットワークレベルでさらに高度化・セキュアにしたものと理解してください。現在、ADFSファームを構築する際はgMSAの使用がMicrosoftの公式要件となっています。

3-2. KDSルートキーの生成と伝播待ち（PowerShell手順）

gMSAを利用するためには、まずフォレスト内に「キー配信サービス（KDS）のルートキー」を生成する必要があります。これはドメインコントローラー（第2回で構築したサーバー）上で1回だけ実行する作業です。

# ドメインコントローラー（DC01）のPowerShellを管理者権限で実行

# KDSルートキーの生成
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

※本来、ルートキーを生成してから全DCにレプリケーションされるまで「10時間」待機する必要がありますが、検証環境や新規構築時においてすぐにgMSAを使いたい場合は、上記のように -EffectiveTime に過去の時間を指定して強制的に有効化するテクニック（バックデート手法）が使われます。

3-3. gMSAアカウントの作成とADFSサーバーへの権限委譲

ルートキーが生成できたら、ADFSサービスを実行するためのgMSAアカウントを作成します。このアカウントを使用できるコンピューター（ADFSサーバー群）を明示的に指定することで、権限の悪用を防ぎます。

# ADFSサーバーのコンピューターオブジェクトをまとめるセキュリティグループを作成
New-ADGroup -Name "ADFS_Servers" -GroupCategory Security -GroupScope Global

# ADFSサーバー（例: ADFS01, ADFS02）をグループに追加
Add-ADGroupMember -Identity "ADFS_Servers" -Members "ADFS01$", "ADFS02$"

# gMSAアカウントの作成（"ADFS_Servers"グループにのみパスワードの取得を許可する）
New-ADServiceAccount -Name "gmsa_adfs" -DNSHostName "sts.linuxkoubou.com" -PrincipalsAllowedToRetrieveManagedPassword "ADFS_Servers"

これで、ADFSサーバーをインストールする準備が完全に整いました。

4. Windows Server 2025：ADFSのインストールとファーム構成（PowerShell）

ここからは、ADFSサーバー（ホスト名：ADFS01.linuxkoubou.local）にログインし、PowerShellを用いて役割のインストールとファームの初期構成を行います。

4-1. ADFSサーバー役割のインストールと証明書のインポート

まずはサーバーマネージャーのGUIを使わず、PowerShellコマンド一発でADFSのバイナリをインストールします。

# ADFSサーバー（ADFS01）のPowerShellを管理者権限で実行

# ADFSの役割（Role）と管理ツールをインストール
Install-WindowsFeature -Name ADFS-Federation -IncludeManagementTools

次に、事前にパブリックCAから取得しておいたSSL/TLS証明書（cert.pfx）を、Windowsの「ローカルコンピューターの個人ストア」にインポートします。GUI（mmc）でインポートしても良いですが、PowerShellでも可能です。

# 証明書のパスワードを指定してセキュアストリングに変換
$certPassword = ConvertTo-SecureString -String "YourCertPassword!" -Force -AsPlainText

# PFX証明書をローカルコンピューターの証明書ストアにインポート
$cert = Import-PfxCertificate -FilePath "C:\temp\cert.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password $certPassword

# インポートした証明書のサムプリント（Thumbprint：ハッシュ値）を変数に格納（後で使用）
$thumbprint = $cert.Thumbprint

4-2. ADFSファームの初期構成スクリプトとパラメータ解説

証明書が準備できたら、ADFSファームを構成します。バックエンドのデータベースには、小〜中規模環境向けの「WID（Windows Internal Database）」を使用します。

# ADFSファームの初期構成（1台目）
Install-AdfsFarm `
    -CertificateThumbprint $thumbprint `
    -FederationServiceDisplayName "LINUX工房 認証ポータル" `
    -FederationServiceName "sts.linuxkoubou.com" `
    -GroupServiceAccountIdentifier "linuxkoubou\gmsa_adfs$" `
    -OverwriteConfiguration:$true

各パラメータの解説：

• -CertificateThumbprint: 先ほどインポートしたSSL証明書のハッシュ値を指定します。ADFSはこの証明書をIIS（HTTP.sys）にバインドします。
• -FederationServiceDisplayName: ユーザーがログイン画面を開いた際に表示される組織名です。
• -FederationServiceName: ADFSファームのURL（FQDN）です。証明書のSANと一致している必要があります。
• -GroupServiceAccountIdentifier: 前項で作成したgMSAアカウントを指定します。末尾の $ マークを忘れないでください。

コマンドを実行すると、背後でHTTP.sysの設定、WIDデータベースの構築、自己署名による「トークン署名証明書」の自動生成などが行われ、再起動が要求されます。

4-3. サービスプリンシパル名（SPN）の自動登録メカニズム

Kerberos認証において、クライアントが「どのサービスに対して認証を要求しているか」を特定するための識別子がSPN（Service Principal Name）です。LinuxにおけるKerberosの keytab ファイルの設定に似ています。

ADFSをgMSAで構成すると、通常はADFSのセットアップスクリプトが自動的に HOST/sts.linuxkoubou.com というSPNをgMSAアカウントに対して登録します。このSPNが正しく登録されていないと、社内からのWindows統合認証（SSO）が失敗し、ブラウザ上で何度もパスワード認証のダイアログ（Basic認証風のプロンプト）が出現するという最悪のトラブルに見舞われます。

手動でSPNの登録状況を確認するには、ドメインコントローラーで以下のコマンドを実行します。

# gMSAアカウントに登録されているSPNを確認
setspn -L linuxkoubou\gmsa_adfs$

5. 構築後の動作確認とセキュリティ強化ベストプラクティス

インストールが完了したら、M365と連携する前にADFS単体での動作テストとセキュリティ強化（ハードニング）を行います。

5-1. IdP-Initiated Sign-Onページの有効化とブラウザテスト

ADFSには、ユーザーが自分からADFSにアクセスしてサインインのテストを行うことができる「IdP-Initiated Sign-On」ページという隠し機能があります。セキュリティ上の理由からデフォルトでは無効化されているため、PowerShellで有効化します。

# ADFSのプロパティを変更し、IdP-Initiated Sign-Onページを有効化
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

社内の検証端末のブラウザから https://sts.linuxkoubou.com/adfs/ls/idpinitiatedsignon.htm にアクセスします。証明書エラーが出ず、青いログイン画面が表示され、ADユーザーの認証情報で「サインイン済み」というメッセージが出れば、ADFSの基本構築は完璧に成功しています。

5-2. 監査ログ（Auditing）の有効化とLinux Syslogへの転送布石

セキュリティインシデント（パスワードリスト攻撃など）が発生した際、ADFSのログは最も重要な証跡となります。しかし、デフォルトでは監査ログは無効化されています。

# ADFSの監査ログ出力を有効化
Set-AdfsProperties -AuditLevel Verbose
auditpol /set /subcategory:"アプリケーションの生成" /success:enable /failure:enable

これを有効にすることで、Windowsの「イベントビューアー（セキュリティログ）」にADFSの認証成功・失敗の生ログが記録されるようになります。本連載の第8回では、これをFluentdやNXLogを用いてLinux上のZabbix/Elasticsearch等（Syslogサーバー）へ転送し、一元監視する基盤を構築します。

5-3. トークン署名証明書の自動ロールオーバー（AutoCertificateRollover）の理解

ADFSには、通信を暗号化する「サービス通信証明書（パブリックCA発行）」とは別に、SAMLトークンの改ざんを防ぐためのデジタル署名を行う「トークン署名証明書（Token-Signing Certificate）」と「トークン暗号化証明書（Token-Decrypting Certificate）」が存在します。

これら2つの証明書は、デフォルトではADFSが内部的に「自己署名証明書（有効期限1年）」として自動生成します。そして、有効期限の20日前になると、自動的に新しい証明書を生成し、プライマリ証明書として切り替える機能（AutoCertificateRollover）がデフォルトで有効になっています。

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

本記事では、Linuxエンジニアの視点から「ADFS（フェデレーションサーバー）」の役割をSAMLプロトコルのレベルから解き明かし、証明書の厳格な設計、gMSAを用いたセキュアなサービスアカウントの導入、そしてPowerShellを用いた完全なCUI構築手順を解説しました。

「Active Directoryはクリックばかりでインフラのコード化（IaC）ができない」という思い込みは、現代のWindows Serverにおいては完全に時代遅れです。PowerShellを活用し、パラメーターを明確に定義することで、Ansible等のツールから一貫性のあるIdP基盤を自動構築することが可能です。また、SAMLのAssertion構造やKerberosのSPNといった認証プロトコルの深層を理解することは、トラブルシューティングにおいてOSを問わない普遍的な武器となります。

しかし、今回構築したADFSは、あくまで「社内ネットワークの安全な場所」に存在する認証エンジンに過ぎません。次回の【第4回】Windows Server 2025：DMZへのWAP（Web Application Proxy）構築では、インターネットの荒波からこのADFSを守るための「防波堤」となるリバースプロキシ（WAP）をDMZに構築し、外部からの認証トラフィックを安全に中継する強固なゲートウェイ設計に挑みます。お楽しみに！