ADFSとは

ADFS（Active Directory Federation Services）
Microsoftが提供するシングルサインオン（SSO）およびフェデレーション認証の仕組み。
Windows Serverの役割（ロール）の1つとして提供され異なる組織間や異種のシステム間で認証を統合するために使われる

ADFSの主な特徴

シングルサインオン（SSO）
- 1度認証すれば複数のアプリケーションやサービスに再認証なしでアクセス可能
フェデレーション認証
- 異なる組織やクラウドサービス（例：Azure AD、AWS、Google Workspace）とIDを連携できる
セキュリティトークンを使用
- OAuth、OpenID Connect、SAMLなどの標準プロトコルを利用
オンプレミス環境での運用
- クラウド認証（Azure ADなど）とは異なりオンプレミスのWindows Server上で動作
多要素認証（MFA）やアクセス制御
- Azure MFAやカスタムポリシーと連携可能

フェデレーション
異なる認証システムや組織間でID情報を連携しシングルサインオン（SSO）を実現する仕組みのこと

ADFSの主な構成要素

ADFSは複数のコンポーネントで構成されている

ADFSサーバー
- 認証要求を処理しトークンを発行する
- ユーザーの認証情報をActiveDirectoryと照合
ADFSプロキシ（WAP:Web Application Proxy）
- インターネットから認証欲求を内部のADFSサーバーに中継
- DMZに配置されることが多い
ActiveDirectory
- ユーザー情報を保持する認証基盤
Relying Party（RP：信頼されたアプリケーション）
- ADFSから認証トークンを受け取るアプリやサービス（Microsoft365 、Salesforce）
Claims Provider（クレームプロバイダー）
- ユーザーの属性情報をトークンに含める

コンポーネント
システムやソフトウェア、ハードウェアなどの構成要素の一部を指す。単体で特定の機能を持ち複数のコンポーネントが組み合わさることでシステム全体が動作するようになる
プロキシ
クライアント（ユーザー）とサーバーの間に入る中継役（代理）のことを指す。クライアントが直接サーバーにアクセスするのではなくプロキシを経由して通信を行う
DMZ
Demilitarized Zine、非武装地帯
内部ネットワーク（社内LAN）と外部ネットワーク（インターネット）の間に設置する中間ゾーン。企業ネットワークで外部に公開するサーバー（Webサーバー、メールサーバー、プロキシサーバーなど）安全に配置するために使用される
クレームプロバイダー
ユーザー認証を行い、ユーザー認証情報（クレーム）を発行する仕組み。主なクレームプロバイダーはADFS、Azure AD、Google、Okta。

ADFSの認証フロー

ユーザーがアプリ（Relying Party）にアクセス
アプリはADFSにリダイレクトし認証を要求
ADFSはActiveDirectoryに問い合わせてユーザーを認証
認証成功後、ADFSがトークンを発行しユーザーをアプリへリダイレクト
アプリがトークンを検証しユーザーをログインさせる

ADFSを使うべきケース

近年、ADFSを使わずにAzure ADに直接統合する企業が増えている。その中でもADFSを使うべきケースは

オンプレミスのActiveDirectoryが必須
- 既存のActiveDirectory認証をそのまま利用したい
クラウド認証を完全に移行できない
- 既存のアプリケーションがAzure ADと直接統合できない
高度なカスタム認証要件がある
- 特定の認証ポリシーやSAMLカスタマイズが必要

ADFSの構成要素

ADFSを導入するには以下のコンポーネントが必要

