Active Directory フェデレーション サービス (AD FS) の新機能

  • [アーティクル]

Windows Server 2019 の Active Directory フェデレーション サービス (AD FS) の新機能

この記事では、Active Directory フェデレーション サービス (AD FS) に加えられた新しい変更について説明します。

保護されたサインイン

次のポイントは、Active Directory フェデレーション サービス (AD FS) 2019 で使用できる保護されたサインインの更新の概要です。

  • プライマリとしての外部認証プロバイダー。 顧客は、 1 つ目の要素としてパスワードを公開するのではなく、 1 つ目の要素としてサード パーティの認証製品を使用できるようになりました。 外部認証プロバイダーで 2 つの要素を証明できる場合は、MFA が要求される可能性があります。
  • 追加認証としてのパスワード認証。 顧客は、パスワードなしのオプションが最初の要素として使用された後、追加要素としてのみパスワードを使用するフル サポートのインボックス オプションを利用できます。 このオプションにより、現状のままサポートされる GitHub アダプターを顧客がダウンロードする必要があった AD FS 2016 と比べてカスタマー エクスペリエンスが強化されています。
  • プラグ可能なリスク評価モジュール。 顧客は独自のプラグイン モジュールを作成して、事前認証段階で特定の種類の要求をブロックできるようになりました。 この機能により、顧客は ID 保護などのクラウド インテリジェンスを使用して、危険なユーザーや危険なトランザクションのサインインをブロックしやすくなります。 詳細については、「AD FS 2019 のリスク評価モデルを使用してプラグインをビルドする」を参照してください。
  • ESL の改良点。 次の機能を追加して、2016 の ESL クイック修正エンジニアリング (QFE) を改善しました。
    • AD FS 2012 R2 以降で使用できる "クラシック" エクストラネット ロックアウト機能の保護を受けながら、顧客は監査モードになることができます。 現在 2016 をご利用の場合、監査モード中は保護されません。
    • 使い慣れた場所に対して、個別のロックアウトしきい値を有効にします。 この機能により、共通のサービス アカウントで実行されているアプリの複数のインスタンスが、最小限の影響でパスワードをロールオーバーできるようになります。

その他のセキュリティの強化

AD FS 2019 では、次のセキュリティ強化を利用できます。

  • SmartCard サインインを使用したリモート PowerShell。 顧客は、スマートカードを使用して PowerShell 経由で AD FS にリモート接続し、それを使用してマルチノード コマンドレットを含むすべての PowerShell 機能を管理できます。
  • HTTP ヘッダーのカスタマイズ。 顧客は、次のヘッダーを含む、AD FS の応答中に生成された HTTP ヘッダーをカスタマイズできるようになりました。
    • HSTS: このヘッダーは、準拠するブラウザーが強制するため、 HTTPS エンドポイント上でのみ、AD FS エンドポイントを使用できることを伝えます。
    • x-frame-options: AD FS 管理者は、特定の証明書利用者に AD FS 対話型サインイン ページへの iFrame の埋め込みを許可できます。 このヘッダーは、HTTPS ホスト上でのみ使用する必要があるので注意してください。
    • 将来的なヘッダー: 他の将来的なヘッダーも構成できます。

詳細については、「AD FS 2019 で HTTP セキュリティ応答ヘッダーをカスタマイズする」を参照してください。

認証およびポリシーの機能

