Windows Server の AD FS 要件

[アーティクル]
02/13/2024
適用対象:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

AD FS の展開時に従う必要があるさまざまな要件を次に示します。

5\. コマンドプロンプトで、「ipconfig /all」と入力して Enter キーを押します。
ハードウェア要件
ソフトウェア要件
AD DS の要件
構成データベースの要件
ブラウザーの要件
エクストラネットの要件
ネットワークの要件
属性ストアの要件
アプリケーションの要件
認証の要件
Workplace join の要件
暗号化の要件
アクセス許可の要件

証明書の要件

証明書は、フェデレーションサーバー、Web アプリケーションプロキシ、要求対応アプリケーション、および Web クライアント間の通信のセキュリティを確保するうえで最も重要な役割を果たします。証明書の要件は、このセクションで説明するように、フェデレーションサーバーとプロキシコンピューターのどちらをセットアップするかによって異なります。

フェデレーションサーバーの証明書

証明書の種類	要件、サポート、知っておくべきこと
Secure Sockets Layer (SSL) 証明書: これは標準の SSL 証明書であり、フェデレーションサーバーとクライアントの間の通信のセキュリティ確保に使用されます。	- この証明書は、公的に信頼された* X509 v3 証明書である必要があります。 - AD FS エンドポイントにアクセスするすべてのクライアントは、この証明書を信頼する必要があります。パブリック (サードパーティ) 証明機関 (CA) によって発行された証明書を使用することが強く推奨されます。テストラボ環境のフェデレーションサーバーでは、自己署名 SSL 証明書を正常に使用できます。ただし、運用環境では、パブリック CA から証明書を取得することを勧めします。 - SSL 証明書用に Windows Server 2012 R2 でサポートされている任意のキーサイズがサポートされています。 - CNG キーを使用する証明書はサポートされていません。 - Workplace Join またはデバイス登録サービスと共に使用する場合、AD FS サービスの SSL 証明書のサブジェクト代替名には、後に組織のユーザープリンシパル名 (UPN) サフィックスが付いた enterpriseregistration 値 (例: enterpriseregistration.contoso.com) が含まれている必要があります。 - ワイルドカード証明書がサポートされています。 AD FS ファームを作成するときに、AD FS サービスのサービス名 (例: adfs.contoso.com) を入力するように求められます。 - Web アプリケーションプロキシに同じ SSL 証明書を使用することが強く推奨されます。ただし、Web アプリケーションプロキシ経由で Windows 統合認証エンドポイントをサポートする場合と、拡張保護認証が有効になっている (既定の設定) 場合は、これを同じにすることが必須になります。 - この証明書のサブジェクト名は、展開する AD FS の各インスタンスのフェデレーションサービス名を表すために使用されます。このような理由から、CA 発行の新しい証明書のサブジェクト名は、パートナーに対して自社または自組織の名前を最も良く表すものを選ぶことをお勧めします。証明書の ID は、フェデレーションサービス名 (例: fs.contoso.com) と一致する必要があります。ID は、dNSName 型のサブジェクト代替名拡張か、またはサブジェクト代替名エントリがない場合は、共通名として指定されたサブジェクト名のいずれかになります。証明書には複数のサブジェクト代替名エントリを指定できますが、そのうちの 1 つがフェデレーションサービス名と一致していることを条件とします。 - 重要: AD FS ファーム内のすべての Web アプリケーションプロキシに加えて、AD FS ファームのすべてのノードで同じ SSL 証明書を使用することが強く推奨されます。
サービス通信証明書: この証明書によって、フェデレーションサーバー間の通信のセキュリティを確保するための WCF メッセージのセキュリティを有効にします。	- 既定では、SSL 証明書がサービス通信証明書として使用されます。ただし、サービス通信証明書として別の証明書を構成するオプションもあります。 - 重要: サービス通信証明書として SSL 証明書を使用している場合、SSL 証明書の有効期限が切れたら、更新された SSL 証明書をサービス通信証明書として構成してください。これは自動的には行われません。 - この証明書は、WCF メッセージセキュリティを使用する AD FS のクライアントによって信頼されている必要があります。 - 公的 (第三者) 証明機関 (CA) 発行のサーバー認証証明書を使用することが推奨されます。 - サービス通信証明書を、CNG キーを使用する証明書にすることはできません。 - この証明書は、AD FS 管理コンソールを使用して管理できます。
トークン署名証明書: これは標準の X509 証明書であり、フェデレーションサーバーが発行するすべてのトークンを安全に署名するために使用されます。	- 既定では、AD FS によって 2048 ビットキーで自己署名証明書が作成されます。 - CA 発行の証明書もサポートされており、AD FS 管理スナップインを使用して変更できます - CA 発行の証明書は、CSP 暗号化プロバイダーを介して保存し、アクセスする必要があります。 - トークン署名証明書を、CNG キーを使用する証明書にすることはできません。 - AD FS では、トークン署名のために外部で登録された証明書は必要ありません。 AD FS では、これらの自己署名証明書が有効期限が切れる前に自動的に更新されます。最初に新しい証明書がセカンダリ証明書として構成されるので、パートナーがそれらを使用できます。次に、自動証明書ロールオーバーと呼ばれるプロセスで、それがプライマリに切り替えられます。トークン署名には自動的に生成された既定の証明書を使用することが推奨されます。トークン署名用に別の証明書を構成する必要があるポリシーが組織にある場合は、インストール時に PowerShell を使用して証明書を指定できます (Install-AdfsFarm コマンドレットの -SigningCertificateThumbprint パラメーターを使用します)。インストール後、AD FS 管理コンソールまたは PowerShell コマンドレット Set-AdfsCertificate と Get-AdfsCertificate を使用して、トークン署名証明書を表示および管理できます。外部で登録された証明書をトークン署名に使用した場合、AD FS によって証明書の自動更新またはロールオーバーが実行されません。このプロセスは、管理者が実行する必要があります。 1 つの証明書の有効期限が近づいたときに証明書のロールオーバーを許可するには、AD FS でセカンダリトークン署名証明書を構成できます。既定で、すべてのトークン署名証明書がフェデレーションメタデータで公開されますが、実際にトークンに署名するために AD FS によって使用されるのは、プライマリトークン署名証明書のみです。
トークン暗号化解除/暗号化証明書: これは、受信トークンの暗号化解除/暗号化に使用される標準 X509 証明書です。これは、フェデレーションメタデータでも公開されています。	- 既定では、AD FS によって 2048 ビットキーで自己署名証明書が作成されます。 - CA 発行の証明書もサポートされており、AD FS 管理スナップインを使用して変更できます - CA 発行の証明書は、CSP 暗号化プロバイダーを介して保存し、アクセスする必要があります。 - トークン暗号化解除/暗号化証明書を、CNG キーを使用する証明書にすることはできません。 - 既定で、AD FS によって、独自の内部で生成された自己署名証明書が生成され、トークンの暗号化解除に使用されます。 AD FS では、この目的で外部で登録された証明書は必要ありません。さらに、AD FS によって、これらの自己署名証明書が有効期限が切れる前に自動的に更新されます。トークンの暗号化解除には、既定の自動的に生成された証明書を使用することが推奨されます。トークン暗号化解除用に別の証明書を構成する必要があるポリシーが組織にある場合は、インストール時に PowerShell を使用して証明書を指定できます (Install-AdfsFarm コマンドレットの -DecryptionCertificateThumbprint パラメーターを使用します)。インストール後、AD FS 管理コンソールまたは PowerShell コマンドレット Set-AdfsCertificate と Get-AdfsCertificate を使用して、トークン暗号化解除証明書を表示および管理できます。外部で登録された証明書をトークン暗号化解除に使用した場合、AD FS によって証明書の自動更新が実行されません。このプロセスは、管理者が実行する必要があります。 - AD FS サービスアカウントは、ローカルコンピューターの個人用ストア内のトークン署名証明書のプライベートキーにアクセスできる必要があります。これは、セットアップによって行われます。また、トークン署名証明書を後で変更した場合に。AD FS 管理スナップインを使用して、このアクセスを確認することもできます。

