Windows Server 2012 R2 および Windows Server 2012 AD FS のアクセス制御ポリシー

[アーティクル]
02/13/2024

この記事で説明するポリシーでは、次の 2 種類の要求を使用します。

AD FS や Web アプリケーションプロキシで検査および検証できる情報 (AD FS に直接接続しているクライアントや WAP の IP アドレスなど) に基づいて AD FS が作成する要求。
クライアントによって HTTP ヘッダーとして AD FS に転送される情報に基づいて AD FS が作成する要求。

重要: 以下で説明するポリシーは、次の追加エンドポイントへのアクセスに必要な Windows 10 のドメイン参加およびサインオンシナリオをブロックします。

Windows 10 のドメイン参加およびサインオンに必要な AD FS エンドポイント

[フェデレーションサービス名]/adfs/services/trust/2005/windowstransport
[フェデレーションサービス名]/adfs/services/trust/13/windowstransport
[フェデレーションサービス名]/adfs/services/trust/2005/usernamemixed
[フェデレーションサービス名]/adfs/services/trust/13/usernamemixed
[フェデレーションサービス名]/adfs/services/trust/2005/certificatemixed
[フェデレーションサービス名]/adfs/services/trust/13/certificatemixed

重要: /adfs/services/trust/2005/windowstransport エンドポイントと /adfs/services/trust/13/windowstransport エンドポイントは、HTTPS で WIA バインディングを使用するイントラネット接続用のエンドポイントであるので、イントラネットアクセスに対してのみ有効にする必要があります。それらをエクストラネットに公開すると、これらのエンドポイントに対する要求によってロックアウト保護がバイパスされる可能性があります。 AD アカウントのロックアウトを保護するため、プロキシではこれらのエンドポイントを無効にする (つまり、エクストラネットから無効にする) 必要があります。

解決するには、エンドポイント要求に基づいて拒否するすべてのポリシーを更新して、上記のエンドポイントに対して例外を許可するようにします。

たとえば、次の規則を

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[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 = " DenyUsersWithClaim");

次のように更新します。

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value != "(/adfs/ls/)|(/adfs/services/trust/2005/windowstransport)|(/adfs/services/trust/13/windowstransport)|(/adfs/services/trust/2005/usernamemixed)|(/adfs/services/trust/13/usernamemixed)|(/adfs/services/trust/2005/certificatemixed)|(/adfs/services/trust/13/certificatemixed)"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");

注意

このカテゴリからの要求は、ネットワークへのアクセスを保護するためのセキュリティポリシーとしてではなく、ビジネスポリシーを実装するためにのみ使用する必要があります。承認されていないクライアントが、アクセスを取得するための手段として、誤った情報を含むヘッダーを送信する可能性があります。

この記事で説明されているポリシーは、ユーザー名とパスワードや多要素認証など、他の認証方法と常に併用する必要があります。

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

シナリオ	説明
シナリオ 1: Office 365 への外部アクセスをすべてブロックする	Office 365 アクセスは、企業内部のネットワークのすべてのクライアントからのものは許可されますが、外部クライアントからの要求はその外部クライアントの IP アドレスに基づいて拒否されます。
シナリオ 2: Exchange ActiveSync を除く Office 365 へのすべての外部アクセスをブロックする	Office 365 アクセスは、企業内部のネットワークのすべてのクライアントからのものに加えて、Exchange ActiveSync を使用するスマートフォンなどの外部クライアントデバイスからのものも許可されます。 Outlook を使用するものなど、他のすべての外部クライアントはブロックされます。
シナリオ 3: ブラウザーベースのアプリケーションを除く Office 365 へのすべての外部アクセスをブロックする	Outlook Web Access や SharePoint Online などのパッシブ (ブラウザーベース) アプリケーションを除く、Office 365 への外部アクセスをブロックします。
シナリオ 4: 指定された Active Directory グループを除く Office 365 へのすべての外部アクセスをブロックする	このシナリオは、クライアントアクセスポリシーの展開をテストおよび検証するために使用されます。このシナリオは、1 つ以上の Active Directory グループのメンバーに対してのみ、Office 365 への外部アクセスをブロックします。これは、特定のグループのメンバーに対してのみ外部アクセスを提供するのにも使用できます。

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