AD FS 2019 には、次の認証およびポリシーの機能があります。

  • RP ごとに他の認証の認証方法を指定します。 顧客は、要求ルールを使用して、追加の認証に他のどの認証プロバイダーを呼び出すかを決定できるようになりました。 この機能は 2 つのユース ケースで役立ちます。
    • 顧客は、ある認証プロバイダーから別の認証プロバイダーに移行しています。 このようにして、新しい認証プロバイダーにユーザーをオンボードするときに、グループを使って、どの追加認証プロバイダーを呼び出すかを制御できます。
    • 顧客には、特定のアプリケーションのための特定の追加認証プロバイダー (証明書など) が必要です。
  • トランスポート層セキュリティ (TLS) ベースのデバイス認証を、それを必要とするアプリケーションのみに制限します。 顧客は、クライアントの TLS ベースのデバイス認証を、デバイス ベースの条件付きアクセスを実行するアプリケーションのみに制限できるようになりました。 このオプションにより、TLS ベースのデバイス認証を必要としないアプリケーションでは、不要なデバイス認証のプロンプトが表示されなくなります (または、クライアント アプリケーションで処理できない場合は失敗します)。
  • 多要素認証 (MFA) の更新の間隔のサポート。 AD FS では、2 つ目の要素の資格情報の更新の間隔に基づいて、2 つ目の要素の資格情報を再実行する機能がサポートされるようになりました。 この機能によってお客様は、2 つの要素を使用して最初のトランザクションを実行し、定期的に、2 つ目の要素に対してのみプロンプトを表示することができます。 この機能は、要求に追加パラメーターを提供できるアプリケーションでのみ使用できますが、AD FS で構成可能な設定ではありません。 Azure AD では、Azure AD フェデレーション ドメイン信頼設定で "X 日間 MFA を記憶する" を構成し、'supportsMFA' フラグを true に設定すると、このパラメーターがサポートされます。

シングル サインオンの機能強化

AD FS 2019 では、次のシングル サインオン SSO の機能強化が行われています。

  • 中央揃えテーマを使用したページ分割された UX。 AD FS は、ページ分割された UX フローに移行し、AD FS がよりスムーズなサインイン エクスペリエンスを検証および提供できるようになりました。 AD FS では、(画面の右側ではなく) 中央の UI が使用されるようになりました。 このエクスペリエンスに合わせて、新しいロゴと背景画像が必要になる場合があります。 この変更は、Azure AD で提供される機能にも反映されます。
  • バグの修正: プライマリ更新トークン(PRT) 認証を行うときの Win10 デバイスの永続的な SSO 状態。 この変更によって、Windows 10 デバイスで PRT 認証を使用するときに MFA 状態が保持されない問題が解決されます。 この問題の結果、エンド ユーザーは頻繁に、2 つ目の要素の資格情報 (MFA) の入力を求められていました。 また、この修正により、デバイス認証がクライアント TLS および PRT メカニズムを介して正常に実行される場合のエクスペリエンスの一貫性も向上します。

最新の基幹業務アプリを構築するためのサポート

最新の基幹業務 LOB アプリを構築するため、次のようなサポートが AD FS 2019 に追加されました。

  • Oauth デバイス フロー/プロファイル。 AD FS は、豊富なサインイン エクスペリエンスをサポートする UI サーフェス領域を持たないデバイスにサインインするための OAuth デバイス フロー プロファイルをサポートするようになりました。 この機能により、ユーザーは別のデバイス上でサインイン エクスペリエンスを完了できるようになります。 この機能は、Azure Stack での Azure CLI のエクスペリエンスに必要であり、他の場合にも使用できます。
  • 'Resource' パラメーターの削除。 AD FS では、リソース パラメーターを指定する要件が削除されました。これは、現在の Oauth 仕様に準拠しています。 クライアントは、要求されたアクセス許可に加えて、スコープ パラメーターとして証明書利用者の信頼識別子を提供できるようになりました。
  • AD FS 応答のクロスオリジン リソース共有 (CORS) ヘッダー。 顧客は、AD FS の OpenID Connect (OIDC) 検出ドキュメントから署名キーを照会することにより、クライアント側の JavaScript ライブラリから id_token の署名を検証できるシングル ページ アプリケーションを構築できるようになりました。
  • Proof Key for Code Exchange (PKCE) のサポート。 AD FS では、OAuth 内でセキュリティで保護された認証コード フローを提供するために、PKCE のサポートを追加します。 この機能は、このフローにセキュリティのレイヤーを追加し、コードのハイジャックや別のクライアントからのリプレイを防ぎます。
  • バグ修正: x5t と kid 要求を送信します。 この変更は軽微なバグ修正です。 AD FS は、署名を検証するためのキー ID ヒントを示す 'kid' 要求を追加で送信するようになりました。 以前は、 AD FS は 'x5t' 要求のみを送信していました。

