Office Apps failing conditional access policy check after after wake up from sleep

Products

• WSS add-on - Full Isolation

Issue/Introduction

WSS Agent directing all Web traffic to Symantec Cloud SWG service.

Dedicated egress IP address feature enabled for traffic going to login.microsoftonline.com, that is used in Entra Conditional Access Policy (CAP) to prove that the logon is coming from the organisation managed MacOS hosts.

When the host comes up and any Office application is accessed e.g. Outlook, the authentication succeeds and user can access their mailbox.

When the macOS device goes to sleep and wakes up, Office applications appears to restart before the proxy agent and traffic comes from the user’s local IP, and is blocked by Conditional Access Policy.

This is CAP working as expected. What is not working as expected is that the WSS Agent should block all traffic until it is active. It does on boot, but not on wake from sleep.

Environment

macOS.

WSS Agent.

Dedicated IP address.

Entra conditional access policies.

Cause

Multiple applications generating requests to login.microsoftonline.com, with some of these applications bypassed from WSS Agent.

Resolution

Remove the application bypass for the process generating requests into login.microsoftonline after the host wakes up from sleep.

Additional Information

Knowing the Entra CAP policies were failing gave a clue that some requests were probably being bypassed from going into the WSS Agent tunnel.

Analysing the PCAP from the Symdiag output, we confirmed that requests were going into the tunnel on occasions, and direct on other occasions - even for the same destination IP address.

Looking at the routing logs, we could see two separate applications generating requests into login.microsoftonline.com IP addresses - one going into the tunnel and hence via dedicated IPs and one going direct. Outlook process always went into the WSS Agent tunnel, but an ExampleCorporateApp was bypassed.

2025-11-25 13:56:44 TCP Flow 45123735616 (x.x.x.71:443) from /Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook received
2025-11-25 13:56:44 TCP Flow 45123735616 (x.x.x.71:443) sent via tunnel (R13)
2025-11-25 13:56:45 TCP Flow 45123739200 (x.x.x.3:443) from /Applications/ExampleCompanyApp.app/Contents/MacOS/Mac SSO Extension received
2025-11-25 13:56:45 TCP Flow 45123739200 (x.x.x.3:443) sent direct (R5)
2025-11-25 13:57:11 TCP Flow 45123734592 (x.x.x.2:443) from /Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook received
2025-11-25 13:57:11 TCP Flow 45123734592 (x.x.x.2:443) sent via tunnel (R13)
2025-11-25 13:57:12 TCP Flow 45123739392 (x.x.x.2:443) from /Applications/ExampleCompanyApp.app/Contents/MacOS/Mac SSO Extension received
2025-11-25 13:57:12 TCP Flow 45123739392 (x.x.x.2:443) sent direct (R5)
2025-11-25 13:57:12 TCP Flow 45123732864 (x.x.x.23:443) from /Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook received
2025-11-25 13:57:12 TCP Flow 45123732864 (x.x.x.23:443) sent via tunnel (R13)
2025-11-25 13:57:13 TCP Flow 45123733952 (x.x.x.23:443) from /Applications/ExampleCompanyApp.app/Contents/MacOS/Mac SSO Extension received
2025-11-25 13:57:13 TCP Flow 45123733952 (x.x.x.23:443) sent direct (R5)

Looking at the Application bypass list in the ATM configuration showed that a /Applications/ExampleCompanyApp.app/** entry existed. Removing this fixed the issue.