Windows Server 2012 R2 の AD FS でクライアントアクセスポリシーを有効にするには、Microsoft Office 365 ID プラットフォームの証明書利用者信頼を更新する必要があります。次のシナリオ例のいずれかを選択して、組織のニーズに最も合った Microsoft Office 365 ID プラットフォームの証明書利用者信頼に対する要求規則を構成します。

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

このクライアントアクセスポリシーシナリオは、すべての内部クライアントからのアクセスを許可し、すべての外部クライアントを、その外部クライアントの IP アドレスに基づいてブロックします。次の手順に従うことにより、選択したシナリオに合わせて、Office 365 証明書利用者信頼に適切な発行認可規則を追加できます。

Office 365 へのすべての外部アクセスをブロックする規則を作成する方法

[サーバーマネージャー] で [ツール] をクリックして、[AD FS の管理] をクリックします。
コンソールツリーの [AD FS\信頼関係] の下にある、[証明書利用者信頼] をクリックし、[Microsoft Office 365 ID プラットフォーム] 信頼を右クリックして、[要求規則の編集] をクリックします。
[要求規則の編集] ダイアログボックスで、[発行認可規則] タブを選択し、[規則の追加] をクリックして、要求規則ウィザードを開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP 要求が存在する場合は、拒否します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力または貼り付けます (上の "x-ms-forwarded-client-ip" の値を有効な IP 式に置き換えてください)。c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");
[完了] をクリックします。発行認可規則の一覧で、新しい規則が、既定の [すべてのユーザーにアクセスを許可する] 規則よりも前に表示されていることを確認します (拒否規則は、一覧で先に表示されていても優先されます)。既定のアクセス許可規則がない場合は、要求規則言語を次のように使用して、一覧の末尾に追加できます。

c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");
新しい規則を保存するため、[要求規則の編集] ダイアログボックスで [OK] をクリックします。結果の一覧は次のようになります。

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

次の例では、Outlook を含む内部クライアントからの、Exchange Online を含むすべての Office 365 アプリケーションへのアクセスを許可します。これは、スマートフォンなどの Exchange ActiveSync クライアントを除く、企業ネットワークの外部に存在するクライアントからのアクセスを、そのクライアント IP アドレスに従ってブロックします。

Exchange ActiveSync を除く Office 365 へのすべての外部アクセスをブロックする規則を作成する方法

[サーバーマネージャー] で [ツール] をクリックして、[AD FS の管理] をクリックします。
コンソールツリーの [AD FS\信頼関係] の下にある、[証明書利用者信頼] をクリックし、[Microsoft Office 365 ID プラットフォーム] 信頼を右クリックして、[要求規則の編集] をクリックします。
[要求規則の編集] ダイアログボックスで、[発行認可規則] タブを選択し、[規則の追加] をクリックして、要求規則ウィザードを開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP 要求が存在する場合は、ipoutsiderange 要求を発行します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力または貼り付けます (上の "x-ms-forwarded-client-ip" の値を有効な IP 式に置き換えてください)。

