Global Protect Portal - Azure SAML Authentication

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Global Protect Portal - Azure SAML Authentication

L1 Bithead

Users can't complete authentication to the Global Protect portal with Azure SAML auth.  When I go to the portal address in a web browser it redirects me to an Office 365 login, I enter my credentials and MFA code, it sits on a login.microsoftonline.com URL loading and eventually fails with the this URLin the address bar, <global-protect-url>/SAML20/SP/ACS.  Chrome returns an ERR_EMPTY_RESPONSE, Firefox returns a message saying, "The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."

 

I followed this documentation for setting up the Azure SAML authentication: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008U48CAE

The user authenticates successfully on the Azure side but the authentication never gets passed back to the firewall.

 

If I switch the authentication for the portal over to LDAP I can login.  Computer with the Global Protect agent can't connect either but I switched to troubleshooting in the browser to eliminate the agent version being an issue.

1 accepted solution

Accepted Solutions

L1 Bithead

Hi,

In my case, it was a network issue. Enabling Adjust MSS with default value on the interface hosting GlobalProtect Portal solved the problem.

Regards,

View solution in original post

5 REPLIES 5

L1 Bithead

Hi,

In my case, it was a network issue. Enabling Adjust MSS with default value on the interface hosting GlobalProtect Portal solved the problem.

Regards,

This solved it, thank you. We had to enable this setting for our WAN interface a while back too.  Do you have any idea why it would all of a sudden need to be enabled?  Global Protect has been working for a few months now up until the other day. 

I suppose that something has to change in the communication path which caused problems with TCP packets with too big payload (maybe some extra encapsulation).
In my case, the issue occurs on PA-VM Hyper-V, but I have PA-VM on VMWare, where SAML is working without any adjustments.

Our firewall is a PA-VM on Hyper-V as well so that is interesting. 

 

My thought as well, I have a support ticket open but haven't gotten response after 2 days.  If they ever respond I'll see if they can confirm that or agree that is a likely explanation.  If they give any helpful info I'll post back here for anyone having this issue in the future.

Give more detail on the fix, I am having the same issue but unable to follow your direction.

  • 1 accepted solution
  • 3807 Views
  • 5 replies
  • 0 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!