Force user credentials at every login Azure AD SAML SSO

[JasonHensley-Tavoca]

I have had GlobalProtect working for years with RADIUS based authentication and MFA.  We are now moving to SAML based SSO with Azure AD.  I have everything working, but, our environment requires that we provide login credentials every time we login to the VPN. So instead of using the credentials of the user that is logged into the machine by default, I want to force the user to enter their credentials, and supply MFA response, EVERY time they login to GP (even though the credentials in the end are the same as the user's Windows credentials)

I've changed all kinds of settings in the Portal - Agent - App settings, but nothing accomplishes what I need.    When we use Azure AD SAML auth programatically, we send the "ForceAuthn=true" attribute, but I've not found anywhere to add custom attributes, or set something like this, in GP settings. 

Anyone have suggestions?

[OtakarKlier]

Hello,

Do you have the configuration set to "No"?

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFbCAK

Setting to yes will try and use the windows creds.

Regards,

[PA_nts · Accepted solution]

As Otakar said.. also in my case this is set to yes.

also a good thing i found is to set 'IPv6 preferred' to 'no' in the app settings on the portal.

re forcing MFA..

I had a similar issue some time back.. in the end, the change (if i recall correctly) needed was on the Azure end.. if i recall the Azure engineers had to set a time limit on the MFA request.. by creating a new azure access policy that will request mfa authentication every 1 hour think the minimum was 1 hour it can be set to for the gp vpn user groups.

the thing with Azure MFA is, if a user is connected and they simply disconnect, then reconnect, the GP app will simply use the Azure's Realtime Refresh Tokens'  (RFT) (look it up.. a good read) to auto validate the MFA.. so the user won't get MFA response again if reconnecting within a certain amount of time. however if they go to the GP app settings, and sign out, then reconnect, then they will be prompted for MFA.

Just to clarify also, there are 2 options, disconnect and sign out (pending on how gp app is setup on palo side). if a user disconnects it preserves the user credentials, whereas if they 'sign out' it will clear the user credentials locally in the cache store. there is no way to force it to clear the credentials when user selects 'disconnect' that i am aware off.

i will try and find out from the Azure team what they did but might also have included some conditional access policies on the Azure end to be created.

unfortunately as I write this it is a Friday afternoon.. so the guys have long gone home and sipping on the good stuff by now. so will try and find out next week for more info and post an update.

have a great weekend!

[JasonHensley-Tavoca]

Thank you.  I've experimented with that setting.  Neither setting accomplishes what I need unfortunately. 

[JasonHensley-Tavoca]

Thank you.  I wondered if it was something I would have to do on the Azure side, but have hit dead ends going that route as well.  The RFT reference may be helpful, so I'll start reading :).

I will also review the sign out vs disconnect.  Right now my GP is set to just offer disconnect, so I'll switch that to sign out and see if that accomplishes what I need.

[JasonHensley-Tavoca]

PA_nts - you got me going in the right direction.  I ended up moving our org from the Azure Security Defaults to managing authentication with Conditional Access policies.  I created a policy that forced authentication every time for my VPN users, and tied it to the Palo Alto GP Enterprise application.  It now works beautifully. Asks for credentials every time, AND uses our company's MFA options. Bonus is that I now have more granular control over authentication policies in my organization. 

Thanks for the help!

[PA_nts]

awesome glad to you hear you got it working.. happy days!

[Anthony-Green]

Hi Jason.

I'm having this exact issue.

We're already using Conditional Access policy tied to the Palo application.

The policy is configured as follows: 

Users: All Users

Target Resources: Palo GP App

Network: Not configured

Conditions: 0 selected

Grant: Grant Access > Require MFA

Session: Sign-in frequency > Periodic reauthentication > 1 Hour

Is this the same as yours?

Did you need specific settings on the Palo side to get it to work?

Because ours is still signing in and connecting automatically when the user logs in to their computer. Logs in Azure say "MFA requirement satisfied by claim in the token"

[JasonHensley-Tavoca]

Hi Anthony,

The only difference I see is that I have Session: Sign-in frequency set to "Every Time". But funny thing is, even with that setting, every once in awhile users still don't have to provide creds or MFA.  But this setting got me working 90% of the time.

Hope this helps!

[Anthony-Green]

Thanks, I'll take a look at those PAGP client settings that Otakar suggested and see if they match ours.

[B.Md611526]

Hi @Anthony-Green 
We are experiencing the same issue. Has this been resolved for you? We have user single sign-on set to "No" and a conditional access policy configured for 8-hour periodic authentication, but it still isn't prompting for re-authentication. If you have found a fix for this issue, please let me know.

[Anthony-Green]

We have it working better than it was, and it is prompting most of the time, though occasionally will not prompt. PAGP is definitely one of the worst VPNs I've used.

The issue could either be on the MS or the Palo side.

Firstly, you will have to make sure that you don't have multiple Conditional Access Policies (CAP) applying to that user. Make sure that all other CAPs exclude the PAGP application from them, and that the PAGP policy includes ONLY the PAGP application and excludes all others. We also changed the sign in frequency to Every Time.

That improved things, but did not resolve them for us.

Secondly, we also had to adjust some settings in the Palo side to disable the Always Connected option. This, unfortunately, brought in another issue where it gives us a "Page Cannot be found" pop-up screen on some occasions when trying to authenticate. Not every time, though, and I haven't been able to reliably replicate it (so don't know the cause)

So, long story short, it is better, but not a smooth experience for users or admins.