Problem with SAML Authentication not triggering with WSS Agent 9.7.1
search cancel

Problem with SAML Authentication not triggering with WSS Agent 9.7.1

book

Article ID: 381285

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet services via Cloud SWG using WSS Agent.
SAML authentication enabled with Microsoft Entra SAML IDP server.
With the WSS Agent 9.7.1 upgrade, some users were getting blocked accessing resources they were entitled to access per the Cloud SWG policy.
The Cloud SWG admin noticed that AD group sync is not working (latest groups for the user were not logged in Cloud SWG access logs) and can take up to 24h to sync with user.
When assigning any user a new AD group, it does not seem to reflect that group change in the Cloud SWG logs.
When we force reconnect from WSS Agent or from Cloud Portal it does not fix the issue, and it does not look like we get any new assertion from Entra IDP server.
There were no Entra changes; the only change is the version of WSS Agent. 
 

 

Environment

Microsoft Entra.

AD Connect to synchronise internal AD with Entra.

SAML Authentication.

WSS Agent.

Cause

The one major change with 9.7.1 on Windows is support for a single login a day, even when switching networks(see 'session restore' docs). When a user logs in for the first time, it sets a token for that user ... if that user changes network and RECONNECTs, the token is sent to Cloud SWG and assuming it is still valid, the user will NOT be prompted to authenticate via a popup. Without any re-authentication, no updated SAML assertion can be received which would include new groups.

In the past, the popup would appear several times a day as the user switched networks which was frustrating users.

Resolution

There are a few options:

  1. Can reboot the machine and the current session will be removed
  2. Can use wssad.exe option samlSessionRestore to disable SAML Session Restore (can also be pushed out via GPO), with the following syntax:

    Windows OS - run from Administrator command prompt

    "C:\Program Files\Symantec\WSS Agent\wssad.exe" -p samlSessionRestore=false

    After completing the test, make sure that you remove the option so that the session restore feature works again (unless Cloud SWG admin wants it off persistently). To remove the option, simply run:

    "C:\Program Files\Symantec\WSS Agent\wssad.exe" -e samlSessionRestore

    macOS (Big Sur and later) - using sudo to run as root

    sudo "/Applications/Symantec WSS Agent.app/Contents/MacOS/wssad" -p samlSessionRestore=false

    And to remove the change and re-enable SAML Session Restore:

    sudo "/Applications/Symantec WSS Agent.app/Contents/MacOS/wssad" -e samlSessionRestore


    Any RECONNECT after this change will force traffic to the SAML IDP server, to get a new assertion with updated groups.

Additional Information

With WSS Agent 9.6.1 and all working well, the following authentication request/response were visible in Symdiag PCAPs when hitting RECONNECT: 
 
GET /api/v1/check_auth HTTP/1.1
Host: pod.threatpulse.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Edg/129.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9,en-US;q=0.8
 
 
HTTP/1.1 307 Temporary Redirect
Cache-Control: no-cache
Location: https://saml.threatpulse.net:8443/?cfru=aHR0cDovL3BvZC50aHJlYXRwdWxzZS5jb20vYXBpL3YxL2NoZWNrX2F1dGg=
X-XSS-Protection: 1
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: 9557
Pragma: no-cache
 
This would end up with a corresponding request into Entra SAML IDP server.
 
With the WSS Agent 9.7.1, we see the same GET request but get a 204 "no content" response with no corresponding redirect to SAML to get an updated assertion.