Troubleshooting cloud service authentication problems when using Netskope

on


This article will show you how to troubleshoot cloud service authentication problems when using Netskope.

Main Cause

The premise is that while using Netskope, communications generated by the client are terminated at Netskope's data center, and HTTPS communications are decrypted there. The HTTPS communication is then decrypted at the Netskope data center, and re-encrypted at the Netskope data center using the certificate provided by Netskope, and a new communication is generated to the application.

In this process, the original certificate used for authentication is no longer included in the new communication, which is the main reason why authentication does not succeed. (However, the details of this situation vary depending on the characteristics of each cloud service.)

General Troubleshooting Overview

  1. Identify if Netskope is the cause of the event
  2. Identify the FQDN causing the event from Netskope logs.
  3. Do one of the following for that FQDN
    1. Configure the SSL Decryption Policy to prevent SSL decryption.
    2. Set an Exception on the communication from Netskope.

Detail

1. Identify if Netskope is the cause of the event

First, determine if Netskope is the cause; if the cloud service authenticates successfully with the Netskope Client turned off, then Netskope is most likely the cause.

2. Identify the FQDN causing the event from Netskope logs.

Reproduce the event and record the time of reproduction

With Netskope turned on, reproduce the event where the cloud service cannot be authenticated. Then record the exact time of the reproduced event. For ease of viewing the log, it is recommended to close all applications and websites except for the event you wish to verify.

Obtaining logs from Netskope Client

Click on the Netskope icon, select [Save Logs] and specify where you would like to save the logs.

Identifying Suspicious FQDNs

In the Zip file, there is a log file called [nsdebuglog.log]. This log is simply a log that records "communications from Netskope Client (terminal) to where". There are two patterns in this log: "communication directly to the Internet" and "communication to Netskope".

Communications leading directly to the Internet
As shown in the log sample below, the log entry "bypassAppMgr.cpp:996" indicates communication directly to the Internet. This log is not suspicious in this case of authentication failure.
 2021/12/07 12:21:40.207711 stAgentSvc p8c t3e0f 4 bypassAppMgr.cpp:996 BypassAppMgr bypassing flow to exception host: x.google.com, process: google chrome helper, Dest IP: X.X.X.X, Dest Port: 443
Communication heading to Netskope
The following log sample, which shows "tunnel.cpp:695", is the communication going to Netskope. To identify the suspect FQDN, check the value following host: in this log.
2021/12/07 12:21:41.870744 stAgentSvc p8c t3e0f 4 tunnel.cpp:695 nsTunnel TLS [sessId 501] Tunneling flow from addr: X.X.X.X:X, process: google chrome helper to host: blog.sample.com, addr: X.X.X.X to nsProxy
In the log sample above, "blog.sample.com" is the FQDN suspected to be the cause of the authentication failure issue.

3. Do one of the following for that FQDN

Once the causative FQDN is identified, there are two ways to deal with it: "SSL Decryption Policy Settings" OR "Exception Settings (Exception)". 
The "SSL Decryption Policy setting" allows the registered FQDN to go through Netskope's data center, but without terminating the communication or decrypting the HTTP communication to access the application. The downside is that less information is output to the Netskope Management Console than in the normal case, but because it goes through Netskope's data center, more information can be obtained than in the "Exception" setting introduced next. 
On the other hand, when "Exception" is used, the terminal communicates directly with the registered FQDN without going through Netskope's data center. In this case, the information cannot be retrieved by the Netskope Management Console. 

Whenever possible, it is preferable to use "Configure SSL Decryption Policy" to deal with this issue, but only if the authentication does not succeed even with "Configure SSL Decryption Policy", it would be good if you could also try Configure Exception.

3-1. Configure the SSL Decryption Policy to prevent SSL decryption.

1. In the Netskope Management Console, navigate to [Policies] > [SSL Decryption] and click ADD Policy.

2. Configure as follows and Save.
  • Match Criteria: *Enter the identified FQDN
  • Action: Select Do Not Decrypt
  • Set Policy: Any policy name
  • Status: Enabled
3. Click APPLY CHANGES

3-2. Set an Exception on the communication from Netskope.

1. Log in to the Netskope administration page and navigate to [Settings] > [Security Cloud Platform] > [Steering Configuration] > [Default tenant config] > [EXCEPTIONS].
2. Click [NEW EXCEPTIONS], enter the appropriate FQDN and click [Add].

In this setting, wildcards can be specified, such as *.example.com. However, as mentioned earlier, if you bypass a wide range, the meaning of including Netskope will diminish, so be sure to specify and enter the minimum required FQDN.

Point to make note of

As a matter of course, setting an SSL Decryption Policy or setting an Exception from Netskope means that some monitoring and control of cloud services using Netskope's functionality will no longer be possible. (However, monitoring and control via other axes, such as API Introspection, will continue to be possible.)
It is functionally possible to specify a wide range of FQDNs using wildcards, etc., but please make sure to purchase and configure the minimum FQDN information required for Netskope authentication for this setting.

Comments

Post a Comment