注意事項

証明書のうち、トークン署名やトークン暗号化解除および暗号化に使用されるものは、フェデレーションサービスの安定性にきわめて重要です。独自のトークン署名とトークンの暗号化解除/暗号化証明書を管理するお客様は、これらの証明書がバックアップされ、回復イベントの発生時に個別に使用できることを確認する必要があります。

Note

AD FS では、デジタル署名に使用されるセキュアハッシュアルゴリズム (SHA) レベルを SHA-1 または SHA-256 (よりセキュリティが強固) のいずれかに変更できます。 AD FS では、MD5 (Makecert.exe コマンドラインツールで使用される既定のハッシュアルゴリズム) などの他のハッシュ方式での証明書の使用はサポートされていません。セキュリティ上のベストプラクティスとして、すべての証明書に SHA-256 (既定の設定) を使用することをお勧めします。 SHA-1 は、SHA-256 を使用した通信がサポートされない製品 (Microsoft 以外の製品やレガシーバージョンの AD FS など) との相互運用が必要なシナリオでのみ使用が推奨されます。

注意

CA から証明書を受け取ったら、すべての証明書がローカルコンピューターの個人証明書ストアにインポートされていることを確認してください。個人ストアへの証明書のインポートは証明書 MMC スナップインで行うことができます。

