次の方法で共有


AD FS 2.0 のクライアント アクセス制御ポリシー

Active Directory フェデレーション サービス 2.0 のクライアント アクセス ポリシーを使用すると、ユーザーにリソースへのアクセスを制限または許可できます。 このドキュメントでは、AD FS 2.0 でクライアント アクセス ポリシーを有効にする方法と、最も一般的なシナリオを構成する方法について説明します。

AD FS 2.0 でのクライアント アクセス ポリシーの有効化

クライアント アクセス ポリシーを有効にするには、次の手順に従います。

手順 1: AD FS サーバーに AD FS 2.0 パッケージの更新プログラムロールアップ 2 をインストールする

Active Directory フェデレーション サービス (AD FS) 2.0 用の更新プログラムロールアップ 2 パッケージをダウンロードし、すべてのフェデレーション サーバーおよびフェデレーション サーバー プロキシにインストールします。

手順 2: Active Directory クレーム プロバイダー信頼に 5 つの要求規則を追加する

すべての AD FS サーバーとプロキシに更新プログラムロールアップ 2 がインストールされたら、次の手順に従って、新しい要求の種類をポリシー エンジンで使用できるようにする一連の要求規則を追加します。

これを行うには、次の手順を使用して、新しい要求コンテキスト要求の種類ごとに 5 つの受け入れ変換規則を追加します。

Active Directory クレームプロバイダーの信頼において、新しいリクエストコンテキストクレームタイプを通過させるための新しい受容変換ルールを作成します。

5 つのコンテキスト要求の種類ごとに Active Directory 要求プロバイダー信頼に要求規則を追加するには:

  1. [スタート] をクリックし、[プログラム] をポイントし、[管理ツール] をポイントして、[AD FS 2.0 管理] をクリックします。

  2. コンソール ツリーの AD FS 2.0\Trust Relationships で、[要求プロバイダーの信頼] をクリックし、[Active Directory] を右クリックし、[要求規則の編集] をクリックします。

  3. [要求規則の編集] ダイアログ ボックスで、[同意変換規則] タブを選択し、[規則の追加] をクリックして規則ウィザードを開始します。

  4. [規則テンプレートの選択] ページの [要求規則テンプレート] で、一覧から [パススルー] または [受信要求のフィルター処理] を選択し、[次へ] をクリックします。

  5. [規則の構成] ページの [要求規則名] に、この規則の表示名を入力します。[受信要求の種類] に、次の要求の種類の URL を入力し、[すべての要求値を渡す] を選択します。
    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

  6. ルールを確認するには、一覧でルールを選択し、[ルールの編集] をクリックし、[ルール言語の表示] をクリックします。 要求規則の言語は次のように表示されます。 c:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"] => issue(claim = c);

  7. 完了をクリックしてください。

  8. [要求規則の編集] ダイアログ ボックスで、[OK] をクリックして規則を保存します。

  9. 手順 2 から 6 を繰り返して、5 つの規則がすべて作成されるまで、以下に示す残りの 4 つの要求の種類ごとに追加の要求規則を作成します。

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

手順 3: Microsoft Office 365 Identity Platform の証明書利用者信頼を更新する

次のいずれかのシナリオ例を選択して、組織のニーズに最も適した Microsoft Office 365 Identity Platform 証明書利用者信頼の要求規則を構成します。

AD FS 2.0 のクライアント アクセス ポリシー のシナリオ

次のセクションでは、AD FS 2.0 に存在するシナリオについて説明します

シナリオ 1: Office 365 への外部アクセスをすべてブロックする

このクライアント アクセス ポリシー シナリオでは、すべての内部クライアントからのアクセスが許可され、外部クライアントの IP アドレスに基づいてすべての外部クライアントがブロックされます。 規則セットは、既定の発行承認規則に基づいて作成され、すべてのユーザーへのアクセスを許可します。 次の手順を使用して、発行承認規則を Office 365 証明書利用者信頼に追加できます。

Office 365 への外部アクセスをすべてブロックするルールを作成するには

  1. [スタート] をクリックし、[プログラム] をポイントし、[管理ツール] をポイントして、[AD FS 2.0 管理] をクリックします。
  2. コンソール ツリーの [AD FS 2.0\Trust Relationships] で、[証明書利用者信頼] をクリックし、Microsoft Office 365 ID プラットフォーム信頼を右クリックして、[要求規則の編集] をクリックします。
  3. [要求規則の編集] ダイアログ ボックスで、[発行承認規則] タブを選択し、[規則の追加] をクリックして要求規則ウィザードを開始します。
  4. [規則テンプレートの選択] ページの [要求規則テンプレート] で、[カスタム規則を使用して要求を送信] を選択し、[次へ] をクリックします。
  5. [規則の構成] ページの [要求規則名] に、この規則の表示名を入力します。 [カスタム規則] で、次の要求規則言語構文を入力するか貼り付けます。 exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. 完了をクリックしてください。 発行承認規則の一覧の [すべてのユーザーへのアクセスを許可する] 規則のすぐ下に新しい規則が表示されることを確認します。
  7. ルールを保存するには、[要求規則の編集] ダイアログ ボックスで [OK] をクリックします。

