User is not able to login with WSS Agent on macOS devices that are locked down by organisation.

Products

• Symantec ZTNA

Issue/Introduction

ZTNA enabled with segment based applications.

Cloud SWG WSS Agent hosts used to send traffic into both the Cloud SWG and ZTNA services.

SAML authentication enabled where users see the IdP server login page inside a macOS Webkit popup when agent initialises.

No issues reported during the pilot phase, but when the organisational rollout took place, a few users on mcOS claimed they could not see the login page.

Using the dpOverride command to set samlSystemBrowser=true, to enforce the SAML login on the browser, also failed so the issue was unrelated to the Webkit macOS popup.

Error reported by the macOS users was that the 'site could not be reached' as shown below, but the site was not the SAML IdP server:

 

Environment

Cloud SWG.

ZTNA Segment applications.

macOS 15.7.2.

Cause

macOS default browser settings enforcing HTTPS and redirecting any HTTP traffic to HTTPS.

All traffic into Cloud SWG pod.threatpulse.com endpoints are expected to be over HTTP.

Resolution

Disable "HTTPS-first" mode in the default browser, or add an exception for the pod.threatpulse.com domain.

 

Within the organisation, the onset of this behavior appeared to be linked to changes rolled out in Chrome build 141 which hard-coded HTTPS-First to "on" for Incognito and Guest sessions. 

 

In the organisations Google Apps admin console, there was an HttpAllowList user/cloud policy that whitelists http://pod.threatpulse.com/. This policy was pushed to the browser once a user signs into to the Chrome app with their organisations Google Apps account and allowed the organisation to manage their work profile.

 

NOTE: Merely accessing Google Apps via Chrome does not automatically sign users into Chrome, hence the HttpAllowList user policy would not get deployed to Chrome for all users ... all users must signin to Chrome with corporate account to address the issue.

Additional Information

The Symdiag PCAPs showed that certain requests destined for pod.threatpulse.com were sent over HTTPS, which should not happen by default.

Enabling the HAR file at the time of the issue showed a CONNECTION_CLOSED error instead of the expected 307 redirect status, indicating the back end had closed the connection - which confirmed what we saw in the PCAPs. Again these requests were using the HTTPS scheme.