次の方法で共有


承認要求規則を使用する場合

受信要求の種類を実行する必要がある場合は、Active Directory フェデレーション サービス (AD FS) でこの規則を使用し、ルールで指定した値に基づいてユーザーがアクセスを許可または拒否するかどうかを決定するアクションを適用できます。 この規則を使用する場合は、規則で構成したオプションのいずれかに基づいて、次の規則ロジックに一致する要求をパススルーまたは変換します。

ルール オプション ルール ロジック
すべてのユーザーを許可する 受信要求の種類が任意の要求の種類と等しく、値が任意の値と等しい場合は、値が Permit と等しい要求を発行します
この受信クレームを持つユーザーにアクセスを許可する 受信要求の種類が指定された要求の種類と値が指定された要求値と等しい場合は、値が Permit と等しい要求を発行します
この受信クレームを持つユーザーへのアクセスを拒否する 受信要求の種類が指定された要求の種類と値が指定された要求値と等しい場合は、値が Deny と等しい要求を発行します

次のセクションでは、要求規則の基本的な概要と、この規則を使用するタイミングの詳細について説明します。

要求規則について

要求規則は、受信要求を受け取り、条件を適用し (x の場合は y の場合)、条件パラメーターに基づいて送信要求を生成するビジネス ロジックのインスタンスを表します。 次の一覧では、このトピックの詳細を読む前に要求規則について知っておくべき重要なヒントの概要を示します。

  • AD FS 管理スナップインでは、要求規則は要求規則テンプレートを使用してのみ作成できます

  • 要求規則は、要求プロバイダー (Active Directory や別のフェデレーション サービスなど) から直接、または要求プロバイダー信頼に対する受け入れ変換規則の出力から受信要求を処理します。

  • 要求規則は、特定の規則セット内の時系列の順序で要求発行エンジンによって処理されます。 ルールに優先順位を設定することで、特定のルール セット内の以前のルールによって生成された要求をさらに絞り込んだり、フィルター処理したりできます。

  • 要求規則テンプレートでは、常に受信要求の種類を指定する必要があります。 ただし、1 つの規則を使用して、同じ要求の種類を持つ複数の要求値を処理できます。

要求規則と要求規則セットの詳細については、「要求規則 の役割」を参照してください。 ルールの処理方法の詳細については、「 要求エンジンの役割」を参照してください。 要求規則セットの処理方法の詳細については、「要求パイプラインの役割」を参照してください。

すべてのユーザーを許可する

[すべてのユーザーを許可] ルール テンプレートを使用すると、すべてのユーザーが証明書利用者にアクセスできるようになります。 ただし、追加の承認規則を使用して、アクセスをさらに制限することができます。 ある規則でユーザーが証明書利用者へのアクセスを許可し、別の規則が証明書利用者へのアクセスを拒否した場合、拒否の結果は許可の結果をオーバーライドし、ユーザーはアクセスを拒否されます。

フェデレーション サービスから証明書利用者へのアクセスが許可されているユーザーは、引き続き証明書利用者によってサービスを拒否される可能性があります。

この受信クレームを持つユーザーにアクセスを許可する

受信要求規則テンプレートに基づくユーザーの許可または拒否を使用して規則を作成し、許可する条件を設定すると、受信要求の種類と値に基づいて、証明書利用者への特定のユーザーのアクセスを許可できます。 たとえば、このルール テンプレートを使用して、ドメイン管理者の値を持つグループ要求を持つユーザーのみを許可するルールを作成できます。 ある規則でユーザーが証明書利用者へのアクセスを許可し、別の規則が証明書利用者へのアクセスを拒否した場合、拒否の結果は許可の結果をオーバーライドし、ユーザーはアクセスを拒否されます。

ユーザーは、フェデレーション サービスから証明書利用者へのアクセスが許可されても、証明書利用者によってサービスが拒否される場合があります。 すべてのユーザーに証明書利用者へのアクセスを許可する場合は、[すべてのユーザーの許可] ルール テンプレートを使用します。

この受信クレームを持つユーザーへのアクセスを拒否する

受信要求規則テンプレートに基づくユーザーの許可または拒否を使用して規則を作成し、条件を拒否するように設定すると、受信要求の種類と値に基づいて証明書利用者へのユーザーのアクセスを拒否できます。 たとえば、このルール テンプレートを使用して、ドメイン ユーザーの値を持つグループ要求を持つすべてのユーザーを拒否するルールを作成できます。

拒否条件を使用しても、特定のユーザーの証明書利用者へのアクセスを有効にする場合は、後で許可条件を使用して承認規則を明示的に追加して、それらのユーザーが証明書利用者にアクセスできるようにする必要があります。

要求発行エンジンが規則セットを処理するときにユーザーがアクセスを拒否された場合、それ以降のルール処理はシャットダウンされ、AD FS はユーザーの要求に "アクセス拒否" エラーを返します。

ユーザーの承認

AD FS では、認可規則を使って、(使われる要求の種類に応じて) ユーザーまたはユーザー グループが特定の証明書利用者の Web ベースのリソースにアクセスできるかどうかを決定する、許可または拒否要求が発行されます。 認証規則は信頼済みパーティーにのみ設定できます。

認可規則セット

構成する必要がある許可操作または拒否操作の種類に応じて、異なる承認規則セットが存在します。 これらのルール セットには、次のものが含まれます。

  • 発行承認規則: これらの規則は、ユーザーが証明書利用者の要求を受信できるかどうか、したがって証明書利用者へのアクセスを受け取ることができるかどうかを決定します。

  • 委任承認規則: これらの規則は、ユーザーが証明書利用者の別のユーザーとして機能できるかどうかを決定します。 ユーザーが別のユーザーとして機能している場合、要求するユーザーに関する要求は引き続きトークンに配置されます。

  • 偽装権限ルール: これらのルールは、ユーザーが別のユーザーを信頼する当事者に完全に偽装することができるかどうかを判断します。 別のユーザーを偽装することは非常に強力な能力です。なぜなら、関連する当事者はそのユーザーが偽装されていることを知らないからです。

