<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: PA Global Protect in GlobalProtect Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pa-global-protect/m-p/1244096#M7189</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/1175515515"&gt;@V.Tolstorozhikh&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="137" data-end="390"&gt;This sounds less like a GP settings misconfiguration and more like a SAML configuration issue to me. That said, I’d still start by verifying that the new portal is referencing the correct SAML IdP Server Profile tied to the new Azure app you configured.&lt;/P&gt;
&lt;P data-start="137" data-end="390"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="392" data-end="625"&gt;When you mention seeing successful connection attempts, I’m assuming that’s based on the system logs. If so, is the GlobalProtect client actually getting stuck after the login redirect without presenting an explicit error or failure?&lt;/P&gt;
&lt;P data-start="392" data-end="625"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="627" data-end="837"&gt;You also mentioned seeing “Authentication Failed” when launching the app from myapps.microsoft.com. In most cases, that behavior points back to the Azure enterprise app itself rather than GlobalProtect.&lt;/P&gt;
&lt;P data-start="627" data-end="837"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;From the symptoms, it looks like the client is successfully redirecting to Entra ID for authentication (which would explain the “success” events), but the flow is breaking when Entra attempts to send the SAML response back to the portal, or the portal is rejecting the assertion.&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;In that case, I’d double-check that the ACS&amp;nbsp;and Entity ID&amp;nbsp;configured on the Azure app exactly match what the portal is expecting (including things like :443 if applicable), as even small mismatches there can cause this behavior.&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;As a final sanity check, I’d re-export and re-import the metadata, then open the XML and confirm the EntityID, ACS/Reply URL, and signing certificate all match what the portal expects.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 18 Dec 2025 01:04:18 GMT</pubDate>
    <dc:creator>JayGolf</dc:creator>
    <dc:date>2025-12-18T01:04:18Z</dc:date>
    <item>
      <title>PA Global Protect</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pa-global-protect/m-p/1244090#M7188</link>
      <description>&lt;P&gt;I have 4 portals and 4 gateways (4 different PA fw/vm ) of a GlobalProtect. PA is integrated with azure (an azure app per each gateway).&lt;BR /&gt;I added one more new portal and one more new subnet to the one of the existing gateways, a new dns a-record and a new azure app. &lt;BR /&gt;ISSUE: Clients can't connect to this portal, it's getting stuck after connection attempt. There're "success" events on the azure log and PA log. Also, I get "Authentication Failed" error by using azure app from myapps.microsoft.com&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 17 Dec 2025 22:48:59 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pa-global-protect/m-p/1244090#M7188</guid>
      <dc:creator>V.Tolstorozhikh</dc:creator>
      <dc:date>2025-12-17T22:48:59Z</dc:date>
    </item>
    <item>
      <title>Re: PA Global Protect</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pa-global-protect/m-p/1244096#M7189</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/1175515515"&gt;@V.Tolstorozhikh&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="137" data-end="390"&gt;This sounds less like a GP settings misconfiguration and more like a SAML configuration issue to me. That said, I’d still start by verifying that the new portal is referencing the correct SAML IdP Server Profile tied to the new Azure app you configured.&lt;/P&gt;
&lt;P data-start="137" data-end="390"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="392" data-end="625"&gt;When you mention seeing successful connection attempts, I’m assuming that’s based on the system logs. If so, is the GlobalProtect client actually getting stuck after the login redirect without presenting an explicit error or failure?&lt;/P&gt;
&lt;P data-start="392" data-end="625"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="627" data-end="837"&gt;You also mentioned seeing “Authentication Failed” when launching the app from myapps.microsoft.com. In most cases, that behavior points back to the Azure enterprise app itself rather than GlobalProtect.&lt;/P&gt;
&lt;P data-start="627" data-end="837"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;From the symptoms, it looks like the client is successfully redirecting to Entra ID for authentication (which would explain the “success” events), but the flow is breaking when Entra attempts to send the SAML response back to the portal, or the portal is rejecting the assertion.&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;In that case, I’d double-check that the ACS&amp;nbsp;and Entity ID&amp;nbsp;configured on the Azure app exactly match what the portal is expecting (including things like :443 if applicable), as even small mismatches there can cause this behavior.&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-start="839" data-end="1118"&gt;As a final sanity check, I’d re-export and re-import the metadata, then open the XML and confirm the EntityID, ACS/Reply URL, and signing certificate all match what the portal expects.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 18 Dec 2025 01:04:18 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pa-global-protect/m-p/1244096#M7189</guid>
      <dc:creator>JayGolf</dc:creator>
      <dc:date>2025-12-18T01:04:18Z</dc:date>
    </item>
  </channel>
</rss>