サポート性の向上

次のサポート性の向上が、AD FS 2019 に含まれるようになりました。

  • AD FS 管理者にエラーの詳細を送信します。 管理者は、エンド ユーザー認証の失敗に関するデバッグ ログを送信し、簡単に使用できるように圧縮ファイルとして保存するようにエンド ユーザーを構成できます。 管理者は、簡易メール転送プロトコル (SMTP) 接続を構成して、 圧縮ファイルをトリアージ メール アカウントにメールを自動送信したり、メールに基づいてチケットを自動作成したりもできます。

デプロイの更新

AD FS 2019 には、次のデプロイの更新が追加されました。

  • ファーム動作レベル 2019。 AD FS 2016 と同様に、後述の記事で説明する新しい機能を有効にするために必要な新しいファーム動作レベル バージョンがあります。 これにより、以下が可能になります。
    • Windows Server 2012 R2 の AD FS から Windows Server 2016 の AD FS。
    • Windows Server 2016 の AD FS から Windows Server 2019 の AD FS。

SAML の更新

次の Security Assertion Markup Language (SAML) 更新プログラムが AD FS 2019 に含まれています。

  • バグ修正: 集約されたフェデレーションのバグを修正します。 集計されたフェデレーションのサポートに関連するバグ修正が多数ありました (InCommon など)。 次の領域で修正が行われます。
    • 集計されたフェデレーション メタデータ ドキュメント内の多数のエンティティのスケーリングが向上しました。以前は、スケーリングは、"ADMIN0017" エラーで失敗していました。
    • Get-AdfsRelyingPartyTrustsGroup PowerShell コマンドレット経由で 'ScopeGroupID' パラメータを使用してクエリを実行します。
    • 重複する entityID に関するエラー条件の処理。

スコープ パラメーターの Azure AD スタイル リソース仕様

以前は、AD FS では、認証要求の別のパラメーターに目的のリソースとスコープが必要でした。 たとえば、次の OAuth 要求は、通常送信するものと同じようになります。

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Server 2019 の AD FS では、リソース値をスコープ パラメーターに埋め込んで渡すことができます。 この変更は Azure AD に対して認証を行う方法と一致しています。

スコープ パラメーターは、各エントリがリソース/スコープとして構成された、スペース区切りのリストとして作成できるようになりました。

注意

認証要求では、1 つのリソースのみを指定できます。 要求に複数のリソースが含まれている場合、AD FS からエラーが返され、認証は失敗します。

oAuth の Proof Key for Code Exchange (PKCE) のサポート

認証コードの付与を使用する OAuth パブリック クライアントは、認証コードの傍受攻撃の影響を受けやすくなります。 この攻撃の詳細については、RFC 7636 を参照してください。 この攻撃を軽減するために、Server 2019 の AD FS では、OAuth 認証コード付与フロー用の Proof Key for Code Exchange (PKCE) がサポートされています。

この仕様では、PKCE のサポートを使用するために、OAuth 2.0 認証とアクセス トークン要求には別のパラメーターが追加されています。

クライアントと AD FS 2019 の間の PKCE 関係の図。

A。 クライアントは、"code_verifier" という名前のシークレットを作成および記録して、変換されたバージョンの "t(code_verifier)" ("code_challenge" と呼ばれます)を導出します。 シークレットは、"t_m" 変換メソッドとともに OAuth 2.0 承認要求で送信されます。

B. 承認エンドポイントは通常どおり応答しますが、"t(code_verifier)" と変換メソッドが記録されます。

C. クライアントからは通常どおりアクセス トークン要求で認証コードが送信されますが、(A) で生成された "code_verifier" シークレットが含められます。

D. AD FS によって "code_verifier" が変換され、(B) の "t(code_verifier)" と比較されます。 同じでない場合、アクセスは拒否されます。

2019 における追加の認証プロバイダーの選択方法

