Windows clients not able to use Microsoft web sign-in when WSS Agent active
Article ID: 411294
Updated On:
Products
Issue/Introduction
Users accessing internet sites via Cloud SWG using WSS agents, where users login to the local AD domain controllers.
As part of a new ZTNA deployment, with WSS Agents running on windows 11 laptops that managed by microsoft intune, the Cloud SWG admin wants to enable the Web sign in option using the following instructions.
After bypassing predefined and other microsoft certificate pinning urls, it seams like the web sign-in option is blocked by the agent for signed-in users.
After a user clicks on the Web sign-in option after a reboot, there is a long delay (up to 60 seconds) before the following page is rendered on the screen:
The user reports the error "We can't open that page right now. For security reasons, you'll need to visit the page from a browser or a different device. If you think you've reached this page because of an error, tell your organization's IT support you can't access https://login.microsoftonline.com/webapp/windowslogon/1"
When the agent is disabled - the functionality of web sign-in is working fine.
Environment
Web sign in for Windows.
WSS Agent.
Cloud SWG.
SAML Authentication.
Cause
Requests for Entra Web sign-in endpoints blocked by WSS Agent by default.
Resolution
Make sure that we enable 'always intercept' in the WSS Agent ATM configuration for the following domains, bypass authentication and have an ALLOW rule so that the client initiated requests can get to the back end to complete the Web sign-in. By default, only traffic to pod.threatpulse.com and saml.threatpulse.net is allowed into the tunnel (needed for SAML authentication) before authentication succeeds otherwise all requests are blocked by the WSS Agent from being sent into Cloud SWG.
- ecs.office.com
- endpoints.office.com
- inference.location.live.net
- odc.officeapps.live.com
An alternative solution is to bypass these domains from going into Cloud SWG via the ATM domain bypass configuration. This is not a recommended solution as Cloud SWG has no way of intercepting or securing requests to these domains.
Additional Information
When gathering WSS Agent troubleshooting information during a reboot, the Symdiag does not capture PCAPs. This means that the above domains are not easily traceable.
Broadcom support can take the Symdiag output and rehydrate to gather the information via another route, which helped address the issue here.
One option could also have been to do the web sign-in without any WSS Agent and trace the requests generated that way before tweaking the WSS Agent setup. This would typically require port mirroring for the Windows host.
Feedback
