Users accessing internet via Cloud SWG using WSS Agents.
Office application not working on MacBook but is working on Win11 machine, when both the clients are targeting same Cloud SWG tenant.
Dedicated IP address is enabled for the Azure login endpoint at login.microsoftonline.com.
macOS users report seeing a status 53003 error below, indicating potential issues with conditional access policies.
The IP address reported in the above error page is the users home IP address, and not the dedicated IP address assigned to Cloud SWG.
Cloud SWG access logs do not show any of the requests from the macOS users when the error happens.
Azure logs confirm the successful Windows users logging in have the dedicated IP egress address assigned.
WSS Agent 9.x.
macOS Tahoe/Sequoia.
Application bypass causing requests to go DIRECT and not into the Cloud SWG tunnel.
Make sure that all 'dedicated IP address' configured IP addresses or domains are not bypassed from going into the WSS Agent tunnel.
In the above case, no IP or domain bypass existed but there was an application bypass that kicked in and sent the traffic directly and not via the WSS Agent tunnel.
Another option, to overwrite any IP, domain or application bypass would be to add an 'always intercept' ATM rule for the problematic login.microsoftonline.com domain as shown below which has a higher priority than the bypass rules.
PCAPs confirmed that the requests to login.microsoftonline.com went DIRECT (visible in the capture-net.cap file).
Since no visible bypass rules for the login.microsoftonline.com domain existed, technical support searched the debug WSS Agent logs and found the reason .. The PID generating these requests to the domain was from a PID whose path matched an Application bypass added via ATM. /Applications/Company Portal.app/Contents/PlugIns/Mac SSO Extension.appex/Contents/MacOS/Mac SSO Extension application and this is bypassed from sending traffic into tunnel by default.