上記の "パブリック IP アドレス正規表現" の値を有効な IP 式に置き換える必要があります。詳細については、IP アドレス範囲式の作成を参照してください。

シナリオ 2: Exchange ActiveSync を除く Office 365 への外部アクセスをすべてブロックする

次の例では、Outlook を含む内部クライアントから、Exchange Online を含むすべての Office 365 アプリケーションにアクセスできます。 スマート フォンなどの Exchange ActiveSync クライアントを除き、クライアント IP アドレスで示されているように、企業ネットワークの外部に存在するクライアントからのアクセスをブロックします。 規則セットは、既定の発行承認規則に基づいて作成されます。"すべてのユーザーへのアクセスを許可する" というタイトルです。 要求規則ウィザードを使用して Office 365 証明書利用者信頼に発行承認規則を追加するには、次の手順に従います。

Office 365 への外部アクセスをすべてブロックするルールを作成するには

  1. [スタート] をクリックし、[プログラム] をポイントし、[管理ツール] をポイントして、[AD FS 2.0 管理] をクリックします。
  2. コンソール ツリーの [AD FS 2.0\Trust Relationships] で、[証明書利用者信頼] をクリックし、Microsoft Office 365 ID プラットフォーム信頼を右クリックして、[要求規則の編集] をクリックします。
  3. [要求規則の編集] ダイアログ ボックスで、[発行承認規則] タブを選択し、[規則の追加] をクリックして要求規則ウィザードを開始します。
  4. [規則テンプレートの選択] ページの [要求規則テンプレート] で、[カスタム規則を使用して要求を送信] を選択し、[次へ] をクリックします。
  5. [規則の構成] ページの [要求規則名] に、この規則の表示名を入力します。 [カスタム規則] で、次の要求規則言語構文を入力するか貼り付けます。 exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value=="Microsoft.Exchange.Autodiscover"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value=="Microsoft.Exchange.ActiveSync"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. 「完了」をクリックします。 発行承認規則の一覧の [すべてのユーザーへのアクセスを許可する] 規則のすぐ下に新しい規則が表示されることを確認します。
  7. ルールを保存するには、[要求規則の編集] ダイアログ ボックスで [OK] をクリックします。

上記の "パブリック IP アドレス正規表現" の値を有効な IP 式に置き換える必要があります。詳細については、IP アドレス範囲式の作成を参照してください。

シナリオ 3: ブラウザー ベースのアプリケーションを除く Office 365 への外部アクセスをすべてブロックする

規則セットは、既定の発行承認規則に基づいて作成されます。"すべてのユーザーへのアクセスを許可する" というタイトルです。 次の手順を使用して、要求規則ウィザードを使用して Microsoft Office 365 ID プラットフォーム証明書利用者信頼に発行承認規則を追加します。

このシナリオは、パッシブ (Web ベース) 要求を使用するクライアント アクセス ポリシー ヘッダーに制限があるため、サード パーティのプロキシではサポートされていません。

ブラウザー ベースのアプリケーションを除く Office 365 への外部アクセスをすべてブロックするルールを作成するには

  1. [スタート] をクリックし、[プログラム] をポイントし、[管理ツール] をポイントして、[AD FS 2.0 管理] をクリックします。
  2. コンソール ツリーの [AD FS 2.0\Trust Relationships] で、[証明書利用者信頼] をクリックし、Microsoft Office 365 ID プラットフォーム信頼を右クリックして、[要求規則の編集] をクリックします。
  3. [要求規則の編集] ダイアログ ボックスで、[発行承認規則] タブを選択し、[規則の追加] をクリックして要求規則ウィザードを開始します。
  4. [規則テンプレートの選択] ページの [要求規則テンプレート] で、[カスタム規則を使用して要求を送信] を選択し、[次へ] をクリックします。
  5. [規則の構成] ページの [要求規則名] に、この規則の表示名を入力します。 [カスタム規則] で、次の要求規則言語構文を入力するか貼り付けます。 exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. 「完了」をクリックしてください。 発行承認規則の一覧の [すべてのユーザーへのアクセスを許可する] 規則のすぐ下に新しい規則が表示されることを確認します。
  7. ルールを保存するには、[要求規則の編集] ダイアログ ボックスで [OK] をクリックします。

