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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

L1 Bithead

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.

11 REPLIES 11

L1 Bithead

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.

L1 Bithead

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

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.

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...

L1 Bithead

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

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.

We have the same issue. Any solution to that?

L2 Linker

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.

L0 Member

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. 

 

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.

L0 Member

Any updates on things that work to resolve this? 

  • 18834 Views
  • 11 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!