c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");
[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP が存在し、かつ EAS 以外の x-ms-client-application claim が存在する場合は、拒否します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力するか貼り付けます。
```
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value != "Microsoft.Exchange.ActiveSync"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
```
[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「アプリケーション要求が存在するかどうかを確認します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力するか貼り付けます。
```
NOT EXISTS([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application"]) => add(Type = "http://custom/xmsapplication", Value = "fail");
```
[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「ipoutsiderange が true のユーザーを拒否し、アプリケーションは失敗します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力するか貼り付けます。
```
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/xmsapplication", Value == "fail"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
```
[完了] をクリックします。発行認可規則の一覧で、新しい規則が、前の規則のすぐ下にあり、既定の [すべてのユーザーにアクセスを許可する] 規則よりも前に表示されていることを確認します (拒否規則は、一覧で先に表示されていても優先されます)。
既定のアクセス許可規則がない場合は、要求規則言語を次のように使用して、一覧の末尾に追加できます。
```
c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");
```
新しい規則を保存するため、[要求規則の編集] ダイアログボックスで [OK] をクリックします。結果の一覧は次のようになります。

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

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

[サーバーマネージャー] で [ツール] をクリックして、[AD FS の管理] をクリックします。
コンソールツリーの [AD FS\信頼関係] の下にある、[証明書利用者信頼] をクリックし、[Microsoft Office 365 ID プラットフォーム] 信頼を右クリックして、[要求規則の編集] をクリックします。
[要求規則の編集] ダイアログボックスで、[発行認可規則] タブを選択し、[規則の追加] をクリックして、要求規則ウィザードを開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP 要求が存在する場合は、ipoutsiderange 要求を発行します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力または貼り付けます (上の "x-ms-forwarded-client-ip" の値を有効な IP 式に置き換えてください)。

c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");

[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP が存在し、かつエンドポイントが /adfs/ls でない場合は、拒否します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力するか貼り付けます。
```
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[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 = " DenyUsersWithClaim");`
```
[完了] をクリックします。発行認可規則の一覧で、新しい規則が、既定の [すべてのユーザーにアクセスを許可する] 規則よりも前に表示されていることを確認します (拒否規則は、一覧で先に表示されていても優先されます)。

既定のアクセス許可規則がない場合は、要求規則言語を次のように使用して、一覧の末尾に追加できます。

c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

新しい規則を保存するため、[要求規則の編集] ダイアログボックスで [OK] をクリックします。結果の一覧は次のようになります。

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

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

指定された Active Directory グループを除く Office 365 へのすべての外部アクセスをブロックする規則を作成する方法

[サーバーマネージャー] で [ツール] をクリックして、[AD FS の管理] をクリックします。
コンソールツリーの [AD FS\信頼関係] の下にある、[証明書利用者信頼] をクリックし、[Microsoft Office 365 ID プラットフォーム] 信頼を右クリックして、[要求規則の編集] をクリックします。
[要求規則の編集] ダイアログボックスで、[発行認可規則] タブを選択し、[規則の追加] をクリックして、要求規則ウィザードを開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「目的の範囲外の IP 要求が存在する場合は、ipoutsiderange 要求を発行します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力または貼り付けます (上の "x-ms-forwarded-client-ip" の値を有効な IP 式に置き換えてください)。
```
`c1:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] && c2:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");`
```
[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「グループ SID を確認します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力または貼り付けます ("groupsid" は、使用している AD グループの実際の SID に置き換えてください)。
```
NOT EXISTS([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-100"]) => add(Type = "http://custom/groupsid", Value = "fail");
```
[完了] をクリックします。新しい規則が発行認可規則の一覧に表示されていることを確認します。
次に、[要求規則の編集] ダイアログボックスの [発行認可規則] タブで、[規則の追加] をクリックして、要求規則ウィザードをもう一度開始します。
[規則テンプレートの選択] ページの [要求規則テンプレート] の下にある、[カスタム規則を使用して要求を送信] を選択して、[次へ] をクリックします。
[規則の構成] ページの [要求規則名] に、この規則の表示名を入力します (「ipoutsiderange が true のユーザーを拒否し、groupsid は失敗します」など)。 [カスタム規則] の下に、次の要求規則言語構文を入力するか貼り付けます。

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/groupsid", Value == "fail"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

[完了] をクリックします。発行認可規則の一覧で、新しい規則が、前の規則のすぐ下にあり、既定の [すべてのユーザーにアクセスを許可する] 規則よりも前に表示されていることを確認します (拒否規則は、一覧で先に表示されていても優先されます)。

既定のアクセス許可規則がない場合は、要求規則言語を次のように使用して、一覧の末尾に追加できます。

c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

新しい規則を保存するため、[要求規則の編集] ダイアログボックスで [OK] をクリックします。結果の一覧は次のようになります。

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

これを拡張して、次のように OR 式を使用すると、2 つの異なる IP アドレスと一致させることができます。\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

式のテスト

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

式をテストする場合、一致する必要があるものについて理解することが重要です。 Exchange Online のシステムは、多くの 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

信頼性情報の種類

Windows Server 2012 R2 の AD FS は、次の要求の種類を使用して要求コンテキスト情報を提供します。

X-MS-Forwarded-Client-IP

要求の種類: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

この AD FS 要求は、要求を行うユーザー (Outlook クライアントなど) の IP アドレスを確認する "最適な試行" を表します。この要求には、要求を転送したそれぞれのプロキシのアドレスを含む、複数の IP アドレスを含めることができます。この要求は HTTP から設定されます。この要求の値には、次のいずれかを指定できます。

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

注意

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

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

注意

Exchange Online のインフラストラクチャに関連した IP アドレスは、この一覧には含まれません。

警告

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

X-MS-Client-Application

要求の種類: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

この AD FS 要求は、エンドクライアントによって使用されるプロトコルを表します。これは、使用されているアプリケーションにある程度対応します。この要求は、現在 Exchange Online によってのみ設定されている HTTP ヘッダーから設定されます。Exchange Online は、認証要求を AD FS に渡す際にこのヘッダーを設定します。アプリケーションによって、この要求の値は次のいずれかになります:

Exchange Active Sync を使用するデバイスの場合、値は Microsoft.Exchange.ActiveSync です。
Microsoft Outlook クライアントを使用すると、次の値のいずれかになる可能性があります:
- Microsoft.Exchange.Autodiscover
- Microsoft.Exchange.OfflineAddressBook
- Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices
- Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices
このヘッダーが取りうる他の値には、次のものが含まれます。
- Microsoft.Exchange.Powershell
- Microsoft.Exchange.SMTP
- Microsoft.Exchange.Pop
- Microsoft.Exchange.Imap

X-MS-Client-User-Agent

要求の種類: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

この AD FS 要求は、クライアントがサービスへのアクセスに使用しているデバイスの種類を表す文字列を提供します。これは、顧客が特定のデバイス (特定の種類のスマートフォンなど) のアクセスを防ぎたい場合に使用できます。この要求の値の例には、次のものが含まれます (これら以外の値も考えられます)。

x-ms-client-application が "Microsoft.Exchange.ActiveSync" であるクライアントの場合に x-ms-user-agent の値に含まれる可能性のあるものの例を次に示します。

Vortex/1.0
Apple-iPad1C1/812.1
Apple-iPhone3C1/811.2
Apple-iPhone/704.11
Moto-DROID2/4.5.1
SAMSUNGSPHD700/100.202
Android/0.3

この値が空である場合もあります。

X-MS-Proxy

要求の種類: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

この AD FS 要求は、要求が Web アプリケーションプロキシを通過したことを示します。この要求は、Web アプリケーションプロキシによって設定されます。このプロキシは、認証要求をバックエンドフェデレーションサービスに渡す際にこのヘッダーを設定します。その後、AD FS がこれを要求に変換します。

この要求の値は、その要求を渡した Web アプリケーションプロキシの DNS 名です。

InsideCorporateNetwork

要求の種類: https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

上述の x-ms-proxy という要求の種類と同様に、この要求の種類は、要求が Web アプリケーションプロキシを通過したかどうかを示します。 x-ms-proxy とは異なり insidecorporatenetwork はブール値で、True である場合は、企業ネットワーク内からフェデレーションサービスへの直接の要求であることを示します。

X-MS-Endpoint-Absolute-Path (アクティブまたはパッシブ)

要求の種類: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

この要求の種類は、"アクティブ" (リッチ) クライアントからの要求と "パッシブ" (Web ブラウザーベース) クライアントからの要求を判別するために使用できます。これを使用すると、Microsoft Outlook などのリッチクライアントからの要求をブロックしながら、Outlook Web Access、SharePoint Online、Office 365 ポータルなどのブラウザーベースのアプリケーションからの外部要求を許可できます。

この要求の値は、その要求を受け取った AD FS サービスの名前です。

参照

AD FS の運用