Reconnecting WSSA with ZTNA disabled shows ZTNA status as "Enabled" after successful reconnect
search cancel

Reconnecting WSSA with ZTNA disabled shows ZTNA status as "Enabled" after successful reconnect

book

Article ID: 381624

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

If you have ZTNA in a disabled state prior to a manual reconnect of the WSSA. After a successful reconnect of the WSSA the ZTNA status shows in the WSSA UI as "Enabled"

Environment

Cloud SWG

WSSA 9.7.1

SAML Authentication enabled

ZTNA integrated

Cause

This is working as designed

Resolution

If you have ZTNA and ATM enabled in your Cloud SWG tenant with ZTNA rules for specific user or groups.  When a WSSA reconnect happens, you get the default ZTNA rule of "do not intercept" which turns off ZTNA completely. After a successful login to SAML, you get a new ZTNA rule of "Intercept". ZTNA rules should only allow intercept with a SAML user or group is set, it is required that ZTNA "Intercept" verdicts always have a SAML user (or group) associated with it.  The net effect means reconnecting the WSSA will reenable ZTNA since the connection will pass through the "unauthenticated" state (which will never have ZTNA configured)

 

 

Additional Information

NOTE: The enable/disable state of ZTNA is perserved across reconnects as long as the configuration of ZTNA does not change.