GlobalProtect 認証は Cookie と CSC を上書きします
9907
Created On 04/12/22 15:39 PM - Last Modified 05/13/24 21:52 PM
Symptom
認証オーバーライドCookieは、「デバイスチェック」および「カスタムチェック」に基づく設定選択基準(CSC)と組み合わせて使用すると機能しない場合があります。
Environment
- GlobalProtect(認証オーバーライドCookie)が構成されている
- 「デバイスチェック」および「カスタムチェック」に基づく設定選択基準(CSC)を使用したポータル設定(ユーザー/ユーザーグループ設定選択基準とは関係ありません)
Cause
「デバイスチェック」と「カスタムチェック」に基づく設定選択基準(CSC)は、クライアントが認証された後、適切なポータルエージェント設定と照合するために、GPクライアントから(getconfig_csc.espを介して)追加情報を収集することに依存しています。 一方、認証オーバーライドの Cookie 処理設定 (生成/承認) は、ポータル エージェント構成内で指定されます。 設定はクライアント認証とgetconfig_csc交換の後にのみ適切に決定されるため、手遅れになるまでクッキーが受け入れられるかどうかは確かではありません(鶏と卵のような問題)。
これが、Authentication OverrideとConfig Selection Criteria -> Device Checks/Custom Checksの両方が設定されているというコミット警告メッセージが追加された
理由です。 認証の上書きは無効
になりますが、Cookieを無効にしているわけではありませんが、残りの設定に応じて、構成が意図したとおりに機能する場合と機能しない場合があります。
動作しない例:
- CSCベースの設定(上)はCookieを受け入れますが、以下のmatch-all設定(CSCベースではない)はCookieを受け入れません
- 認証プロセス中、ポータル(サーバー側)はCookieが許可されているかどうかを評価する必要がありますが、認証後の「getconfig_csc.esp」交換までCSCベースの構成が一致するかどうかを判断することはできません
- この時点で、サーバー側は一致する可能性のある設定(CSC基準のない設定)を見つけ、Cookie関連の設定(この例ではCookieを受け入れない)を使用し、最終的にはCookieを許可するCSCベースの設定(「getconfig_csc.esp」交換後)と一致しますが、ユーザーは認証を強制されます
ポータル接続プロセスは、以下のとおりです。
- 認証プロファイルや証明書プロファイルによる認証(OSによる区別が可能)
- Cookieは、Cookieを受け入れるCSCチェックを必要としないポータルエージェント設定の一致の可能性がある場合に許可/受け入れられる可能性があります。これにより、適切な構成の選択を「getconfig_csc」する前に、Cookieを受け入れることができます。
- 注:(CSC交換前の)設定の一致の可能性とCookieの使用有無に関係なく、最終的には常に正しいエージェント設定を照合します。 ユーザーは常に意図した設定を受け取り、「事前照合された」設定は、認証プロセス中にCookieを処理する方法を決定するためにサーバー側でのみ使用されます。
- 認証後(Cookieの有無にかかわらず)、「getconfig_csc」は、ポータルエージェント構成と完全に一致させるために必要な追加の詳細を提供します。
Resolution
「GlobalProtect Portal Configuration > Agent」にリストされているクライアント構成に応じて、「デバイスチェック」と「カスタムチェック」の設定に基づいて、設定選択基準(CSC)による認証オーバーライドが成功する場合とできない場合があります。
シナリオ 1 : すべてのポータル エージェント構成が Cookie を受け入れている
このシナリオは実現可能です。 Cookieを受け入れ、CSC評価の前に「事前照合」できる非CSCベースのポータルエージェント設定があることを確認する必要があります。 個々のCSCベースの構成を複製し、CSC選択部分を取り除き、CSCベースの構成のすぐ下にクローンを配置するか(構成が多数ある場合、それほどエレガントではありません)、またはリストの最後に「キャッチオール」の非CSCベースのエージェント構成を配置して、適切なCookie受け入れ設定を保持することができます。この特定の構成は、機能(および/または割り当てられたゲートウェイ)の観点から制限する必要がありますが、重要なのは、「最終的な」構成の一致(CSC評価後)ではまったくヒットせず、Cookieの処理にのみ利用する必要があるということです。 お客様は、このポリシーを下部に追加せずにCookie機能を許可している可能性のある一致する非CSCベースの構成をすでに持っている可能性があります。
シナリオ 2 : すべてのポータル エージェント構成が Cookie を受け入れない
このシナリオも実現可能です。 ここには特別な指示はありません。 Cookie は、ポータル エージェント構成で有効にしないでください。
シナリオ 3 : 混合構成 オプション (一部のエージェント構成は Cookie を受け入れますが、一部は受け入れません)
このシナリオは、エンド カスタマーが何を達成しようとしているかに応じて、達成できる場合とできない場合があります。可能であれば、一貫性のあるCookieポリシー(シナリオ1/2)を持つことをお勧めします。
CSCが関与する混合構成(Cookieの観点から)のいくつかを実現する方法は、(シナリオ1と同様)次のとおりです。
- CSC ベースの設定のクローニング
- CSCベースの要件(「デバイスチェック」および「カスタムチェック」条件)の複製された設定の除去
- 複製されたCSCベースのポリシーのすぐ下に配置します
「複製された」設定アプローチのもう 1 つの問題は、CSC 部分が取り除かれた後、複数の CSC ベースの設定クローンが同じように見える可能性があることです。
例：
- CSC_A設定とCSC_B設定では、それぞれ非CSCベースのクローンが CSC_A、 Non_CSC_A_Clone、 CSC_B、 Non_CSC_B_Cloneの順序で作成されます。
- 「クローン」設定が同じ場合、 Non_CSC_B_Clone 一致することはなく、 Non_CSC_A_Clone設定が常に使用されることを意味します( CSC_A と CSC_B で異なるCookie処理が必要な場合に問題があります)。