AD FS では、要求ルール ポリシーに基づいた追加の認証のトリガーは既にサポートされています。 これらのポリシーは、特定の RP に、またはグローバル レベルで設定できます。 「Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs」コマンドレットを使用して、AdditionalAuthenticationRules または AdditionalAuthenticationRulesFile パラメーターのいずれかを渡すことで、特定の RP に追加の認証ポリシーを設定できます。 グローバルに設定するには、管理者は「Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs」コマンドレットを使用できます。

たとえば、2012 R2 以降の管理者は、既に、エクストラネットから要求が送信された場合に追加の認証を求める次の規則を作成できます。

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'

2019 では、顧客は、要求ルールを使用して、追加の認証に呼び出す他の認証プロバイダーを決定できるようになりました。 この機能は 2 つのシナリオで役立ちます。

顧客は、ある認証プロバイダーから別の認証プロバイダーに移行しています。 このようにして、新しい認証プロバイダーにユーザーをオンボードするときに、グループを使って、どの追加認証プロバイダーを呼び出すかを制御できます。

顧客は、特定のアプリケーション用には特定の追加認証プロバイダー (証明書など) が必要ですが、その他のアプリケーション用には別の方法 (Azure AD 多要素認証) が必要です。

この構成は、他の認証ポリシーから要求 http://schemas.microsoft.com/claims/authnmethodsproviders を発行して実現できます。 この要求の値は、認証プロバイダーの名前にする必要があります。

2019 では、自身のシナリオに基づいて認証プロバイダーを選択するように上記の要求ルールを変更できるようになりました。

他の認証プロバイダーから別の認証プロバイダーへの移行: 前述の規則を変更して、グループ SID S-1-5-21-608905689-872870963-3921916988-12345 内のユーザーに対して Azure AD 多要素認証を選択できます。 たとえば、Azure AD 多要素認証に登録したユーザーを追跡する、エンタープライズで管理するグループに対してこの変更を使用できます。 この変更は、管理者が証明書認証を使用したい残りのユーザーにも機能します。

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’

2 つの異なるアプリケーションに対して 2 つの異なる認証プロバイダーを設定する方法を示す例。

追加の認証プロバイダーとして Azure AD 多要素認証を使用するようにアプリケーション A を設定します。

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

追加の認証プロバイダーとして証明書を使用するようにアプリケーション B を設定します。

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

管理者は、複数の追加認証プロバイダーを許可する規則を作成することもできます。 この場合、AD FS は発行された認証方法プロバイダーを表示し、ユーザーはそれらのいずれかを選択できます。 複数の追加認証プロバイダーを許可するには、複数の要求 http://schemas.microsoft.com/claims/authnmethodsproviders を発行する必要があります。

要求の評価で認証プロバイダーが返されない場合、AD FS はフォールバックして、AD FS の管理者によって構成されたすべての追加の認証プロバイダーが表示されます。 その後、ユーザーは適切な認証プロバイダーを選択する必要があります。