ハードウェア要件

Windows Server 2012 R2 の AD FS フェデレーションサーバーに適用される最小および推奨ハードウェア要件を次に示します。

ハードウェア要件	最小要件	推奨要件
CPU 速度	1.4 GHz 64 ビットプロセッサ	クアッドコア、2 GHz
RAM	512 MB	4 GB
ディスク領域	32 GB	100 GB

ソフトウェア要件

次の AD FS 要件は、Windows Server® 2012 R2 オペレーティングシステムに組み込まれているサーバーの機能に対するものです。

エクストラネットアクセスの場合は、Windows Server® 2012 R2 リモートアクセスサーバーロールの一部である Web アプリケーションプロキシロールサービスをデプロイする必要があります。以前のバージョンのフェデレーションサーバープロキシは、Windows Server® 2012 R2 の AD FS ではサポートされていません。
フェデレーションサーバーと Web アプリケーションプロキシの役割サービスを同じコンピューターにインストールすることはできません。

AD DS 要件

ドメインコントローラーの要件

すべてのユーザードメインおよび AD FS サーバーが参加しているドメインのドメインコントローラーは、Windows Server 2008 以降を実行している必要があります。

注意

Windows Server 2003 ドメインコントローラーを使用した環境のすべてのサポートは、Windows サーバー 2003 の延長サポート終了日後に終了します。お客様は、できるだけ早くドメインコントローラーをアップグレードすることが強く推奨されます。 Microsoft サポートのライフサイクルの詳細については、このページを参照してください。 Windows Server 2003 ドメインコントローラー環境に固有の問題が検出された場合、セキュリティの問題に対して、かつ Windows Server 2003 の拡張サポートの有効期限が切れる前に修正プログラムを発行できる場合にのみ、修正プログラムが発行されます。

注意

AD FS には、読み取り専用ドメインコントローラーではなく、完全に書き込み可能なドメインコントローラーを機能させる必要があります。計画されたトポロジに読み取り専用ドメインコントローラーが含まれている場合は、読み取り専用ドメインコントローラーを認証に使用できますが、LDAP 要求の処理には書き込み可能なドメインコントローラーへの接続が必要です。

ドメイン機能レベルの要件

すべてのユーザーアカウントドメインと AD FS サーバーが参加しているドメインは、Windows Server 2003 以降のドメインの機能レベルで動作している必要があります。

AD FS の機能のほとんどは、AD DS の機能レベルを変更しなくても正常に動作します。ただし、クライアント証明書認証の証明書が明示的に AD DS 内のユーザーアカウントにマッピングされている場合に認証を正しく動作させるには、ドメイン機能レベルが Windows Server 2008 以上であることが必要です。

スキーマの要件

AD FS では、AD DS の機能レベルの変更やスキーマの変更は必要ありません。
Workplace Join 機能を使用するには、AD FS サーバーが参加しているフォレストのスキーマを Windows Server 2012 R2 に設定する必要があります。

サービスアカウントの要件