承認規則プロセスが要求発行パイプラインにどのように適合するかの詳細については、「要求発行エンジンの役割」を参照してください。

サポートされている要求の種類

AD FS では、ユーザーが許可されるか拒否されるかを判断するために使用される 2 つの要求の種類を定義します。 これらの要求の種類の URI (Uniform Resource Identifier) は次のとおりです。

  1. 許可: http://schemas.microsoft.com/authorization/claims/permit

  2. 拒否: http://schemas.microsoft.com/authorization/claims/deny

このルールを作成する方法

両方の承認規則を作成するには、要求規則言語を使用するか、[ すべてのユーザーを許可 ] 規則テンプレートを使用するか、AD FS 管理スナップインの 受信要求規則テンプレートに基づいてユーザーを許可または拒否 します。 [すべてのユーザーを許可] ルール テンプレートには、構成オプションはありません。 ただし、受信要求規則テンプレートに基づくユーザーの許可または拒否には、次の構成オプションが用意されています。

  • 要求規則名を指定する

  • 受信要求の種類を指定する

  • 着信要求の値を入力する

  • この受信クレームを持つユーザーにアクセスを許可する

  • この受信クレームを持つユーザーへのアクセスを拒否する

このテンプレートを作成する方法の詳細については、「AD FS 展開ガイド」の「 すべてのユーザーを許可するルールを作成 する」 または「受信要求に基づいてユーザーを許可または拒否するルールを作成 する」を参照してください。

要求規則言語の使用

要求値がカスタム パターンと一致する場合にのみ要求を送信する場合は、カスタム規則を使用する必要があります。 詳細については、「 カスタム要求規則を使用する場合」を参照してください

複数の要求に基づいて承認規則を作成する方法の例

要求規則言語構文を使用して要求を承認する場合、ユーザーの元の要求に複数の要求が存在する場合に基づいて要求を発行することもできます。 次の規則は、ユーザーがグループ エディターのメンバーであり、Windows 認証を使用して認証されている場合にのみ、承認要求を発行します。

[type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
value == "urn:federation:authentication:windows" ]
&& [type == "http://schemas.xmlsoap.org/claims/Group ", value == "editors"]
=> issue(type = "http://schemas.xmlsoap.org/claims/authZ", value = "Granted");

フェデレーション サーバー プロキシ信頼を作成または削除できるユーザーを委任する承認規則を作成する方法の例

フェデレーション サービスがフェデレーション サーバー プロキシを使用してクライアント要求をリダイレクトできるようにするには、まずフェデレーション サービスとフェデレーション サーバー プロキシ コンピューターの間で信頼を確立する必要があります。 既定では、AD FS フェデレーション サーバー プロキシ構成ウィザードで次のいずれかの資格情報が正常に指定されると、プロキシ信頼が確立されます。

  • フェデレーションサービスが使用する、プロキシが保護するサービスアカウント

  • フェデレーション サーバー ファーム内のすべてのフェデレーション サーバーのローカル Administrators グループのメンバーである Active Directory ドメイン アカウント

特定のフェデレーション サービスに対してプロキシ信頼を作成できるユーザーを指定する場合は、次のいずれかの委任方法を使用できます。 このメソッドの一覧は、最も安全で問題の少ない委任方法に関する AD FS 製品チームの推奨事項に基づいて、優先順位が付けられます。 組織のニーズに応じて、次のいずれかの方法のみを使用する必要があります。

  1. Active Directory にドメイン セキュリティ グループ (FSProxyTrustCreators など) を作成し、このグループをファーム内の各フェデレーション サーバーのローカル Administrators グループに追加し、この権限を委任するユーザー アカウントのみを新しいグループに追加します。 可能であればこの方法の使用をお勧めします。

  2. ファーム内の各フェデレーション サーバーの管理者グループにユーザーのドメイン アカウントを追加します。

  3. 何らかの理由でこれらの方法を使用できない場合は、この目的で承認規則を作成することもできます。 この規則が正しく書き込まれていない場合に発生する可能性のある複雑さがあるため、推奨されませんが、カスタム承認規則を使用して、特定のフェデレーション サービスに関連付けられているすべてのフェデレーション サーバー プロキシ間の信頼を作成または削除できる Active Directory ドメイン ユーザー アカウントを委任できます。

    方法 3 を選択した場合は、次の規則構文を使用して、指定されたユーザー (この場合は contoso\frankm) がフェデレーション サービスに対する 1 つ以上のフェデレーション サーバー プロキシの信頼を作成できるようにする承認要求を発行できます。 この規則は、 AddProxyAuthorizationRulesSet-ADFSProperties Windows PowerShell コマンドを使用して適用する必要があります。

    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", issuer=~"^AD AUTHORITY$" value == "contoso\frankm" ] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true")
    
    exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"])
    => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");
    
    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value );
    
    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );
    

    後で、ユーザーがプロキシ信頼を作成できないようにユーザーを削除する場合は、既定のプロキシ信頼承認規則に戻して、ユーザーがフェデレーション サービスのプロキシ信頼を作成する権限を削除できます。 また、 AddProxyAuthorizationRulesSet-ADFSProperties Windows PowerShell コマンドを使用して、この規則を適用する必要があります。

    exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"])
    => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");
    
    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value );
    
    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );
    

要求規則言語の使用方法の詳細については、「要求規則 言語の役割」を参照してください。