Auth Connector installed and used to retrieve group information for authenticated users
AuthConnector cannot successfully connect to our tenant - WSS Portal reports state of Auth Connector connections to be down
Auth connector debug logs show that connection to auth.threatpulse.com IP address fails.
PCAPs from Auth Connector shows WSS Cloud is sending back a TLS Reset after AuthConnector sent a "Client Hello".
List of supported Auth Connector ciphers defined at https://knowledge.broadcom.com/external/article/175072/auth-connector-fails-to-connect-to-autht.html are actually included in non working client_hello message.
Auth Connector running on Windows 19 Server platform
Auth Connector traffic was going through Zscaler network and blocked.
Bypassed Auth Connector traffic destined for WSS authentication servers and pods (as per WSS IP address KB) from going through Zscaler cloud service.
Turned out that Windows 2019 Server was configured to proxy requests via the zscaler.net cloud. The Zscaler service was not sending the requests upstream into WSS auth services, and hence the TCP RST after the client_hello TLS message.
Given that client_hello message from Auth Connector initially failed to trigger a server_hello response, we tried to change list of available Windows ciphers without success
Running the OpenSSL command from Windows 2019 server with one of supported back end ciphers would fail but running the same command from another device in DMZ would work fine e.g.
$ openssl s_client -connect 35.245.151.226:443 -no_tls1_3 -cipher 'ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-CBC-SHA384' 2>/dev/null | grep New
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Working openssl command was from a host that was not sending traffic into Zscaler cloud service.
To determine whether a host is going through the Zscaler service, have them access https://ip.zscaler.com/ and confirm whether you get message that 'you are accessing the internet via Zscaler cloud' message.