GlobalProtect 身份验证覆盖 Cookie 和 CSC
9933
Created On 04/12/22 15:39 PM - Last Modified 05/13/24 21:52 PM
Symptom
当与基于“设备检查”和“自定义检查”的配置选择标准 （CSC） 结合使用时，身份验证覆盖 cookie 可能不起作用。
Environment
- 配置了身份验证覆盖 Cookie 的 GlobalProtect
- 使用基于“设备检查”和“自定义检查”的配置选择标准 （CSC） 进行门户配置（与用户/用户组配置选择标准无关）
Cause
基于“设备检查”和“自定义检查”的配置选择标准 （CSC） 依赖于在客户端通过身份验证后从 GP 客户端（通过 getconfig_csc.esp）收集其他信息，以便匹配正确的门户代理配置。 另一方面，身份验证覆盖 cookie 处理设置（生成/接受）在门户代理配置中指定。 由于只有在客户端身份验证和getconfig_csc交换后才能正确确定配置，因此我们无法确定是否接受cookie，直到为时已晚（先有鸡还是先有蛋的问题）。
这就是为什么添加了提交警告消息的原因：
身份验证覆盖和配置选择标准 - >设备检查/自定义检查都已配置。 身份验证覆盖将被禁用
虽然我们没有禁用 cookie，但配置可能会也可能不会按预期工作，具体取决于设置的其余部分。
非工作示例：
- 基于 CSC 的配置（顶部）接受 cookie，而下面的全部匹配配置（非基于 CSC）不接受 cookie
- 在认证过程中，Portal（服务器端）需要评估是否允许cookie，但无法确定基于CSC的配置是否匹配，直到认证后的“getconfig_csc.esp”交换
- 此时，服务器端将找到一个潜在的配置匹配（没有 CSC 标准的配置）并使用其与 cookie 相关的设置（在此特定示例中 - 不接受 cookie），并且用户将被迫进行身份验证，即使它最终将匹配基于 CSC 的配置（在“getconfig_csc.esp”交换之后），它确实允许 cookie
门户连接过程如下：
- 基于身份验证配置文件和/或证书配置文件的身份验证（可能根据操作系统进行区分）。
- 如果存在潜在的门户代理配置匹配，则允许/接受 Cookie，而 CSC 检查也接受 Cookie;这将允许在“getconfig_csc”正确的配置选择之前接受 cookie。
- 注意：无论潜在的配置匹配（在CSC交换之前）和是否使用cookie，我们最终始终匹配正确的代理配置！ 用户将始终收到其预期的配置，“预匹配”配置仅在服务器端用于决定如何在身份验证过程中处理 cookie。
- 身份验证（有或没有 cookie）后，“getconfig_csc”会提供正确匹配确切的门户代理配置所需的其他详细信息。
Resolution
根据“GlobalProtect Portal Configuration > Agent”下列出的客户端配置，我们可能会也可能不会根据配置的“设备检查”和“自定义检查”配置选择标准 （CSC） 进行身份验证覆盖。
场景 1 ： 所有门户代理配置都接受 cookie
此方案是可以实现的。 我们需要确保有一个非基于 CSC 的门户代理配置接受 cookie，并且可以在 CSC 评估之前进行“预匹配”。 我们可以克隆单个基于 CSC 的配置，剥离 CSC 选择部分，并将克隆放在基于 CSC 的配置下面（如果有很多配置，那就不那么优雅了），或者我们可以在列表末尾有一个“包罗万象”的非基于 CSC 的代理配置，它将保存正确的 cookie 接受设置;这个特定的配置应该在功能（和/或分配的网关）方面受到限制，但关键是它不应该在“最终”配置匹配（在 CSC 评估之后）被击中，而只用于 cookie 处理。 客户可能已经拥有非基于 CSC 的配置，这些配置具有潜在的匹配项，这些配置允许 Cookie 功能，而无需在底部添加此策略。
场景 2 ： 所有门户代理配置都不接受 cookie
此方案也是可以实现的。 这里没有特别说明。 不应在任何门户代理配置中启用 Cookie。
场景 3 ： 混合配置选项（某些代理配置接受 cookie，而某些则不接受）
此方案可能可实现，也可能无法实现，具体取决于最终客户尝试完成的任务;建议是，如果可能的话，要有一致的cookie政策（方案1/2）。
完成涉及 CSC 的一些混合配置（从 cookie 的角度来看）的方法如下（类似于场景 1）：
- 克隆基于 CSC 的配置
- 剥离基于 CSC 的要求的克隆配置（“设备检查”和“自定义检查”条件）
- 将其放在已克隆的基于 CSC 的策略的正下方
“克隆”配置方法的另一个问题是，剥离 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处理的情况下是有问题的）。