Cached credential issue when using SAML with Global Protect Client and MS Azure

[ddockter]

We are using SAML with Global Protect Client and MS Azure and it works well for us, with one caveat.  We have a consultant who uses the Global Protect client to establish a VPN connection to their network.  When I have them attempt to use the Global Protect client to establish a VPN connection into our network (using an O365 account on our tenant), it is using the O365 account for his company (no prompt for credentials).  How do I get Global Protect to prompt for a different set of O365 credentials?  It seems the credentials are being cached somehow.  I've had them clear their browser cookies, but that didn't help.

[dwlord]

Came here with the same/similar problem.  Using default browser authentication.  User johndoe@xyz.com  tries to login with credentials for our environment jdoe@contoso.com.  We have seen it prompt for credentials and authenticate properly for jdoe@contoso.com but the browser wants to pass through johndoe@xyz.com so it fails.  This seems to only affect contractors that are on a different domain.  Would love to be able to have globalprotect launch a "private" version of the default browser to limit this for certain users.

[ddockter]

Exactly my issue as you described.  I'm really hoping someone has come up with a fix.  I did find the below but have not had a chance to test it yet to see if it will resolve this issue.

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

[dwlord]

The contractor I was just working with was tech savvy enough to be able to switch default over to Chrome from Edge and that worked but I expect there will be other contractors that won't be able to do that.

One troubleshooting idea I had was to have them login to portal.office.com first with the alternate domain credentials first to see if the browser then did a better job of being choosier on which one it passed over.  I am going to try to create a lab environment for this issue to see if that helps.

I saw that KB but it didn't look like it would help but maybe I am wrong.

[dwlord]

Okay, so I got a lab up and was able to reproduce it as if I were a contractor. The error message I get when logged in as user johndoe@xyz.com to local computer of domain xyz.com and trying to VPN as jdoe@contoso.com is:

Sorry, but we're having trouble signing you in.

AADSTS50105: The signed in user 'johndoe@xyz.com' is not assigned to a role for the application...

By logging into office.com with user jdoe@contoso.com, it passed through that credential and worked. Not ideal, but directing a user to login to office.com before connecting vpn isn't the worst workaround I have ever recommended...

[ddockter]

We made the firewall change in this link and now get the O365 logon prompted on each connection attempt which is what we wanted.

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

[dwlord]

Glad it is working better for you!  Unfortunately, it doesn't seem to be helping us after I made the change here.  If the contractor is actively logged into office.com as domain xyz.com it will not prompt for alternate contoso.com user.

[HenryA]

We have the same issue. Any solution to that?

[jeremyw]

I also have the same issue, even after modifying the single sign out URL as suggested.

I believe the contractor is signing into the device with a Microsoft account, and the GlobalProtect SAML process gives no option to choose a different account.

[johnwilliams]

Is there an update or resolution to this? We have several contractors that have not been able to use our VPN due to this issue. Currently running GP agent 5.2.10, and software 10.1.7 on the firewall. 

[jeremyw]

Check if the end user is using any other software which has been logged in using SAML authentication.

Also try changing the 'Use Default Browser for SAML Authentication' setting. Make sure you are on the latest GlobalProtect client version as well, as this setting did not apply correctly on some versions.