<?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 GP internal gateway for Azure AD authenticated users in GlobalProtect Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/gp-internal-gateway-for-azure-ad-authenticated-users/m-p/549105#M4203</link>
    <description>&lt;P&gt;In our on-prem firewalls, some policies are based on user-ID.&lt;/P&gt;
&lt;P&gt;User-to-IP mapping for the corresponding users are sourced via different mechanisms such as;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;- User-ID agents installed on domain-controllers&lt;/P&gt;
&lt;P&gt;&amp;nbsp;- terminal server agents.&lt;/P&gt;
&lt;P&gt;This setup has been working pretty well so far.&lt;/P&gt;
&lt;P&gt;However, now we have a challenge after the introduction of Microsoft "modern devices". Users logged in to these devices are authenticated against Azure AD instead of the on-prem AD servers. Because of this, on-prem firewalls are unable to acquire any user-to-IP mapping information. To address this problem, we are looking at deploying GP internal gateway on modern devices hoping that it can provide the required mapping information to the firewall. However, we have some unknowns about this approach.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;How to authenticate clients when connecting to the internal gateway&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;When a GP client connect to the internal gateway, firewall needs to authenticate it first.&lt;/P&gt;
&lt;P&gt;This authentication need to be seamless &amp;nbsp;as the user already authenticated to the device already.&lt;/P&gt;
&lt;P&gt;We have the options of certificate authentication or SAML ( by communicating with Azure AD )&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Even after this authentication, we are not sure what the format of the username populated in the firewall along with the IP address.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Since the user is authenticated against the Azure AD, we have a suspicion that the UPN (i.e. the email address ) will be populated as the username instead of the sAMAccountName (ie. Domain/username format)&lt;/P&gt;
&lt;P&gt;If the UPN is populated as the user name, the firewall will not be able to use it any of the policies as the firewall is not integrated with Azure AD.&lt;/P&gt;
&lt;P&gt;In that case, we will have to the cloud-ID-engine function as well to pull Azure-AD group mapping&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Just wondering whether anyone has implemented a similar solution ?&lt;/P&gt;
&lt;P&gt;Apologies for the lengthy message.&lt;/P&gt;</description>
    <pubDate>Wed, 12 Jul 2023 12:56:45 GMT</pubDate>
    <dc:creator>bcdomain</dc:creator>
    <dc:date>2023-07-12T12:56:45Z</dc:date>
    <item>
      <title>GP internal gateway for Azure AD authenticated users</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/gp-internal-gateway-for-azure-ad-authenticated-users/m-p/549105#M4203</link>
      <description>&lt;P&gt;In our on-prem firewalls, some policies are based on user-ID.&lt;/P&gt;
&lt;P&gt;User-to-IP mapping for the corresponding users are sourced via different mechanisms such as;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;- User-ID agents installed on domain-controllers&lt;/P&gt;
&lt;P&gt;&amp;nbsp;- terminal server agents.&lt;/P&gt;
&lt;P&gt;This setup has been working pretty well so far.&lt;/P&gt;
&lt;P&gt;However, now we have a challenge after the introduction of Microsoft "modern devices". Users logged in to these devices are authenticated against Azure AD instead of the on-prem AD servers. Because of this, on-prem firewalls are unable to acquire any user-to-IP mapping information. To address this problem, we are looking at deploying GP internal gateway on modern devices hoping that it can provide the required mapping information to the firewall. However, we have some unknowns about this approach.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;How to authenticate clients when connecting to the internal gateway&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;When a GP client connect to the internal gateway, firewall needs to authenticate it first.&lt;/P&gt;
&lt;P&gt;This authentication need to be seamless &amp;nbsp;as the user already authenticated to the device already.&lt;/P&gt;
&lt;P&gt;We have the options of certificate authentication or SAML ( by communicating with Azure AD )&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Even after this authentication, we are not sure what the format of the username populated in the firewall along with the IP address.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Since the user is authenticated against the Azure AD, we have a suspicion that the UPN (i.e. the email address ) will be populated as the username instead of the sAMAccountName (ie. Domain/username format)&lt;/P&gt;
&lt;P&gt;If the UPN is populated as the user name, the firewall will not be able to use it any of the policies as the firewall is not integrated with Azure AD.&lt;/P&gt;
&lt;P&gt;In that case, we will have to the cloud-ID-engine function as well to pull Azure-AD group mapping&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Just wondering whether anyone has implemented a similar solution ?&lt;/P&gt;
&lt;P&gt;Apologies for the lengthy message.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Jul 2023 12:56:45 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/gp-internal-gateway-for-azure-ad-authenticated-users/m-p/549105#M4203</guid>
      <dc:creator>bcdomain</dc:creator>
      <dc:date>2023-07-12T12:56:45Z</dc:date>
    </item>
  </channel>
</rss>

