次の方法で共有


Windows Server の AD FS 要件

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

証明書の要件

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

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

証明書の種類 要件、サポート、知っておくべきこと
Secure Sockets Layer (SSL) 証明書: これは、フェデレーション サーバーとクライアント間の通信をセキュリティで保護するために使用される標準の SSL 証明書です。 - この証明書は、パブリックに信頼されている * X509 v3 証明書である必要があります。
- AD FS エンドポイントにアクセスするすべてのクライアントは、この証明書を信頼する必要があります。 パブリック (サード パーティ) 証明機関 (CA) によって発行された証明書を使用することを強くお勧めします。 テスト ラボ環境のフェデレーション サーバーで、自己署名 SSL 証明書を正常に使用できます。 ただし、運用環境では、パブリック CA から証明書を取得することをお勧めします。
- SSL 証明書に対して Windows Server 2012 R2 でサポートされている任意のキー サイズをサポートします。
- CNG キーを使用する証明書はサポートされていません。
- Workplace Join/Device Registration Service と共に使用する場合、AD FS サービスの SSL 証明書のサブジェクトの別名には、エンタープライズ登録の価値が含まれ、その後に組織のユーザー プリンシパル名 (UPN) サフィックスが続く必要があります (例: 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 ファームのすべてのノードと、AD FS ファーム内のすべての Web アプリケーション プロキシで同じ 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 管理スナップインを使用してこのアクセスを確保することもできます。

注意事項

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

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

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 Server 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 つのドメイン コントローラー (2 つ以上を展開することをお勧めします) が必要です。

  • ドメインに参加しているクライアントと AD FS の間で Kerberos 認証を機能させるには、サービス アカウントに 'HOST/<adfs_service_name>' を SPN として登録する必要があります。 既定では、この操作を実行するための十分なアクセス許可がある場合、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 がフェデレーション プロバイダーとして機能し、外部クレーム プロバイダーからセキュリティ トークンを使用するシナリオでのみ使用されます。

  • サーバーの数が 30 を超えない限り、フェールオーバーまたは地理的な負荷分散のために個別のデータ センターに AD FS サーバーを展開することがサポートされます。

次の表に、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 を有効にする必要があります

  • サーバー名表示 (SNI) がサポートされている必要があります

  • ユーザー証明書とデバイス証明書認証 (ワークプレース参加機能) の場合、ブラウザーは SSL クライアント証明書認証をサポートしている必要があります

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

ブラウザー プラットフォーム
IE 10.0 Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
IE 11.0 Windows7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
Windows Web Authentication Broker 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

Von Bedeutung

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

クッキー

AD FS は、サインイン、サインアウト、シングル サインオン (SSO)、その他の機能を提供するために、クライアント コンピューターに保存する必要があるセッション ベースの永続的な Cookie を作成します。 そのため、Cookie を受け入れるようにクライアント ブラウザーを構成する必要があります。 認証に使用される Cookie は、送信元サーバー用に書き込まれる常にセキュア ハイパーテキスト転送プロトコル (HTTPS) セッション 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 アプリケーション プロキシとフェデレーション サーバーの間のファイアウォールでは必要ありません)。

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

DNS の構成

  • イントラネット アクセスの場合、内部企業ネットワーク (イントラネット) 内の AD FS サービスにアクセスするすべてのクライアントは、AD FS サーバーまたは AD FS サーバーのロード バランサーに AD FS サービス名 (SSL 証明書によって提供される名前) を解決できる必要があります。

  • エクストラネット アクセスの場合、企業ネットワーク (エクストラネット/インターネット) の外部から AD FS サービスにアクセスするすべてのクライアントは、WEB アプリケーション プロキシ サーバーまたは Web アプリケーション プロキシ サーバーのロード バランサーに AD FS サービス名 (SSL 証明書によって提供される名前) を解決できる必要があります。

  • エクストラネット アクセスを適切に機能させるには、DMZ 内の各 Web アプリケーション プロキシ サーバーが、AD FS サーバーまたは AD FS サーバーのロード バランサーに AD FS サービス名 (SSL 証明書によって提供される名前) を解決できる必要があります。 これは、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 承認付与プロファイル

AD FS では、Web アプリケーション プロキシでサポートされているクレーム対応以外のアプリケーションの認証と承認もサポートされています。

認証の要件

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

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

  • Windows 統合認証で Kerberos および NTLM のためのネゴシエートを使用

  • ユーザー名/パスワードを使用したフォーム認証

  • AD DS のユーザー アカウントにマップされた証明書を使用した証明書認証

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

  • ユーザー名/パスワードを使用したフォーム認証

  • AD DS のユーザー アカウントにマップされている証明書を使用した証明書認証

  • Windows 統合認証を受け入れる WS-Trust エンドポイントに対するネゴシエートを使用した Windows 統合認証 (NTLM のみ)。

証明書認証の場合:

  • ピンで保護できるスマートカードまで拡張します。

  • ユーザーがピンを入力するための GUI は AD FS によって提供されず、クライアント TLS を使用するときに表示されるクライアント オペレーティング システムの一部である必要があります。

  • スマート カードのリーダーおよび暗号化サービス プロバイダー (CSP) は、ブラウザーが配置されているコンピューターで動作する必要があります。

  • スマート カード証明書は、すべての AD FS サーバーと Web アプリケーション プロキシ サーバー上の信頼されたルートまでチェーンする必要があります。

  • 証明書は、次のいずれかの方法で AD DS のユーザー アカウントにマップする必要があります。

    • 証明書のサブジェクト名は、AD DS のユーザー アカウントの LDAP 識別名に対応します。

    • 証明書のサブジェクト (altname) 拡張機能には、AD DS のユーザー アカウントのユーザー プリンシパル名 (UPN) が含まれています。

イントラネット内の Kerberos を使用したシームレスな Windows 統合認証の場合は、次の手順を実行します。

  • サービス名が信頼済みサイトまたはローカル イントラネット サイトの一部である必要があります。

  • さらに、AD FS ファームが実行されているサービス アカウントで HOST/<adfs_service_name> SPN を設定する必要があります。

多要素認証

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

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

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

デバイス認証

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

ワークプレース ジョインの要件

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

  • AD FS では、Windows 8.1 および iOS 5 以降のデバイスのワークプレース参加がサポートされます

  • Workplace Join 機能を使用するには、AD FS サーバーが参加しているフォレストのスキーマが Windows Server 2012 R2 である必要があります。

  • AD FS サービスの SSL 証明書のサブジェクトの別名には、エンタープライズ登録の値を含め、その後に組織のユーザー プリンシパル名 (UPN) サフィックス (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 が既定であり、SHA1 はパートナー (証明書利用者) が SHA256 をサポートできない場合にのみ使用され、SHA1 を使用する必要があります。

アクセス許可の要件

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

こちらもご覧ください

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