任意の標準サービスアカウントを AD FS のサービスアカウントとして使用できます。グループのマネージドサービスアカウントもサポートされています。これには、Windows Server 2012 以上を実行する少なくとも 1 つのドメインコントローラーが必要です (複数デプロイすることが推奨されます)。
ドメインに参加しているクライアントと AD FS 間で Kerberos 認証を機能させるには、サービスアカウントの SPN として 'HOST/<adfs_service_name>' を登録する必要があります。既定で、新しい AD FS ファームを作成するときに、この操作を実行するための十分なアクセス許可があれば、AD FS によってこれが構成されます。
AD FS サービスアカウントは、AD FS サービスに対して認証するユーザーを含むすべてのユーザードメインで信頼されている必要があります。

ドメインの要件

すべての AD FS サーバーは、AD DS ドメインに参加している必要があります。
ファーム内のすべての AD FS サーバーを 1 つのドメインにデプロイする必要があります。
AD FS サーバーが参加しているドメインは、AD FS サービスに対して認証するユーザーを含むすべてのユーザーアカウントドメインを信頼している必要があります。

複数フォレストの要件

AD FS サーバーが参加しているドメインは、AD FS サービスに対して認証するユーザーを含むすべてのユーザーアカウントドメインまたはフォレストを信頼している必要があります。
AD FS サービスアカウントは、AD FS サービスに対して認証するユーザーを含むすべてのユーザードメインで信頼されている必要があります。

構成データベースの要件

次に、構成ストアの種類に基づいて適用される要件と制限を示します。

WID

証明書利用者側の信頼が 100 以下の場合、WID ファームのフェデレーションサーバー数は 30 台に制限されます。
SAML 2.0 のアーティファクト解決プロファイルは、WID 構成データベースでサポートされていません。トークンリプレイ検出は、WID 構成データベースでサポートされていません。 AD FS がフェデレーションプロバイダーとして機能し、外部要求プロバイダーからのセキュリティトークンを使用するシナリオでのみ、この機能が使用されます。
フェールオーバーまたは地理的負荷分散のために個別のデータセンターに AD FS サーバーをデプロイすることは、サーバーの数が 30 台を超えない限りサポートされます。

次の表に、WID ファームを使用する場合の概要を示します。それを使用して実装を計画してください。

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 2012 R2 の AD FS では SQL Server 2008 以上を使用できます

ブラウザー要件

ブラウザーまたはブラウザーコントロールを介して AD FS 認証を実行する場合、ブラウザーは次の要件を満たしている必要があります。

JavaScript を有効にする必要があります
Cookie を有効にする必要があります
Server Name Indication (SNI) をサポートする必要があります
ユーザー証明書とデバイス証明書の認証 (Workplace Join 機能) の場合、ブラウザーで SSL クライアント証明書認証がサポートされている必要があります

いくつかの主要なブラウザーとプラットフォームについては、レンダリングと機能の検証が行われています。その詳細を以下に示します。この表に記載されていないブラウザーやデバイスでも、上記の要件を満たしていればサポートされます。

ブラウザー	プラットフォーム
IE 10.0	Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
IE 11.0	Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
Windows Web 認証ブローカー	Windows 8.1
Firefox [v21]	Windows 7、Windows 8.1
Safari [v7]	iOS 6、Mac OS-X 10.7
Chrome [v27]	Windows 7、Windows 8.1、Windows Server 2012、Windows Server 2012 R2、Mac OS-X 10.7

重要

既知の問題 - Firefox: デバイス証明書を使用してデバイスを識別する Workplace Join 機能は、Windows プラットフォームでは機能しません。 Firefox では、Windows クライアントのユーザー証明書ストアにプロビジョニングされた証明書を使用した SSL クライアント証明書認証の実行は、現在サポートされていません。

Cookie

AD FS によって作成されるセッションベースや永続的な Cookie がクライアントコンピューター上に保存される必要があります。これは、サインイン、サインアウト、シングルサインオンなどの機能を実現するためです。したがって、クライアントブラウザーは Cookie を受け入れるように設定されている必要があります。認証に使用される Cookie はすべて HTTPS (Hypertext Transfer Protocol Secure) セッション Cookie であり、発信元サーバーごとに書き出されます。クライアントブラウザーがこの Cookie を受け入れるように設定されていない場合は、AD FS が正しく動作することができません。永続的 Cookie は、ユーザーが選択したクレームプロバイダーを記憶するために使用されます。これを無効にするには、AD FS サインインページの構成ファイルにある構成設定を使用します。セキュリティ上の理由から、TLS/SSL のサポートが必要です。

