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
- ADFSサーバー名→
- 例：
②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のフェデレーションサービス
- 設定を完了し、サービスを開始
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が機能するか検証）