使用許可されている他のすべての認証プロバイダーを取得するには、管理者はコマンドレット (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider を使用できます。 http://schemas.microsoft.com/claims/authnmethodsproviders 要求の値は、上記のコマンドレットによって返されたプロバイダー名のいずれかである必要があります。

RP が 「AD FS Windows Server 2016 のアクセス制御ポリシー | Microsoft Docs」を使用している場合、特定の追加の認証プロバイダーのトリガーはサポートされていません。アプリケーションをアクセス制御ポリシーから移動すると、AD FS は、アクセス制御ポリシーから AdditionalAuthenticationRules および IssuanceAuthorizationRules に対応するポリシーをコピーします。 したがって、管理者が特定の認証プロバイダーを使用したい場合は、アクセス制御ポリシーを使用しない状態から移行して、 AdditionalAuthenticationRules を変更して特定の認証プロバイダーをトリガーできます。

よく寄せられる質問

AD FS 管理イベント ログ エラー "無効な Oauth 要求を受信しました" を解決するにはどうすれば良いですか。 クライアント 'NAME' はスコープ 'ugs' のリソースへのアクセスを禁止されていますか?

問題を修復するには、次の手順に従います。

  1. AD FS 管理コンソールを起動します。 [サービス] > [スコープの説明] の順に移動します。
  2. [スコープの説明] で他のオプションを選択し、[スコープの説明の追加] を選択します。
  3. 名前に "ugs" と入力し、[適用 > OK] を選択します。
  4. 管理者として PowerShell を起動します。
  5. コマンド Get-AdfsApplicationPermission を実行します。 ClientRoleIdentifier を持つ ScopeNames :{openid, aza} を検索します。 ObjectIdentifier を書き留めておきます。
  6. コマンド Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' を実行します。
  7. AD FS サービスを再起動します。
  8. クライアント側で、クライアントを再起動します。 Windows Hello for Business (WHFB) を構成するように求められます。
  9. 構成ウィンドウがポップアップしない場合は、トレース ログを収集し、さらにトラブルシューティングを行う必要があります。

Azure AD に対する要求方法のように、スコープ値の一部としてリソース値を渡すことはできますか?

Server 2019 の AD FS では、リソース値をスコープ パラメーターに埋め込んで渡すことができます。 スコープ パラメーターは、各エントリがリソース/スコープとして構成された、スペース区切りのリストとして作成できるようになりました。 例: <create a valid sample request>

AD FS では PKCE 拡張機能はサポートされていますか?

Server 2019 の AD FS では、OAuth 認証コード付与フロー用の Proof Key for Code Exchange (PKCE) をサポートしています。

Windows Server 2016 の Active Directory フェデレーション サービス (AD FS) の新機能

以前のバージョンの AD FS に関する情報を探している場合は、Windows Server 2012 または 2012 R2 での AD FS と AD FS 2.0 に関する次の記事を参照してください。

AD FS は、Office 365、クラウド ベースの SaaS アプリケーション、社内ネットワーク上のアプリケーションなど、さまざまなアプリケーションにアクセス制御とシングル サインオンを提供します。

  • IT 組織の場合、同じ資格情報とポリシーのセットに基づいて、任意のマシン上の最新のアプリケーションとレガシ アプリケーションの両方にサインオンとアクセス制御を提供できるようになります。
  • ユーザーの場合、同じ使い慣れたアカウント資格情報を使用したシームレスなサインオンが提供されます。
  • 開発者の場合、組織のディレクトリに ID が存在するユーザーを簡単に認証できるため、認証や ID ではなく、アプリケーションに集中できます。

エクストラネットからパスワードを削除する

AD FS 2016 では、パスワードなしでサインオンするための 3 つの新しいオプションが有効になりました。これにより、組織はパスワードのフィッシング、漏えい、盗難によるネットワーク侵害のリスクを回避できます。

Azure Active Directory 多要素認証でサインイン

AD FS 2016 は、Windows Server 2012 R2 の AD FS の多要素認証 (MFA) 機能に基づいて構築されています。 ユーザー名とパスワードを最初に入力せずに、Azure AD 多要素認証コードのみを使用してサインオンを許可できるようになりました。

  • プライマリ認証方法として Azure AD 多要素認証を使用している場合、ユーザーは、Azure Authenticator アプリからユーザー名と OTP コードの入力を求められます。
  • セカンダリまたは追加の認証方法として Azure AD 多要素認証を使用する場合、ユーザーはプライマリ認証資格情報を提供します。 ユーザー名とパスワード、スマート カード、またはユーザー証明書やデバイス証明書を使用して、Windows 統合認証を使用してサインインできます。 その後、テキスト、音声、または OTP ベースの Azure AD 多要素認証サインインのプロンプトが表示されます。
  • 新しい組み込みの Azure AD 多要素認証アダプターを使用すると、AD FS を使用した Azure AD 多要素認証のセットアップと構成がかつてないほど簡単になります。
  • 組織は、オンプレミスの Azure AD 多要素認証サーバーを必要とせずに、Azure AD 多要素認証を利用できます。
  • イントラネット用やエクストラネット用として、またはアクセス制御ポリシーの一部として、 Azure AD 多要素認証を構成できます。

AD FS を使用した Azure AD 多要素認証の詳細については、「AD FS 2016 と Azure AD 多要素認証の構成」を参照してください。

準拠デバイスからのパスワードを使用しないアクセス

AD FS 2016 は、以前のデバイス登録機能に基づいて構築されており、デバイス コンプライアンス状態に基づいたサインオンとアクセス制御を使用できます。 ユーザーはデバイス資格情報を使用してサインオンできます。また、デバイスの属性が変更されるとコンプライアンスが再評価されるため、ポリシーが常に強制されていることを確認できます。 この機能により、次のようなポリシーが有効になります。

  • マネージド デバイスまたは準拠しているデバイスからのアクセスのみを有効にします。
  • マネージド デバイスまたは準拠しているデバイスからのエクストラネット アクセスのみを有効にします。
  • 管理対象ではないコンピューターまたは準拠していないコンピューターに対して多要素認証を要求します。

AD FS では、ハイブリッド シナリオで条件付きアクセス ポリシーに内部設置型コンポーネントを提供します。 クラウド リソースへの条件付きアクセスのために Azure AD にデバイスを登録すると、そのデバイス ID は AD FS ポリシーにも使用できます。

ハイブリッド ソリューションと、ユーザーとオンプレミスの Active Directory の間の関係の図。

クラウドでのデバイス ベースの条件付きアクセスの使用の詳細については、「Azure Active Directory 条件付きアクセス」を参照してください。

AD FS でのデバイス ベースの条件付きアクセスの使用の詳細情報

Windows Hello for Business でサインインする

注意

現在のところ、Google Chrome と Chromium オープン ソース プロジェクト ブラウザーに基づいて構築された新しい Microsoft Edge は、Windows Hello for Business でのブラウザー ベースのシングルサインオン (SSO) ではサポートされていません。 Internet Explorer または以前のバージョンの Microsoft Edge を使用してください。

Windows 10 デバイスでは、Windows Hello および Windows Hello for Business が導入され、ユーザーのパスワードは、ユーザーのジェスチャー (PIN、指紋などの生体認証ジェスチャー、または顔認識) で保護された強力なデバイスバインド ユーザー資格情報に置き換えられました。 AD FS 2016 は、これらの新しい Windows 10 機能をサポートしているため、ユーザーはパスワードを入力しなくてもイントラネットまたはエクストラネットから AD FS アプリケーションにサインインできます。

組織で Windows Hello for Business を使用する方法の詳細については、「組織で Windows Hello for Business を有効にする」を参照してください。

アプリケーションへのアクセスをセキュリティで保護する

次の変更は、AD FS のアプリケーションへのセキュリティで保護されたアクセスに影響します。

先進認証

AD FS 2016 は、Windows 10 および最新の iOS および Android デバイスとアプリのユーザー エクスペリエンスを向上させる最新の先進プロトコルをサポートしています。

詳細については、「開発者向けの AD FS シナリオ」を参照してください。

要求規則言語の知識なしでアクセス制御ポリシーを構成する

以前は、AD FS 管理者は AD FS の要求規則言語を使用してポリシーを構成する必要があり、ポリシーの構成と保守が困難でした。 アクセス制御ポリシーを使用すると、管理者は組み込みのテンプレートを使用して、次のような一般的なポリシーを適用できます

  • イントラネット アクセスのみを許可します。
  • エクストラネットのすべてのユーザーを許可し、MFA を要求します。
  • 特定グループのすべてのユーザーを許可し、MFA を要求します。

テンプレートは、ウィザードが主導するプロセスを使って例外または追加のポリシー規則を追加して簡単にカスタマイズでき、一貫したポリシーを強制するため、1 つまたは複数のアプリケーションに適用できます。

詳細については、「AD FS でのアクセス制御ポリシー」を参照してください。

AD 以外の LDAP ディレクトリでのサインオンを有効にする

多くの組織は、Active Directory とサードパーティのディレクトリを組み合わせています。 ライトウェイト ディレクトリ アクセス プロトコル (LDAP) v3 準拠のディレクトリに保存されているユーザーを認証する AD FS のサポートが追加され、AD FS を次の用途に使用できるようになりました。

  • サード パーティの LDAP v3 準拠ディレクトリ内のユーザー。
  • Active Directory の双方向の信頼が構成されていない Active Directory フォレスト内のユーザー。
  • Active Directory ライトウェイト ディレクトリ サービス (AD LDS) のユーザー。

詳細については、「 Configure AD FS to authenticate users stored in LDAP directories」を参照してください。

サインイン エクスペリエンスの向上

次の変更により、AD FS のサインイン エクスペリエンスが向上します。

AD FS アプリケーションのサインイン エクスペリエンスをカスタマイズする

以前の Windows Server 2012 R2 の AD FS では、すべての証明書利用者アプリケーションに共通のサインオン エクスペリエンスが提供されていて、アプリケーションごとにテキスト ベースのコンテンツのサブセットをカスタマイズする機能が用意されていました。 Windows Server 2016 では、メッセージだけでなく、アプリケーションごとに画像、ロゴ、および Web テーマをカスタマイズできます。 さらに、新しいカスタム Web テーマを作成し、証明書利用者ごとにそれらのテーマの適用ができます。

詳細については、「AD FS のユーザー サインインのカスタマイズ」を参照してください。

管理の容易性と操作性の強化

次のセクションでは、Windows Server 2016 の Active Directory フェデレーション サービス (AD FS) で導入された運用シナリオの改善について説明します。

管理を容易にするための効率的な監査

Windows Server 2012 R2 の AD FS では、1 つの要求に対して多数の監査イベントが生成されていたため、サインインまたはトークン発行アクティビティに関する関連情報が存在しないか、複数の監査イベントに分散しました。 既定で、AD FS 監査イベントは冗長な性質のために無効になっています。 AD FS 2016 のリリースにより、監査が効率化され、冗長性が低くなりました。

詳細については、「Windows Server 2016 での AD FS の監査機能の強化」を参照してください。

コンフェデレーションに参加するための SAML 2.0 との相互運用性の改善

AD FS 2016 には、複数のエンティティを含むメタデータに基づいた信頼のインポートのサポートなど、追加の SAML プロトコルのサポートが含まれています。 この変更により、InCommon フェデレーションや、eGov 2.0 標準に準拠する他の実装など、コンフェデレーションに参加するように AD FS を構成できます。

詳細については、「SAML 2.0 との相互運用性の向上」を参照してください。

フェデレーション Microsoft 365 ユーザーのパスワード管理の簡素化

AD FS で保護されている証明書利用者信頼 (アプリケーション) にパスワードの有効期限要求を送信するように Active Directory フェデレーション サービス (AD FS) を構成することができます。 これらの要求がどのように使用されるかは、アプリケーションによって異なります。 たとえば、証明書利用者として Office 365 を使用している場合、間もなく期限切れになるパスワードをフェデレーション ユーザーに通知できる更新プログラムが Exchange および Outlook に実装されました。

詳細については、「パスワードの有効期限クレームを送信するように AD FS を構成する」を参照してください。

Windows Server 2012 R2 の AD FS から Windows Server 2016 の AD FS への移行が簡単になりました

以前は、AD FS の新しいバージョンに移行するには、古いファームから構成をエクスポートし、新しい並列ファームにインポートする必要がありました。

現在は、Windows Server 2012 R2 の AD FS から Windows Server 2016 の AD FS への移行が簡単になりました。 新しい Windows Server 2016 サーバーを Windows Server 2012 R2 ファームに追加すると、ファームは Windows Server 2012 R2 ファーム動作レベルで動作します。 サーバーは、Windows Server 2012 R2 ファームと同じように見え、動作するようになりました。

次に、新しい Windows Server 2016 サーバーをファームに追加し、機能を確認し、以前のサーバーをロード バランサーから削除します。 すべてのファーム ノードで Windows Server 2016 が動作したら、ファーム動作レベルを 2016 にアップグレードして、新しい機能を使い始める準備は完了です。

詳細については、「Windows Server 2016 での AD FS へのアップグレード」に関する記事を参照してください。