シナリオ 4: 指定された Active Directory グループの Office 365 への外部アクセスをすべてブロックする

次の例では、IP アドレスに基づいて内部クライアントからのアクセスを有効にします。 指定した Active Directory グループ内の個人を除き、外部クライアント IP アドレスを持つ企業ネットワークの外部に存在するクライアントからのアクセスをブロックします。規則セットは、既定の発行承認規則に基づいて作成されます。"すべてのユーザーへのアクセスを許可" というタイトルです。 次の手順を使用して、要求規則ウィザードを使用して Microsoft Office 365 ID プラットフォーム証明書利用者信頼に発行承認規則を追加します。

指定された Active Directory グループの Office 365 への外部アクセスをすべてブロックするルールを作成するには

  1. [スタート] をクリックし、[プログラム] をポイントし、[管理ツール] をポイントして、[AD FS 2.0 管理] をクリックします。
  2. コンソール ツリーの [AD FS 2.0\Trust Relationships] で、[証明書利用者信頼] をクリックし、Microsoft Office 365 ID プラットフォーム信頼を右クリックして、[要求規則の編集] をクリックします。
  3. [要求規則の編集] ダイアログ ボックスで、[発行承認規則] タブを選択し、[規則の追加] をクリックして要求規則ウィザードを開始します。
  4. [規則テンプレートの選択] ページの [要求規則テンプレート] で、[カスタム規則を使用して要求を送信] を選択し、[次へ] をクリックします。
  5. [規則の構成] ページの [要求規則名] に、この規則の表示名を入力します。 [カスタム規則] で、次の要求規則言語構文を入力するか貼り付けます。 exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. 完了をクリックします。 発行承認規則の一覧の [すべてのユーザーへのアクセスを許可する] 規則のすぐ下に新しい規則が表示されることを確認します。
  7. ルールを保存するには、[要求規則の編集] ダイアログ ボックスで [OK] をクリックします。

上記のシナリオで使用される要求規則言語構文の説明

説明 要求規則言語の構文
すべてのユーザーへのアクセスを許可する既定の AD FS 規則。 この規則は、Microsoft Office 365 Identity Platform の証明書利用者信頼発行承認規則の一覧に既に存在している必要があります。 => issue(Type = "<https://schemas.microsoft.com/authorization/claims/permit>", Value = "true");
この句を新しいカスタム 規則に追加すると、要求がフェデレーション サーバー プロキシから送信されたことが指定されます (つまり、x-ms-proxy ヘッダーがあります)。
すべてのルールにこれを含めるのが推奨されます。 exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy>"])
要求が、定義された許容範囲内の IP を持つクライアントからの要求であることを確立するために使用されます。 NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip>", Value=~"customer-provided public ip address regex"])
この句は、アクセスするアプリケーションが Microsoft.Exchange.ActiveSync でない場合は要求を拒否するように指定するために使用されます。 NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application>", Value=="Microsoft.Exchange.ActiveSync"])
このルールを使用すると、呼び出しが Web ブラウザーを通じて行われたかどうかを判断でき、拒否されません。 NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path>", Value == "/adfs/ls/"])
この規則では、(SID 値に基づいて) 特定の Active Directory グループ内の唯一のユーザーを拒否する必要があることを示します。 このステートメントに NOT を追加すると、場所に関係なく、ユーザーのグループが許可されます。 exists([Type == "<https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid>", Value =~ "{Group SID value of allowed AD group}"])
これは、上記のすべての条件が満たされたときに拒否を発行するために必要な句です。 => issue(Type = "<https://schemas.microsoft.com/authorization/claims/deny>", Value = "true");

IP アドレス範囲式の構築

x-ms-forwarded-client-ip 要求は、現在 Exchange Online によってのみ設定される HTTP ヘッダーから設定されます。Exchange Online は、認証要求を AD FS に渡す際にこのヘッダーを設定します。 要求の値は、次のいずれかになります。

Exchange Online では現在、IPV4 のみがサポートされており、IPV6 アドレスはサポートされていません。

1 つの IP アドレス: Exchange Online に直接接続されているクライアントの IP アドレス

企業ネットワーク上のクライアントの IP アドレスは、組織の送信プロキシまたはゲートウェイの外部インターフェイス IP アドレスとして表示されます。

VPN または Microsoft DirectAccess (DA) によって企業ネットワークに接続されているクライアントは、VPN または DA の構成によっては、内部企業クライアントまたは外部クライアントとして表示される場合があります。

1 つ以上の IP アドレス: Exchange Online は、接続しているクライアントの IP アドレスを特定できない場合、x-forwarded-for ヘッダーの値に基づいて値を設定します。これは、HTTP ベースの要求に含めることができる非標準ヘッダーであり、市場の多くのクライアント、ロード バランサー、プロキシでサポートされます。

