AD FS の要件
Active Directory フェデレーション サービス (AD FS) を展開するための要件を次に示します。
5\. コマンド プロンプトで、「ipconfig /all」と入力して Enter キーを押します。
証明書の要件
TLS または SSL 証明書
各 AD FS および Web アプリケーション プロキシ サーバーには、フェデレーション サービスへの HTTPS 要求を処理する TLS/SSL 証明書があります。 Web アプリケーション プロキシには、発行されたアプリケーションへの要求を処理するための追加の証明書をインストールすることができます。
TLS/SSL 証明書の推奨事項
すべての AD FS フェデレーション サーバーと Web アプリケーション プロキシに同じ TLS/SSL 証明書を使用します。
TLS/SSL 証明書の要件
フェデレーション サーバーの TLS/SSL 証明書は、次の要件を満たしている必要があります。
- 証明書が公的に信頼されています (運用環境のデプロイの場合)
- 証明書にサーバー認証の拡張キー使用法 (EKU) の値が含まれています。
- サブジェクトまたはサブジェクトの別名 (SAN) に
fs.contoso.comなどのフェデレーション サービス名が証明書に含まれています。 - ポート 443 でのユーザー証明書認証の場合、証明書に SAN の
certauth.fs.contoso.comなどのcertauth.\<federation service name\>が含まれています。 - デバイスの登録、または Windows 10 より前のクライアントを使用したオンプレミス リソースへの先進認証の場合、SAN には、組織で使用されている各ユーザー プリンシパル名 (UPN) サフィックスの
enterpriseregistration.\<upn suffix\>が含まれている必要があります。
Web アプリケーション プロキシの TLS/SSL 証明書は、次の要件を満たしている必要があります。
- プロキシを使用して Windows 統合認証を使用する AD FS 要求をプロキシする場合、プロキシ TLS/SSL 証明書はフェデレーション サーバーの TLS/SSL 証明書と同じである (同じキーを使用している) 必要があります。
- AD FS プロパティ ExtendedProtectionTokenCheck が有効な場合 (AD FS の既定の設定)、プロキシ TLS/SSL 証明書はフェデレーション サーバーの TLS/SSL 証明書と同じである (同じキーを使用している) 必要があります。
- それ以外の場合、プロキシ TLS/SSL 証明書の要件は、フェデレーション サーバーの TLS/SSL 証明書の要件と同じです。
サービス通信証明書
この証明書は、Microsoft Entra ID や Office 365 などのほとんどの AD FS シナリオで必要ありません。 既定で、AD FS では、初期の構成時に提供される TLS/SSL 証明書がサービス通信証明書として構成されます。
サービス通信証明書の推奨事項
- TLS/SSL に使用するものと同じ証明書を使用します。
トークン署名証明書
この証明書は、証明書利用者に発行されたトークンに署名するために使用されるため、証明書利用者アプリケーションでは、証明書とそれに関連付けられたキーを既知で信頼できるものとして認識する必要があります。 有効期限が切れたときなど、トークン署名証明書が変更されたときに、新しい証明書を構成すると、すべての証明書利用者を更新する必要があります。
トークン署名証明書に関する推奨事項
AD FS の既定である、内部生成された自己署名トークン署名証明書を使用します。
トークン署名証明書の要件
- 組織で、エンタープライズ公開キー基盤 (PKI) からの証明書をトークン署名に使用する必要がある場合、Install-AdfsFarm コマンドレットの SigningCertificateThumbprint パラメーターを使用してこの要件を満たすことができます。
- 既定の内部生成された証明書を使用する場合、または外部登録された証明書を使用する場合のいずれでも、トークン署名証明書が変更されるときに、新しい証明書情報ですべての証明書利用者が更新されるようにする必要があります。 そうしないと、証明書利用者はサインインできません。
トークン暗号化および暗号化解除証明書
この証明書は、AD FS に対して発行されたトークンを暗号化する要求プロバイダーによって使用されます。
トークン暗号化/暗号化解除証明書に関する推奨事項
AD FS の既定である、内部生成された自己署名トークン暗号化解除の証明書を使用します。
トークン暗号化/暗号化解除証明書の要件
- 組織で、エンタープライズ PKI からの証明書をトークン署名に使用する必要がある場合、Install-AdfsFarm コマンドレットの DecryptingCertificateThumbprint パラメーターを使用してこの要件を満たすことができます。
- 既定の内部生成された証明書を使用する場合、または外部登録された証明書を使用する場合のいずれでも、トークン暗号化解除証明書が変更されるときに、新しい証明書情報ですべての要求プロバイダーが更新されるようにする必要があります。 そうしないと、更新されていない要求プロバイダーを使用したサインインは失敗します。
注意事項
証明書のうち、トークン署名やトークン暗号化解除および暗号化に使用されるものは、フェデレーション サービスの安定性にきわめて重要です。 独自のトークン署名とトークンの暗号化解除/暗号化証明書を管理するお客様は、これらの証明書がバックアップされ、回復イベントの発生時に個別に使用できることを確認する必要があります。
ユーザー証明書
- AD FS で x509 ユーザー証明書認証を使用する場合、すべてのユーザー証明書は、AD FS および Web アプリケーション プロキシ サーバーから信頼されているルート証明機関までチェーンする必要があります。
ハードウェア要件
AD FS および Web アプリケーション プロキシのハードウェア要件 (物理または仮想) は CPU に左右されいるため、処理能力に合わせてファームのサイズを調整する必要があります。
- AD FS 2016 容量計画スプレッドシートを使用して、必要な AD FS および Web アプリケーション プロキシ サーバーの数を決定します。
AD FS のメモリとディスクの要件はほとんど静的です。 要件については、以下の表を参照してください。
| ハードウェア要件 | 最小要件 | 推奨要件 |
|---|---|---|
| RAM | 2 GB | 4 GB |
| ディスク領域 | 32 GB | 100 GB |
SQL Server のハードウェア要件
AD FS 構成データベースに Azure SQL を使用している場合は、SQL Server の最も基本的な推奨事項に従って SQL Server のサイズを変更します。 AD FS データベースのサイズは小さく、AD FS によってデータベース インスタンスに大きな処理負荷がかかることはありません。 ただし、AD FS は認証時にデータベースに複数回接続するので、ネットワーク接続を堅牢にする必要があります。 残念ながら、AD FS 構成データベースの SQL Azure はサポートされていません。
プロキシの要件
エクストラネット アクセスの場合は、リモート アクセス サーバー ロールの一部である Web アプリケーション プロキシ ロール サービスをデプロイする必要があります。
サード パーティのプロキシでは、AD FS プロキシとしてサポートされる MS-ADFSPIP プロトコルがサポートされている必要があります。 サードパーティ ベンダーの一覧については、AD FS についてよくある質問 (FAQ) を参照してください。
AD FS 2016 には、Windows Server 2016 上の Web アプリケーション プロキシ サーバーが必要です。 2016 ファームの動作レベルで実行されている AD FS 2016 ファームには、ダウンレベル プロキシを構成できません。
フェデレーション サーバーと Web アプリケーション プロキシの役割サービスを同じコンピューターにインストールすることはできません。
AD DS 要件
ドメイン コントローラーの要件
AD FS には、Windows Server 2008 以降を実行しているドメイン コントローラーが必要です。
Windows Hello for Business には、少なくとも 1 つの Windows Server 2016 ドメイン コントローラーが必要です。
注意
Windows Server 2003 ドメイン コントローラーを使用する環境のすべてのサポートが終了しました。 詳細については、Microsoft ライフサイクル情報を参照してください。
ドメイン機能レベルの要件
すべてのユーザー アカウント ドメインと AD FS サーバーが参加しているドメインは、Windows Server 2003 以降のドメインの機能レベルで動作している必要があります。
クライアント証明書が AD DS のユーザーのアカウントに明示的にマップされている場合、その証明書の認証には Windows Server 2008 のドメイン機能レベル以上が必要です。
スキーマの要件
AD FS 2016 の新規インストールには、Active Directory 2016 スキーマ (最小バージョン 85) が必要です。
AD FS ファームの動作レベル (FBL) を 2016 レベルに上げるには、Active Directory 2016 スキーマ (最小バージョン 85) が必要です。
サービス アカウントの要件
任意の標準ドメイン アカウントを AD FS のサービス アカウントとして使用できます。 グループのマネージド サービス アカウントもサポートされています。 AD FS を構成するときに、実行時に必要なアクセス許可が自動的に追加されます。
AD サービス アカウントに必要な [ユーザー権利の割り当て] は、[サービスとしてログオン] です。
NT Service\adfssrvとNT Service\drsに必要な [ユーザー権利の割り当て] は、[セキュリティ監査の生成] および [サービスとしてログオン] です。グループのマネージド サービス アカウントには、Windows Server 2012 以降を実行しているドメイン コントローラーが少なくとも 1 つ必要です。 グループのマネージド サービス アカウント (gMSA) は、既定の
CN=Managed Service Accountsコンテナー以下に存在する必要があります。Kerberos 認証の場合、サービス プリンシパル名 '
HOST/<adfs\_service\_name>' が AD FS サービス アカウントに登録されている必要があります。 既定では、新しい AD FS ファームを作成するときに AD FS によってこの要件が構成されます。 このプロセスが失敗すると (衝突やアクセス許可不足の場合など)、警告が表示され、手動で追加する必要があります。
ドメインの要件
すべての AD FS サーバーは、AD DS ドメインに参加している必要があります。
ファーム内のすべての AD FS サーバーを同じドメインにデプロイする必要があります。
AD FS ファームの最初のノードのインストールは、PDC が使用可能かどうかによって異なります。
複数フォレストの要件
AD FS サーバーが参加しているドメインは、AD FS サービスに対して認証を行うユーザーを含むすべてのドメインまたはフォレストを信頼する必要があります。
AD FS サービス アカウントがメンバーであるフォレストは、すべてのユーザー サインイン フォレストを信頼する必要があります。
AD FS サービス アカウントには、AD FS サービスに対して認証を行うユーザーを含むすべてのドメインのユーザー属性を読み取るアクセス許可が必要です。
構成データベースの要件
このセクションでは、Windows Internal Database (WID) または SQL Server をデータベースとしてそれぞれ使用する AD FS ファームの要件と制限について説明します。
WID
SAML 2.0 のアーティファクト解決プロファイルは、WID ファームではサポートされていません。
トークン リプレイ検出は、WID ファームではサポートされていません。 AD FS がフェデレーション プロバイダーとして機能し、外部要求プロバイダーからセキュリティ トークンを使用するシナリオで、この機能が使用されます。
WID と SQL Server ファームでサポートされている AD FS サーバーの数の概要を次の表に示します。
| 1-100 個の RP 信頼 | 100 個を超える RP 信頼 |
|---|---|
| 1-30 個の AD FS ノード: WID サポート対象 | 1-30 個の AD FS ノード: WID の使用はサポート対象外 - SQL が必要 |
| 30 個を超える AD FS ノード: WID の使用はサポート対象外 - SQL が必要 | 30 個を超える AD FS ノード: WID の使用はサポート対象外 - SQL が必要 |
SQL Server
Windows Server 2016 の AD FS では、SQL Server 2008 以降のバージョンがサポートされています。
SQL Server ファームでは、SAML アーティファクト解決とトークン リプレイ検出の両方がサポートされています。
ブラウザー要件
ブラウザーまたはブラウザー コントロールを介して AD FS 認証を実行する場合、ブラウザーは次の要件を満たしている必要があります。
JavaScript を有効にする必要があります。
シングル サインオンの場合、Cookie を許可するようにクライアント ブラウザーを構成する必要があります。
Server Name Indication (SNI) をサポートする必要があります。
ユーザー証明書とデバイス証明書の認証の場合、ブラウザーは TLS/SSL クライアント証明書認証をサポートする必要があります。
Windows 統合認証を使用してシームレスにサインインするには、ローカル イントラネット ゾーンまたは信頼済みサイト ゾーンにフェデレーション サービス名 (
https:\/\/fs.contoso.comなど) を構成する必要があります。
ネットワークの要件
ファイアウォールの要件
Web アプリケーション プロキシとフェデレーション サーバー ファームの間にあるファイアウォールと、クライアントと Web アプリケーション プロキシ間にあるファイアウォールの両方で、受信方向の TCP ポート 443 を有効にする必要があります。
また、クライアント ユーザー証明書認証 (X509 ユーザー証明書を使用した clientTLS 認証) が必要で、certauth エンドポイントでポート 443 が有効になっていない場合。 AD FS 2016 では、クライアントと Web アプリケーション プロキシの間のファイアウォールで TCP ポート 49443 受信を有効にする必要があります。 これは、Web アプリケーション プロキシとフェデレーション サーバーの間のファイアウォールには適用されません。
ハイブリッド ポートの要件の詳細については、ハイブリッド ID の必要なポートとプロトコルに関する記事を参照してください。
詳細については、「Best practices for securing Active Directory Federation Services」 (Active Directory フェデレーション サービスのセキュリティ保護に関するベスト プラクティス) を参照してください。
DNS の要件
イントラネット アクセスの場合、社内ネットワーク イントラネット内の AD FS サービスにアクセスするすべてのクライアントでは、AD FS サービス名を、AD FS サーバーのロード バランサーまたは AD FS サーバーに解決できる必要があります。
エクストラネット アクセスの場合、社内ネットワークの外部エクストラネットまたはインターネットから AD FS サービスにアクセスするすべてのクライアントでは、AD FS サービス名を、Web アプリケーション プロキシ サーバーのロード バランサーまたは Web アプリケーション プロキシ サーバーに解決できる必要があります。
非武装地帯 (DMZ) 内の各 Web アプリケーション プロキシ サーバーでは、AD FS サービス名を、AD FS サーバーのロード バランサーまたは AD FS サーバーに解決できる必要があります。 この構成を作成するには、DMZ ネットワーク内の代替ドメイン ネーム システム (DNS) サーバーを使用するか、HOSTS ファイルを使用するローカル サーバーの解決を変更します。
Windows 統合認証では、フェデレーション サービス名に CNAME ではなく DNS A レコードを使用する必要があります。
ポート 443 でのユーザー証明書認証の場合、フェデレーション サーバーまたは Web アプリケーション プロキシに解決するするように "certauth.<federation service name>" を DNS で構成する必要があります。
デバイス登録または Windows 10 より前のクライアントを使用しているオンプレミス リソースへの先進認証の場合、組織で使用されている各 UPN サフィックスの
enterpriseregistration.\<upn suffix\>を構成して、フェデレーション サーバーまたは Web アプリケーション プロキシに解決されるようにする必要があります。
ロード バランサーの要件
- ロード バランサーでは TLS/SSL を終了できません。 AD FS では、TLS/SSL を終了するときに中断する証明書認証を使用する複数のユース ケースがサポートされます。 ロード バランサーでの TLS/SSL の終了は、どのユース ケースでもサポートされていません。
- SNI をサポートするロード バランサーを使用します。 そうでない場合は、回避策として、AD FS または Web アプリケーション プロキシ サーバーで 0.0.0.0 フォールバック バインディングを使用することをお勧めします。
- (HTTPS ではなく) HTTP 正常性プローブ エンドポイントを使用して、トラフィックのルーティングに対してロード バランサーの正常性チェックを実行します。 この要件により、SNI に関連する問題が回避されます。 これらのプローブ エンドポイントへの応答は HTTP 200 OK であり、バックエンド サービスに依存せずにローカルで提供されます。 HTTP プローブには、「/adfs/probe」のパス を使用して HTTP 経由でアクセスできます
http://<Web Application Proxy name>/adfs/probehttp://<AD FS server name>/adfs/probehttp://<Web Application Proxy IP address>/adfs/probehttp://<AD FS IP address>/adfs/probe
- 負荷分散の方法として DNS ラウンド ロビンを使用することはお勧めしません。 この種類の負荷分散を使用しても、正常性プローブを使用してロード バランサーからノードを自動的に削除することはできません。
- ロード バランサー内の AD FS への認証トラフィックに IP ベースのセッション アフィニティまたは固定セッションを使用することはお勧めしません。 これにより、メール クライアントから Office 365 メール サービス (Exchange Online) に接続するためにレガシ認証プロトコルを使用している場合、特定のノードが過負荷になる可能性があります。
アクセス許可の要件
AD FS のインストールと初期構成を実行する管理者には、AD FS サーバーに対するローカル管理者のアクセス許可が必要です。 ローカル管理者が Active Directory にオブジェクトを作成するアクセス許可を持っていない場合、まずドメイン管理者が必要な AD オブジェクトを作成し、次に AdminConfiguration パラメーターを使用して AD FS ファームを構成する必要があります。