エクストラネットの要件

AD FS サービスへのエクストラネットアクセスを提供するには、認証要求をセキュリティ保護された方法で AD FS サービスに対してプロキシするエクストラネット向けのロールとして、Web アプリケーションプロキシのロールサービスをデプロイする必要があります。これにより、AD FS サービスエンドポイントの分離だけでなく、すべてのセキュリティキー (トークン署名証明書など) をインターネットから送信される要求から分離することができます。さらに、ソフトエクストラネットアカウントロックアウトなどの機能では、Web アプリケーションプロキシを使用する必要があります。 Web アプリケーションプロキシの詳細については、「Web アプリケーションプロキシ」を参照してください。 `

ネットワークの要件

組織で AD FS を正常にデプロイするには、以下のネットワークサービスを適切に構成することが非常に重要です。

企業ファイアウォールの構成

Web アプリケーションプロキシとフェデレーションサーバーファームの間にあるファイアウォールと、クライアントと Web アプリケーションプロキシ間にあるファイアウォールの両方で、受信方向の TCP ポート 443 を有効にする必要があります。

さらに、クライアントユーザー証明書認証 (X509 ユーザー証明書を使用した clientTLS 認証) が必要で、Windows Server 2012 R2 の AD FS ではクライアントと Web アプリケーションプロキシ間のファイアウォールで、受信方向の TCP ポート 49443 を有効にする必要があります。これは、Web アプリケーションプロキシとフェデレーションサーバー間のファイアウォールでは必要ありません。

注意

さらに、ポート 49443 が AD FS および Web アプリケーションプロキシサーバー上の他のサービスで使用されていないことも確認してください。

DNS の構成

イントラネットアクセスの場合、社内ネットワーク (イントラネット) 内の AD FS サービスにアクセスするすべてのクライアントで、AD FS サービス名 (SSL 証明書によって提供された名前) を、AD FS サーバーのロードバランサーまたは AD FS サーバーに解決できる必要があります。
エクストラネットアクセスの場合、企業ネットワークの外部 (エクストラネットまたはインターネット) から AD FS サービスにアクセスするすべてのクライアントで、AD FS サービス名 (SSL 証明書によって提供された名前) を、Web アプリケーションプロキシサーバーのロードバランサーまたは Web アプリケーションプロキシサーバーに解決できる必要があります。
エクストラネットアクセスが正常に機能するには、DMZ 内の各 Web アプリケーションプロキシサーバーで、AD FS サービス名 (SSL 証明書によって提供された名前) を、AD FS サーバーのロードバランサーまたは AD FS サーバーに解決できる必要があります。これを達成するには、DMZ ネットワーク内の代替 DNS サーバーを使用するか、HOSTS ファイルを使用してローカルサーバーの解決を変更します。
Web アプリケーションプロキシ経由で公開されるエンドポイントのサブセットに対し、ネットワークの内部およびネットワークの外部で Windows 統合認証を機能させるには、ロードバランサーを指す A レコード (CNAME ではない) を使用する必要があります。

フェデレーションサービスとデバイス登録サービス用に企業 DNS を構成する方法については、「フェデレーションサービスと DRS 用に企業 DNS を構成する」を参照してください。

Web アプリケーションプロキシ用に企業 DNS を構成する方法については、手順 1: Web アプリケーションプロキシインフラストラクチャを構成するの「DNS を構成する」セクションを参照してください。

NLB を使用して、クラスターの IP アドレスまたはクラスターの FQDN を構成する方法については、http://go.microsoft.com/fwlink/?LinkId=75282 の「クラスターパラメーターの指定」を参照してください。

属性ストアの要件

AD FS では、ユーザーの認証とそれらのユーザーのセキュリティ要求の抽出に使用する属性ストアが 1 つ以上必要です。 AD FS でサポートされる属性ストアの一覧については、「属性ストアのロール」を参照してください。

注意

AD FS では既定で、"Active Directory" 属性ストアが自動的に作成されます。属性ストアの要件は、自組織の役割がアカウントパートナー (フェデレーションユーザーをホストする) であるかリソースパートナー (フェデレーションアプリケーションをホストする) であるかによって異なります。

LDAP 属性ストア

LDAP (ライトウェイトディレクトリアクセスプロトコル) をベースとするその他の属性ストアを使用するときは、Windows 統合認証をサポートしている LDAP サーバーに接続する必要があります。 LDAP 接続文字列は、RFC 2255 での説明に従い、LDAP URL の形式で記述されている必要があります。

また、AD FS サービスのサービスアカウントに、LDAP 属性ストアのユーザー情報を取得する権利があることも必要です。

SQL Server 属性ストア

Windows Server 2012 R2 の AD FS が正しく動作するには、SQL Server 属性ストアをホストするコンピューターで Microsoft SQL Server 2008 以上が実行されている必要があります。 SQL ベースの属性ストアを使用するときは、接続文字列も構成する必要があります。

カスタム属性ストア

複雑なシナリオを実現するために、独自の属性ストアを開発することができます。

AD FS 内蔵のポリシー言語からカスタム属性ストアを参照できるので、次に示すようなシナリオの拡張が可能になります。
- ローカルで認証されるユーザーのクレームを作成する
- 外部で認証されるユーザーのクレームを補足する
- トークンを取得することをユーザーに許可する
- ユーザーの行動に基づいてトークンを取得することをサービスに許可する
- AD FS によって証明書利用者に発行されたセキュリティトークンで追加データを発行する。
すべてのカスタム属性ストアは、.NET 4.0 以降に基づいて構築される必要があります。

カスタム属性ストアを使用するときは、接続文字列を構成することも必要になる可能性があります。その場合は、カスタム属性ストアへの接続を可能にする任意のカスタムコードを入力できます。この状況の接続文字列は、一連の名前/値ペアであり、カスタム属性ストアの開発者によって実装されたとおりに解釈されます。カスタム属性ストアの開発と使用の方法の詳細については、属性ストアの概要に関するページを参照してください。

アプリケーションの要件

AD FS では、次のプロトコルを使用する要求対応アプリケーションがサポートされています。

WS-Federation
WS-Trust
IDPLite、SPLite、および eGov1.5 プロファイルを使用した SAML 2.0 プロトコル。
OAuth 2.0 Authorization Grant Profile

AD FS では、Web アプリケーションプロキシでサポートされている要求非対応アプリケーションの認証と認可もサポートされています。

認証の要件

AD DS 認証 (プライマリ認証)

イントラネットアクセスの場合、AD DS の次の標準認証メカニズムがサポートされています。

Kerberos と NTLM のネゴシエートを使用した Windows 統合認証
ユーザー名/パスワードを使用したフォーム認証
AD DS のユーザーアカウントにマップされた証明書を使用した証明書認証

エクストラネットアクセスの場合、次の認証メカニズムがサポートされています。

ユーザー名/パスワードを使用したフォーム認証
AD DS のユーザーアカウントにマップされた証明書を使用した証明書認証
Windows 統合認証を受け入れる WS-Trust エンドポイントに対するネゴシエートを使用した Windows 統合認証 (NTLM のみ)。

証明書認証の場合:

PIN で保護できるスマートカードまで拡張されます。
ユーザーが PIN を入力するための GUI は AD FS で提供されないため、クライアント TLS を使用するときに表示されるクライアントオペレーティングシステムの一部にする必要があります。
ブラウザーが存在するコンピューター上でスマートカードのリーダーと暗号化サービスプロバイダー (CSP) が動作する必要があります。
スマートカード証明書は、すべての AD FS サーバーと Web アプリケーションプロキシサーバー上の信頼されたルートまでチェーンでつながっている必要があります。
証明書は、AD DS 内のユーザーアカウントに、次のいずれかの方法でマッピングされている必要があります。
- 証明書サブジェクト名が、AD DS 内のユーザーアカウントの LDAP 識別名に対応している。
- 証明書のサブジェクト別名拡張領域の中に、AD DS 内のユーザーアカウントのユーザープリンシパル名 (UPN) がある。

イントラネットで kerberos を使用したシームレスな Windows 統合認証には、

サービス名が信頼済みサイトまたはローカルイントラネットサイトの一部である必要があります。
さらに、<HOST/adfs_service_name> SPN が、AD FS ファームが実行されているサービスアカウントに設定されている必要があります。

Multi-Factor Authentication

AD FS では、プロバイダーモデルを使用して、(AD DS でサポートされているプライマリ認証以外に) 追加の認証がサポートされています。それにより、ベンダーやお客様は、管理者がログイン中に登録して使用できる独自の多要素認証アダプターを構築できます。

すべての MFA アダプターは、.NET 4.5 に基づいて構築される必要があります。

MFA の詳細については、「機密アプリケーションの追加の多要素認証によるリスク管理」を参照してください。

デバイス認証

AD FS では、エンドユーザーがデバイスをワークプレースに参加させる操作時に、デバイス登録サービスによってプロビジョニングされた証明書を使用したデバイス認証がサポートされています。

Workplace join の要件

エンドユーザーは、AD FS を使用して、デバイスを組織のワークプレースに参加させることができます。これは、AD FS のデバイス登録サービスによってサポートされています。その結果、エンドユーザーは、AD FS によってサポートされているアプリケーション全体で SSO の追加の利点が得られます。さらに、管理者は、組織のワークプレースに参加しているデバイスに対してのみ、アプリケーションへのアクセスを限定することで、リスクを管理できます。このシナリオを可能にするための要件を次に示します。

AD FS では、Windows 8.1 および iOS 5 以上のデバイスのワークプレース参加がサポートされています
Workplace Join 機能を使用するには、AD FS サーバーが参加しているフォレストのスキーマが R2 Windows Server 2012 である必要があります。
AD FS サービスの SSL 証明書のサブジェクト代替名には、組織のユーザープリンシパル名 (UPN) サフィックスが後に続く、値 enterpriseregistration が含まれる必要があります (例: enterpriseregistration.corp.contoso.com)。

暗号化の要件

次の表に、AD FS トークン署名、トークン暗号化/暗号化解除機能に関する追加の暗号化サポート情報を示します。

アルゴリズム	キーの長さ	プロトコル/アプリケーション/コメント
TripleDES - 既定値 192 (192 から 256 をサポート) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc	>= 192	セキュリティトークンを復号化するためにサポートされているアルゴリズム。このアルゴリズムによるセキュリティトークンの暗号化はサポートされていません。
AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc	128	セキュリティトークンを復号化するためにサポートされているアルゴリズム。このアルゴリズムによるセキュリティトークンの暗号化はサポートされていません。
AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc	192	セキュリティトークンを復号化するためにサポートされているアルゴリズム。このアルゴリズムによるセキュリティトークンの暗号化はサポートされていません。
AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc	256	Default。セキュリティトークンを暗号化するためにサポートされているアルゴリズム。
TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes	.NET 4.0 以降でサポートされているすべてのキーサイズ	セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128	128	セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192	192	セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256	256	セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5	1024	セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p	1024	既定値。セキュリティトークンを暗号化する対称キーを暗号化するためにサポートされているアルゴリズム。
SHA1 - http://www.w3.org/PICS/DSig/SHA1_1_0.html	該当なし	アーティファクト SourceId の生成で AD FS サーバーによって使用されます。このシナリオでは、STS が SHA1 を使用し (SAML 2.0 標準の推奨事項に従って)、アーティファクト sourceiD の短い 160 ビット値を作成します。また、AD FS Web エージェント (WS2003 期間からのレガシコンポーネント) によって、"最終更新" 時間の値の変更を識別し、STS からの情報を更新するタイミングが認識されるようにするためにも使用されます。
SHA1withRSA - http://www.w3.org/PICS/DSig/RSA-SHA1_1_0.html	該当なし	AD FS サーバーが SAML AuthenticationRequest の署名を検証する場合、アーティファクト解決要求または応答に署名する場合、トークン署名証明書を作成する場合に使用されます。このような場合、SHA256 が既定値であり、パートナー (証明書利用者) が SHA256 をサポートできず、SHA1 を使用する必要がある場合にのみ、SHA1 が使用されます。

アクセス許可の要件

AD FS のインストールと初期構成を実行する管理者は、ローカルドメイン (つまり、フェデレーションサーバーが参加しているドメイン) のドメイン管理者アクセス許可を持っている必要があります。

参照

Windows Server 2012 R2 での AD FS 設計ガイド

次の方法で共有