コンポーネント	説明
AD FS サーバー	認証要求を処理し、セキュリティトークンを発行する。
Web Application Proxy（WAP）	DMZに配置し、インターネットからの認証要求を内部のAD FSに中継する。
Active Directory（AD）	ユーザー情報を管理し、AD FSが認証情報を取得する。
SQL Server（オプション）	AD FSの設定データを保存（大規模環境向け）。
Windows Internal Database（WID）	AD FSの構成データを管理（小規模環境向け、SQL Serverの代替）。
リライングパーティ（Relying Party, RP）	AD FSから認証トークンを受け取るサービス（例：Microsoft 365, AWS）。
クレームプロバイダー（Claims Provider, CP）	ユーザー情報を取得し、認証トークンを作成する（例：Active Directory）。
ロードバランサー（オプション）	AD FSやWAPの冗長化のために使用。

ADFSの導入手順

①前提条件

Windows Server 2016/2019/2022（ADFSはWindows Serverの役割として提供）
Active Directory（AD）環境構築済
SSL証明書（ADFSのフェデレーションサービス名に対応）
サーバー名とDNS設定
- 例：
  - ADFSサーバー名→adfs.contoso.com
  - WAPサーバー名→wap.contoso.com

②SSL証明書の準備

ADFSにはSSL証明書が必須

社内環境のみの場合
- 内部認証局（CA)で自己署名証明書を発行

③ADFSのインストール

Windows ServerにADFSをインストール

[サーバーマネージャー] を開く
[役割と機能の追加] をクリック
[Active Directory フェデレーションサービス（AD FS）] を選択
必要なコンポーネント（IIS, .NET Framework など）をインストール
サーバーを再起動

AD FSの構成

[サーバーマネージャー] → [AD FSの構成] をクリック
新しいフェデレーションサービスの作成
- adfs.contoso.com を指定
証明書を選択（事前に準備したSSL証明書）
サービスアカウントの作成
- CONTOSO\adfs_svc（ADのサービスアカウントを作成）
設定を適用し、構成を完了

④Web Application Proxy（WAP）の構成（外部アクセス用）

WAPはDMZに配置し、インターネットからの認証要求をAD FSに中継

📌 WAPの役割

外部からの認証リクエストを受け付け、内部のAD FSに中継
AD FSサーバーを直接外部に公開せずに済むため、セキュリティ強化

WAPのインストール手順

[サーバーマネージャー] → [リモートアクセス] をインストール
[Web Application Proxy] の役割を追加
WAPをAD FSと接続
- AD FSのフェデレーションサービスadfs.contoso.comを指定
- AD FSの管理者アカウントで認証
設定を完了し、サービスを開始

AD FSの設定と管理

①Relying Party Trust（リライングパーティ信頼）の追加

フェデレーション先のアプリケーション（例：Microsoft 365, AWS, Salesforce）を登録

AD FS管理コンソールを開く
[リライングパーティ信頼] を右クリック → [追加]
[SAML 2.0] または [OAuth 2.0 / OpenID Connect] を選択
サービスプロバイダーのメタデータを入力
クレームルールを設定
適用して完了

②クレームルールの設定

クレームルールを設定し、送信するユーザー情報を定義

例：ユーザーのUPNを送信

[発行変換ルール] → [ルールの追加]
[LDAP属性としてクレームを送信] を選択
属性: User-Principal-Name（UPN）
クレームの種類: Name ID
適用

動作確認

✅ 内部アクセスの確認
https://adfs.contoso.com/adfs/ls/IdpInitiatedSignon.aspx にアクセス
ログイン画面が表示されるか確認

✅ 外部アクセスの確認
https://wap.contoso.com/adfs/ls/IdpInitiatedSignon.aspx にアクセス
WAP経由で認証できるか確認

✅ リライングパーティの動作確認
例：Microsoft 365, AWS, Salesforceにログインできるかテスト

まとめ

1️⃣ AD FSをインストール（Windows Serverに追加）
2️⃣ SSL証明書を設定（adfs.contoso.com）
3️⃣ WAP（Web Application Proxy）を構成（DMZに配置）
4️⃣ リライングパーティ信頼を設定（Microsoft 365, AWSなど）
5️⃣ クレームルールを設定（ユーザー情報を送信）
6️⃣ テストして動作確認（SSOが機能するか検証）