Troubleshooting Authentication in Web Isolation
To debug, first, it should be verified that the correct authentication is being implemented.
The authentication mode you select depends primarily on your topology. Use the use cases listed in the table below as a guide to assist you with selecting the appropriate authentication mode.
Note
Internal identity authentication and Active Directory authentication can be used in Proxy mode as well as in Server mode; however, SAML must be used in Server mode.
Use Case | Authentication Mode |
Symantec Threat Isolation explicit proxy | Proxy |
A downstream proxy between the endpoint browser and the Threat Isolation Gateway authenticates the endpoints using the HTTP response: 407 Proxy Authentication Required. In this case, the Gateway must be configured with Server authentication mode. Otherwise, the Gateway can be configured with Proxy authentication mode. | Server |
Your company uses Web Application Isolation Gateways. NOTE: Web Application Isolation Gateways use Server authentication regardless of the mode with which they are configured. | Server |
SAML Authentication | Server |
Note
It is recommended to use Symantec Secure Web Gateway (ProxySG) as your downstream proxy. As products from the same vendor, Symantec Threat Isolation and Symantec ProxySG can be integrated smoothly. This convenience is not available when using any other product.
If your organization’s endpoints communicate indirectly with the Threat Isolation Proxy through a downstream proxy, the proxy forwarding policy in your downstream proxy must support rule-based definition.
In this topology, endpoint communication with the Threat Isolation Proxy and the TIE is carried by the downstream proxy responsible for the forwarding.
The downstream proxy forwards traffic to one or more selected Threat Isolation Gateway clusters using proxy chaining.
As shown in the figure above, the Symantec Threat Isolation Platform distinguishes between two types of third-party proxies, according to their location in relation to the Gateway: the downstream proxy resides between the endpoint and the Threat Isolation Proxy, while the next hop proxy/server resides between the Gateway and the Internet.
For simplicity, the figure contains just one next hop proxy/server. Real-life topologies can contain multiple next hop proxies/servers, with the Threat Isolation Proxy and the Threat Isolation Engine (TIE) pointing to different next hop proxy/server machines.
Note that a downstream proxy can act as both downstream proxy and next hop proxy/server on the same machine, as illustrated in the figure below. In this case, the policy will be run twice: once before the request is forwarded to the Symantec Threat Isolation Platform, and again before it is forwarded to the Internet.
Since the downstream proxy resides between the endpoints and the Threat Isolation Gateway, it must preserve the original data of the source IP and the authenticated user. This data is contained in the following standard request headers:
Proxy Authentication Mode
In Proxy authentication mode, the Gateway issues a Proxy challenge (HTTP 407) for every new connection.
Note
When a downstream proxy between the browser and the Gateway authenticates the endpoints using the HTTP response: 407 Proxy Authentication Required, the Server authentication mode must be used. For more information, see the section "Server Authentication Mode" below.
The following flow chart illustrates the initial browsing flow in Proxy authentication mode. Each leg is explained below.
From the above figure, see further explanation of each leg above. Understanding these will help debug the authentication challenge.
Note: Authentication is required only when the matched rule demands it. For more information, see section "Match Criteria Flow".
Match Criteria Flow
The match criteria of a security rule are evaluated in the following order: Source (first), Destination (second), Request Headers (third), User (fourth).
Skipping Authentication when Egress IP Has Been Authenticated
Some applications do not support Proxy authentication. To avoid connectivity issues in such cases, Symantec Threat Isolation allows authentication to be skipped when the source egress IP address (the source IP address that the traffic comes from) has already been authenticated within the configured authentication caching timeout. The policy can be edited to include criteria for skipping authentication.
When these criteria are matched and the source egress IP address was authenticated previously, the user is considered trusted and authentication will be skipped. The activity log displays “Generic User” instead of the user name when user authentication was skipped for unauthenticated requests. In that case, rules with a specific Access Role were skipped during matching.
Server Authentication Mode
In Server authentication mode, the Threat Isolation Gateway issues an Authentication challenge (HTTP 401) for every new connection.
The following flow chart illustrates the initial browsing flow in Server authentication mode. Each leg is explained below.
Skipping Authentication when Egress IP Has Been Authenticated
When a proxy resides in the cloud, it cannot communicate directly with an authentication server that resides in the LAN. If redirect cannot be done in this case, authentication is likely to fail, resulting in connectivity issues for Bypass and
Inspect actions. (This is not relevant for isolated web traffic.) Connectivity issues can also be experienced by websites that apply Content-Security-Policy[1] such as Facebook.com.
To address the connectivity issues, Symantec Threat Isolation allows authentication to be skipped when the source egress IP address (the source IP address that the traffic comes from) has already been authenticated within the configured authentication caching timeout. The policy can be edited to include criteria for skipping authentication. When these criteria are matched and the source egress IP address was authenticated previously, the user is considered trusted and authentication will be skipped. The activity log displays “Generic User” instead of the user name when user authentication was skipped for unauthenticated requests. In that case, rules with a specific Access Role were skipped during matching.
For more information, follow this Symantec support link, and refer to the Server Authentication Mode section:
https://knowledge.broadcom.com/external/article?legacyId=tech252383
Next, with the debugging process, the "Activity Logs" will have to be checked.
Symantec Threat Isolation Platform authenticates a user's identity using an external Identity Provider. To help you troubleshoot issues involving traffic to the identity provider, the Authentication steps above can be reported in the Activity Logs.
1. Go to:
Policies > Update Policy > Authentication Settings > Server Mode > Settings.
2. Under Logging Settings, click More.
3. Select the authentication steps that you want logged.
4. Click Update.
You may share the the Activity Logs on this case, if required.
Also, with the authentication profile set and the correct authentication mode implemented, if the customer is working with a software requiring authentication based on Windows, the following should be set, on the browser.
An additional debug log would be the HAR file, for the affected web request. Any authentication failure would also show up there.