topic Re: Cached credential issue when using SAML with Global Protect Client and MS Azure in GlobalProtect Discussions

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

ddockter — Tue, 26 Oct 2021 16:31:29 GMT

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.

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

dwlord — Tue, 26 Oct 2021 19:39:43 GMT

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.

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

ddockter — Tue, 26 Oct 2021 19:43:23 GMT

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

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

dwlord — Tue, 26 Oct 2021 19:51:25 GMT

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.

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

dwlord — Tue, 26 Oct 2021 21:29:47 GMT

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

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

ddockter — Wed, 27 Oct 2021 16:27:43 GMT

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

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

dwlord — Thu, 28 Oct 2021 14:13:08 GMT

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.

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

HenryA — Mon, 25 Apr 2022 16:30:20 GMT

We have the same issue. Any solution to that?

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

jeremyw — Thu, 05 May 2022 02:47:35 GMT

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.

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

johnwilliams — Wed, 11 Jan 2023 18:03:52 GMT

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.

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

jeremyw — Wed, 11 Jan 2023 20:55:20 GMT

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.

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

A.Hesseltine — Tue, 12 Nov 2024 17:50:33 GMT

Any updates on things that work to resolve this?

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

akolodziej — Mon, 24 Feb 2025 18:38:14 GMT

If SSO is enabled, users who already logged into another service (like Office 365) don't need to log in again to GP. If this is disabled, they must always log in manually. Here's how you can possibly get around this...Clone your existing Portal Agent config and specify the contractor in the user/group section. Under the App Tab, change Use Single Sign-On to No. This should prompt them to enter their credentials.