GlobalProtect Authentication Override Cookies and CSC
9945
Created On 04/12/22 15:39 PM - Last Modified 05/13/24 21:52 PM
Symptom
Authentication Override cookies may not work when used in combination with Config Selection Criteria (CSC) based on "Device Checks" and "Custom Checks".
Environment
- Palo Alto Firewalls
- GlobalProtect with Authentication Override cookies configured
- Portal configuration using Config Selection Criteria (CSC) based on "Device Checks" and "Custom Checks" (not related to user/user group config selection criteria)
Cause
- Config Selection Criteria (CSC) based on “Device Checks” and “Custom Checks” relies on gathering additional information from the GP client (via getconfig_csc.esp) after the client has been authenticated in order to match proper Portal Agent Configuration.
- On the other hand, authentication override cookie handling settings (Generate/Accept) are specified within Portal Agent Configurations.
- As the configuration is properly determined only after the client authentications and getconfig_csc exchange, we can’t be certain whether cookies are accepted until it is too late (chicken & egg type of problem).
- This is the reason why commit warning message has been added stating:
Authentication Override and Config Selection Criteria -> Device Checks/Custom Checks are both configured. Authentication override will be disabled
- Though we aren't disabling cookies but the configuration may or may not work as intended depending on the rest of the setup.
Non-working example:
- CSC based configuration (on top) is accepting cookies, while match-all config below (not CSC based) doesn’t accept cookies
- During authentication process, Portal (server side) needs to evaluate whether cookies are allowed, but it is impossible to determine whether CSC based config will be matched until "getconfig_csc.esp" exchange which comes after authentication
- At this point, server side will find a potential config match (the one without CSC criteria) and use its cookie related settings (in this particular example - not accepting cookies) and user will be forced to authenticate, even though it will eventually match CSC based config (after "getconfig_csc.esp" exchange) which does allow cookies
The Portal connection process goes as follows:
- Authentication (differentiation possible based on the OS) based on Authentication Profile and/or Certificate Profile.
- Cookies might be allowed/accepted if there is a potential Portal Agent Configuration match not requiring CSC checks which is also accepting cookies; This would allow for the cookie to be accepted, prior to "getconfig_csc" proper configuration selection.
- Note: regardless of the potential config match (prior to CSC exchange) and cookies used or not, we are always matching the right Agent Configuration in the end! User will always receive its intended config, the “pre-matched” config is only used on the server side to decide on how to handle cookies during auth process.
- After the authentication (with or without cookies), "getconfig_csc" provides additional details needed to properly match exact Portal Agent Configuration.
Resolution
Depending on the client configurations listed under "GlobalProtect Portal Configuration > Agent" we may or may not have a successful Authentication Override with Config Selection Criteria (CSC) based on “Device Checks” and “Custom Checks” configured.
Scenario 1 : All Portal Agent Configurations are accepting cookies
This scenario is achievable. We need to make sure that there is a non-CSC based Portal Agent Configuration that is accepting cookies and that can be “pre-matched” prior to CSC evaluation. We can either clone individual CSC-based configs, strip the CSC selection part, and put the clone right beneath the CSC-based config (which wouldn’t be as elegant if there are many configs) OR we can have a “catch-all” non-CSC based agent configuration at the end of the list, which would hold the proper cookie accept settings; This particular config should be restricted in terms of features (and/or gateways assigned), but the point is that it shouldn’t be hit at all for the “final” config match (after CSC evaluation), but rather only be leveraged for cookie handling. Customers may already have non-CSC based configs with potential matches which are allowing cookie functionality without adding this policy at the bottom.
Scenario 2 : All Portal Agent Configurations are NOT accepting cookies
This scenario is achievable as well. No special instructions here. Cookies shouldn’t be enabled in any portal agent configuration.
Scenario 3 : Mixed Configuration Options (some Agent configs are accepting cookies, while some aren't)
This scenario may or may not be achievable depending on what the end customer is trying to accomplish; The suggestion would be to have consistent cookie policies (Scenario 1/2) if possible.
The way to accomplish some of the mixed configuration (from cookie perspective) with CSC involved would be by (similar to scenario 1):
- Cloning CSC-based configurations
- Stripping the cloned configuration of CSC based requirements (“Device Checks” and “Custom Checks” conditions)
- Placing it just below the CSC-based policy that has been cloned
Another problem with the “cloned” configuration approach is that multiple CSC-based configuration clones may look the same after CSC part is stripped;
Example:
- CSC_A config and CSC_B config have their respective non-CSC based clones created with the following order: CSC_A, Non_CSC_A_Clone, CSC_B, Non_CSC_B_Clone.
- If “Clone” configs are the same, Non_CSC_B_Clone would never match, meaning that Non_CSC_A_Clone settings would always be used (which is problematic in case CSC_A and CSC_B need to have different cookie handling).