NTLM Single Sign-On in Active-Active cluster

[xc3ss1v30n3]

Good morning. An issue has come up where some users are being prompted for login credentials from the Pulse Secure appliance when working through the WebVPN on a background application or site. In looking at IIS logs as well as activity logs on the appliances, it appears this happens when the user session changes from one appliance to the other by our load balancer. Unfortunately, this doesn't appear to be a global issue from either the user or the application standpoint so it's difficult to truly nail down

Is this expected behavior in the sense of some kind of limitation whether it be from the appliance or NTLM? Is there a way to ensure that user sessions are maintained on the same appliance? Or, some type of configuration that could be done to ensure that credentials are passed from one to the other?

Brief description of our environment: 2 PSA5000s in an active-active cluster being load balanced by F5 DNS. Appliances are currently running 8.3R1.1.

[zanyterp]

Are users changing devices mid-session OR are they logging out and logging in to a different appliance?
For the former, please ensure that source IP sticky is enabled on the F5; the appliances do not maintain session ownership inside the cluster; for the latter, is it something that you can replicate?

[zanyterp]

Apologies: for "some users are being prompted for login credentials from the Pulse Secure appliance" do you mean that they are being prompted to login to the webVPN again OR that they are being prompted to login to the backend service?

What is your NTLM SSO policy?

[xc3ss1v30n3]

I haven't been able to replicate yet as I do not have access to the back-end application. That is supposedly in the works. But, to answer other questions, I do no believe they are logging out of the appliance. From the screenshot I've seen, the login prompt is coming from within the PSA. I.e. They tried to access a back-end system that is permitted through the access portal, however their logged in user account doesn't have access.

Also, I'm not sure what you mean by "ensure that source IP sticky is enabled on the F5."

Thanks for your response!

[mspiers]

"source IP sticky" is the persistence setting on the BIG-IP so connections from the same source IP get sent to the same PCS.
If the BIG-IP is timing out the user session so the client is then reconnecting and gets sent to a random member of the BIG-IP pool then there is a chance they will not be directed to the PCS that has the existing user session unless persistence is used on the BIG-IP.

You can enable the syncing of user sessions in a cluster but this introduces extra overheads, see https://docs.pulsesecure.net/WebHelp/PCS/8.3R1/Home.htm#PCS/PCS_AdminGuide_8.3/Modifying_the_Cluster_Properties.htm , this would allow users to reconnect without having to enter credentials.

Another option is to make sure the session timers on the BIG-IP match what is configured for the PCS so the BIG-IP does not prematurely disconnect a valid session, see
https://docs.pulsesecure.net/WebHelp/PCS/8.3R1/Home.htm#PCS/PCS_AdminGuide_8.3/Specifying_Role_Session_Options.htm for the Role session timers.

[zanyterp]

In addition to what @mspiers said, can you confirm what they are clustering at System>Cluster>Cluster Properties? It is possible for each node to have independent information about user sessions that could negatively impact NTLM (or any other backend auth system).
In addition to all of that, can you confirm what is meant by "F5 DNS," please? DNS load balancing is not supported because there is no state and users may not be on the same node for each request; one side effect could be this (just as if a client launches, the side effect could be that users are asked to login again due to an invalid session).