Hello @ElTetu,

I don’t believe this is the expected behavior in this case.  I just tested in my lab and I do not receive the Reauth prompt until I move to a Remote configuration.   My dynamic steering config is in the screenshot below:

 

I would validate that the client is seen on on-premises when this happens.  Additionally validate that your on-premises check is not flapping due to the host used in the dynamic steering check is not also used in NPA.

thanks for your response @sshiflett!

I’m glad to know that on a lab it works as my end customer pretends, thank you! but to be honest their setting is a little more complex…

They have decided for the dynamic steering that when user is on-premise specific apps will be steerd to netskope, so I’m not sure if this can affect the behaviour, and to complicate things a little bit more they asked me to configure a Conditional Access on their IdP (Azure AD) so the authentication requires an MFA and it triggers even if the user has a cached session, so I configured for them something like it is explained on this post

Optimizing Identity Provider Settings for NPA Periodic Reauth | Community (netskope.com)

When customer has tried it they assure me that the on-premise detection was working fine, but that it always requested for the reauth, no matter where the user were located. Maybe the “steer specific apps” can affect that?

Also, I’d like to ask you about this thing you said “Additionally validate that your on-premises check is not flapping due to the host used in the dynamic steering check is not also used in NPA.”

The host used for the dynamic steering check is in fact used in NPA. Shouldn’t be this way? Is that a problem?

Thanks a lot for your help!!

@ElTetu,

Yes then the behavior you are seeing is expected.  Periodic reauth will trigger anytime the NPA tunnel is established and the timer expires.  In your case since selected apps are steered even when on-premise then the NPA tunnel is established.  Changing the Reauth to be location based would require an enhancement request but there may be some ways to allow the transparent reauth when on prem by using egress IP to determine if the cookie is honored or not but it would require some further qualification.   

Also, I’d like to ask you about this thing you said “Additionally validate that your on-premises check is not flapping due to the host used in the dynamic steering check is not also used in NPA.”

If the host is steered over NPA and has Publisher DNS enabled then you may find that the on prem check succeeds when NPA enables which causes the client to believe it’s on prem and then changing to the on prem config.  The check will then fail and consider the client remote next time which will cause NPA to come back up which causes the client to flap.  This is documented here:

https://docs.netskope.com/en/netskope-help/netskope-client/netskope-client-configuration/

Thanks again @sshiflett for your help and detailed response!

As for the moment it seems that all the steering configs from my customer would need to steer at least some private apps even on-prem I will try to investigate how to get this transparent reauth by using egress IP as you mentioned

Hi,

A similar scenario is what we’re seeing with a prospect at the moment and the way they have solved it for the only auth when not in the office is to create a private application that steers login to their IdP in this case Entra (MS) when the user is not on premise using a DNs resolution for on premise detection.

Entra then has conditional access rules configured to do AUTH or not depending on the IP address that the auth request is coming from.

One strange thing we’re seeing here though is that using perodic re-auth once the auth period elapses then even though SSO re-auth is required the client routes the traffic not via the private app config and therefore SSO re-auth doesn’t happen