次の方法で共有


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 またはデバイス登録サービスと共に使用する場合、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 設計ガイド