Hybrid Windows users running WSS Agent and Virtual Smartcard are taking more than 2 minutes to login

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Windows users using WSS Agent to access Cloud SWG services without any issues.

SAML based authentication enabled for WSS Agent users, where SAML IDP server is Azure.

All Windows users are part of a hybrid setup where they login to the local AD as well as Azure framework.

Advanced authentication is enabled on Windows for most users with a physical smartcard, and authentication completes without any problems.

There are a few VIP users using virtual smartcards instead of a physical smartcards to login to Windows, and the login time increases to almost 2 minutes when WSS Agent Version 8.2.2 is installed. The WSS Agent SAML prompt appears after about 2 minutes and SSOs immediately.

As soon as we disable WSS Agent, login times are back to a few seconds.

Environment

Hybrid setup on Windows
Virtual smartcard enabled
No PAC files
SAML authentication enabled with WSSA
MCU=0 for a single tunnel solution
Fail closed enabled

Cause

Virtual smartcard login requires access to domains that cannot be accessed until the WSS Agent tunnel is up. Since this can only happen after the user has logged into Windows, there's a big delay. Fail open would have allowed this to work.

 

Resolution

Make sure that the agent is installed with the AU (Assigned User) parameter as shown below:

msiexec -I C:\downloads\wssa-installer.msi /passive AU=unauthenticated

When WSS Agent hosts are running with SAML authentication, This 'assigned user' unauthenticated will allow tunnels to be established earlier and have consistent reporting of traffic that is sent prior to SAML authentication.

Additional Information

In terms of troubleshooting steps, this one is a little more difficult as the problem occurs at startup and gathering PCAPs are more difficult.

We needed to gather working (WSSA) and non working data (no WSSA), to be able to compare requests that are sent out in both cases.

Symdiag has an option to capture data in restart mode, and this was enabled for WSS Agent case. However, this Symdiag with reboot option gathering data after reboot failed due to security settings on clients that prevent AutoStart.

We managed to get PCAPs manually - two potential options exist:

- hookup Windows host to a switch and capture traffic on switch or
-  use the ETL option with netsh trace start (https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503), and convert with netmon or ETL2PCAPNG - https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/converting-etl-files-to-pcap-files/ba-p/1133297
  

Looking at the PCAPs, we could see a DNS requests generated for all sorts of Azure domains, which never saw a corresponding TCP SYN to establish the connection. These requests were being dropped as the tunnel was not up.

Using fail open worked, as the requests would go out due to no active tunnel.

Installing with the AU option avoided the security concern with fail open.