GlobalProtect client fails to connect to Gateway when set to SAML authentication

[Adrian_Jensen]

I have spent the last 2 days bashing my head on his without success... We are changing an existing GP VPN from internal Radius authentication (plus other methods) to an external Azure SAML authentication. I have setup a SAML Server Profile and an Authentication Profile, set the GP Gateway to user SAML authentication, but the GP client always hangs at "Still Working..." after authenticating, it never successfully connects.

The PA GlobalProtect logs show a gateway-prelogin, but no further events. The PA System logs show a client redirect to the SAML authority and successful assertion back. The Azure SSO shows successful login event. But the GP client never completes the connection.

Using the built-in GP client browser (apparently IE), the first time I tried I got a user/pass login prompt, I have never subsequently received that. Setting the client configs to use the default system browser I get a browser SSO login page, authenticate, and PaloAlto successful login page with popup to launch GlobalProtect, but the client never connects. If I use SAML authentication on the Portal and anything else on the Gateway (i.e. cert/Radius/etc.) the SAML login to the Gateway works fine and the Portal login also works (on the alternate method). SAML just never completes on the Gateway.

I suspect this has something to do with website blocking when not connected to the VPN (always-on mode, block all traffic when not connected), but I have already added all relevant FQDNs to the bypass list, or something to do with the Attributes&Claims returned by Azure SSO. But so far I have not been able to find/change anything that makes a difference.

[Adrian_Jensen]

Just to wrap this thread up, after a bit PA support got back to me and suggested disabling Dynamic Passwords for the Gateway under:

Global Protect -> Portals -> [portal config] -> Agent -> [agent config] -> Authentication

Something about having Dynamic Passwords enabled prevents the GP client from completing the Gateway connection when using SAML authentication. The SAML connection itself completes normally, but the client never completes its registration after authentication. Unfortunately, this also means that the GP client will cache and reuse the SAML token for every subsequent reconnection (default Azure token lifetime is 90 days). So if you are expecting to have a user/pass authentication every time a user attempts to connect, that will not happen. We are exploring if Azure can be changed to force a new MFA on reuse of existing SAML token.

[ryan.derrick]

Don't suppose you got anywhere with forcing the token to generate a new MFA request did you? I'm facing the exact same issue. The portal login forces me to use credentials and MFA every time but global protect client has only ever asked me once and now just reconnects without asking for creds or MFA. Massively defeats the point in me trying to use this method to leverage azure MFA. Only thing I can think is that it needs some sort of conditional access but we don't have licence on Azure for that so hoping some way around it

[ryan.derrick]

Hi all, had a breakthrough with this last night. In the auth profile>authentication if you tick enable single logout it then properly logs out the azure connection when you disconnect. It then prompts for credentials and MFA again on reconnection without the need for any conditional access setup.

[Adrian_Jensen]

Interesting... the notes say "Select this option to enable users to log out of every authenticated service by logging out of any single service." Does that mean it removes all SAML tokens on the SAML server side, or just the SAML token related to your GP login? I am setting up to test and see. If it just removes the GP login related token (and anything else you used the token for on the PA, I can't really think of what else this could be off hand, other than maybe admin auth) then that would be great. If it also signals to the SAML server to invalidate all other tokens and it kills your Outlook/third party vendors/etc. tokens, then that would be a big problem. (I suspect the later is not the case as that would open a big window for abuse). 

[KarenJones1]

Could this "enable single logout" solve my problem? We are also using SAML with Azure. Our GP logs in using the credentials of the logged in user. Drives me scatty when working on a new device that is not yet domain joined; or when logged in with an admin account.

[Adrian_Jensen]

I have been testing for a couple hours and does not seem to work as advertised, at least in an Always-On User-Login GP setup. With the "Enable Single Logout" if I switch from one Portal to a different Portal (with a completely different configuration) and then switch back, I get prompted to re-authenticate for my SAML token, but it does not require MFA again. Revoke all my tokens in Azure and reconnect, it requires me to MFA the initial connection. But subsequent reconnects it just asks for user/password, no MFA.

However, when logging out of the PC, or performing a reboot/power off and reconnecting, it doesn't even prompt for user/pass, it automatically connects without any user action. It appears that this is only functioning in the case where a Portal change of config as occurred (i.e. going from one Portal to a different Portal with a significant client config change). I can see the Gateway logout events in the PA logs when the user logout/PC shutdown events happen, but that doesn't seem to cause the GP client to actually discard the existing token.

[ryan.derrick]

Morning all, the difference for me is that i am using on demand for the method. We used to use always on but couldn't see a benefit in leaving it that way when I want this auth part working. if i disconnect it auths again with mfa. 

[Adrian_Jensen]

Yeah, in our case we use Always-On mode as all our WFH/laptops access is required to be filtered through the PA, no direct internet/home network access. I suspect this "Enable Single Logout" option only works when the end user explicitly chooses to log out, which would only really apply to an On-Demand VPN. The real solution to the Azure SAML re-MFA would still seem to be applying policies on the Azure side...

[N.Watson]

This fixed my issue. Thanks a bunch for posting the follow-up.