クライアント IP アドレスと要求を渡した各プロキシのアドレスを示す複数の IP アドレスは、コンマで区切られます。

Exchange Online インフラストラクチャに関連する IP アドレスは一覧に表示されません。

正規表現

IP アドレスの範囲を一致させる必要がある場合は、比較を実行する正規表現を構築する必要があります。 次の一連の手順では、次のアドレス範囲に一致するようにこのような式を構築する方法の例を示します (パブリック IP 範囲に一致するようにこれらの例を変更する必要があることに注意してください)。

  • 192.168.1.1 – 192.168.1.25
  • 10.0.0.1 – 10.0.0.14

最初に、1 つの IP アドレスに一致する基本的なパターンは次のとおりです。\b###.##.###.##\b

これを拡張すると、次のように 2 つの異なる IP アドレスを OR 式と照合できます。\b###.###.###\b|\b###.##.#\b

したがって、2 つのアドレス (192.168.1.1 や 10.0.0.1 など) と一致する例は、\b192.168.1.1\b|\b10.0.0.1\b になります。

これにより、任意の数のアドレスを入力できる手法が提供されます。 192.168.1.1 – 192.168.1.25 のようにアドレスの範囲を許可する必要がある場合は、次のように、文字ごとに一致を行う必要があります。\b192.168.1.([1-9]|1[0-9]|2[0-5])\b

IP アドレスは、数値ではなく文字列として扱われます。

ルールは次のように分類されます: \b192.168.1。

これは、192.168.1 以降の任意の値と一致します。

次は、最後の小数点の後のアドレスの部分に必要な範囲と一致します。

  • ([1-9] 1 から 9 で終わるアドレスに一致します
  • |1[0-9] 10 から 19 で終わるアドレスに一致します
  • |2[0-5]) 20 から 25 で終わるアドレスに一致します

IP アドレスの他の部分から照合が始まらないようにするため、かっこを正しく配置する必要があります。

192 ブロックが一致したので、10 ブロックに対して同様の式を記述できます: \b10.0.0。([1-9]|1[0-4])\b

それらをまとめれば、次の式は"192.168.1.1~25" と "10.0.0.1~14" のすべてのアドレスと一致する必要があります: \b192.168.1。([1-9]|1[0-9]|2[0-5])\b|\b10.0.0.([1-9]|1[0-4])\b

式のテスト

正規表現式は非常に複雑になる可能性があるため、正規表現検証ツールを使用することを強くお勧めします。 "オンライン正規表現式ビルダー" をインターネットで検索する場合は、サンプル データに対して式を試用できる優れたオンライン ユーティリティがいくつか見つかります。

式をテストするときは、一致する必要がある内容を理解することが重要です。 Exchange オンライン システムは、コンマで区切って多数の IP アドレスを送信できます。 上記の式は、これに対して機能します。 ただし、正規表現式をテストするときは、この点を考慮することが重要です。 たとえば、次のサンプル入力を使用して、上記の例を確認できます。

192.168.1.1, 192.168.1.2, 192.169.1.1. 192.168.12.1, 192.168.1.10, 192.168.1.25, 192.168.1.26, 192.168.1.30, 1192.168.1.20

10.0.0.1, 10.0.0.5, 10.0.0.10, 10.0.1.0, 10.0.1.1, 110.0.0.1, 10.0.0.14, 10.0.0.15, 10.0.0.10, 10,0.0.1

デプロイの検証

セキュリティ監査ログ

新しい要求コンテキスト要求が送信され、AD FS 要求処理パイプラインで使用できるかどうかを確認するには、AD FS サーバーで監査ログを有効にします。 次に、いくつかの認証要求を送信し、標準のセキュリティ監査ログ エントリの要求値を確認します。

AD FS サーバー上のセキュリティ ログへの監査イベントのログ記録を有効にするには、「AD FS 2.0 の監査を構成する」の手順に従います。

イベント ログ

既定では、失敗した要求は、アプリケーションとサービス ログ \ AD FS 2.0 \ Admin の下にあるアプリケーション イベント ログに記録されます。AD FS のイベント ログの詳細については、「 AD FS 2.0 イベント ログの設定」を参照してください。

詳細 AD FS トレース ログの構成

AD FS トレース イベントは、AD FS 2.0 デバッグ ログに記録されます。 トレースを有効にするには、「 AD FS 2.0 のデバッグ トレースを構成する」を参照してください。

トレースを有効にしたら、次のコマンド ライン構文を使用して詳細ログ レベルを有効にします。 wevtutil.exe sl "AD FS 2.0 Tracing/Debug" /l:5

新しい要求の種類の詳細については、「 AD FS 要求の種類」を参照してください