<?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 Azure application gateway and TLS termination in ArcGIS Enterprise in the cloud Questions</title>
    <link>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254682#M564</link>
    <description>&lt;P&gt;On-prem deployment has &lt;A href="https://gis.domain.com" target="_blank" rel="noopener"&gt;https://gis.domain.com&lt;/A&gt; being passed through our firewall to our webadaptor vm, port 443 only. *.domain.com CA signed cert is installed on webadaptor VM, IIS. 2 webadaptors are installed on this same machine, /portal(443) and /server(443)&lt;/P&gt;&lt;P&gt;We just finished a base configuration deployment in Azure: portal, server, datastore and webadaptor VMs. We deployed Azure application gateway in front of the webadaptor VM. Our *.domain.com cert has to be installed on both the azure app. gateway &lt;U&gt;and&lt;/U&gt; the backend webadaptor VM.&lt;/P&gt;&lt;P&gt;The application gateway supports TLS termination, which offloads it from the webadaptor VM. This got me thinking, is it beneficial, (CPU wise) to configure ArcGIS Enterprise communication solely over :80 ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Is this possible?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Azure application gateway terminates *.domain.com TLS session, then passes requests:&lt;/P&gt;&lt;P&gt;:443/portal --&amp;gt; &lt;A href="http://webadaptorvm.internal.com/portal" target="_blank" rel="noopener"&gt;http://webadaptorvm.internal.com/portal&lt;/A&gt;&lt;/P&gt;&lt;P&gt;:443/server --&amp;gt;&lt;A href="http://webadaptorvm.internal.com/portal" target="_blank" rel="noopener"&gt;http://webadaptorvm.internal.com/portal&lt;/A&gt;&lt;/P&gt;&lt;P&gt;I would install new webadaptors with the same names, listening on port80. Would this also require me to configure the portal and server VMs to listen on http also?&lt;/P&gt;&lt;P&gt;Portal doc: &lt;A href="https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-https.htm" target="_blank" rel="noopener"&gt;https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-https.htm&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Server doc: &lt;A href="https://enterprise.arcgis.com/en/server/latest/administer/windows/secure-arcgis-server-communication.htm" target="_blank" rel="noopener"&gt;https://enterprise.arcgis.com/en/server/latest/administer/windows/secure-arcgis-server-communication.htm&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 02 Feb 2023 23:26:24 GMT</pubDate>
    <dc:creator>danbecker</dc:creator>
    <dc:date>2023-02-02T23:26:24Z</dc:date>
    <item>
      <title>Azure application gateway and TLS termination</title>
      <link>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254682#M564</link>
      <description>&lt;P&gt;On-prem deployment has &lt;A href="https://gis.domain.com" target="_blank" rel="noopener"&gt;https://gis.domain.com&lt;/A&gt; being passed through our firewall to our webadaptor vm, port 443 only. *.domain.com CA signed cert is installed on webadaptor VM, IIS. 2 webadaptors are installed on this same machine, /portal(443) and /server(443)&lt;/P&gt;&lt;P&gt;We just finished a base configuration deployment in Azure: portal, server, datastore and webadaptor VMs. We deployed Azure application gateway in front of the webadaptor VM. Our *.domain.com cert has to be installed on both the azure app. gateway &lt;U&gt;and&lt;/U&gt; the backend webadaptor VM.&lt;/P&gt;&lt;P&gt;The application gateway supports TLS termination, which offloads it from the webadaptor VM. This got me thinking, is it beneficial, (CPU wise) to configure ArcGIS Enterprise communication solely over :80 ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Is this possible?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Azure application gateway terminates *.domain.com TLS session, then passes requests:&lt;/P&gt;&lt;P&gt;:443/portal --&amp;gt; &lt;A href="http://webadaptorvm.internal.com/portal" target="_blank" rel="noopener"&gt;http://webadaptorvm.internal.com/portal&lt;/A&gt;&lt;/P&gt;&lt;P&gt;:443/server --&amp;gt;&lt;A href="http://webadaptorvm.internal.com/portal" target="_blank" rel="noopener"&gt;http://webadaptorvm.internal.com/portal&lt;/A&gt;&lt;/P&gt;&lt;P&gt;I would install new webadaptors with the same names, listening on port80. Would this also require me to configure the portal and server VMs to listen on http also?&lt;/P&gt;&lt;P&gt;Portal doc: &lt;A href="https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-https.htm" target="_blank" rel="noopener"&gt;https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-https.htm&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Server doc: &lt;A href="https://enterprise.arcgis.com/en/server/latest/administer/windows/secure-arcgis-server-communication.htm" target="_blank" rel="noopener"&gt;https://enterprise.arcgis.com/en/server/latest/administer/windows/secure-arcgis-server-communication.htm&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 02 Feb 2023 23:26:24 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254682#M564</guid>
      <dc:creator>danbecker</dc:creator>
      <dc:date>2023-02-02T23:26:24Z</dc:date>
    </item>
    <item>
      <title>Re: Azure application gateway and TLS termination</title>
      <link>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254685#M565</link>
      <description>&lt;P&gt;I wouldn't.&amp;nbsp; If you choose to remove the AAG in the future or use a different product, then all your content will be HTTP.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Effecitvely, the internal configurations of each item will be HTTP.&amp;nbsp; When the client receives the webmap, the links to services etc will state HTTP, and that could cause a clash.&amp;nbsp; Also given that nearly online content is HTTPS the Portal will not be happy mixing protocols.&lt;/P&gt;&lt;P&gt;The other thing is that internal users could be routed to the IIS/Web Adaptor without going to the AAG.&amp;nbsp; If that's the case, then they still need to be HTTPS for everything to work.&lt;/P&gt;&lt;P&gt;In this day and age, I'd stick with the default flag of HTTPS Only in the Portal Security settings, and everything will work just nicely.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 02 Feb 2023 23:30:44 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254685#M565</guid>
      <dc:creator>Scott_Tansley</dc:creator>
      <dc:date>2023-02-02T23:30:44Z</dc:date>
    </item>
    <item>
      <title>Re: Azure application gateway and TLS termination</title>
      <link>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254714#M566</link>
      <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;P&gt;&lt;STRONG&gt;Is this possible?&lt;/STRONG&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Nope, don't cross the schemes.&amp;nbsp; Stay HTTPS the whole way through.&amp;nbsp; If you want to save on the Web Adaptor CPU load, consider configuring the AAG to talk directly to the 7443 and 6443 ports (still HTTPS).&amp;nbsp; You'll have to configure a few more rules in the AAG, but you can remove the WA component completely.&lt;/P&gt;</description>
      <pubDate>Fri, 03 Feb 2023 01:36:10 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-enterprise-in-the-cloud-questions/azure-application-gateway-and-tls-termination/m-p/1254714#M566</guid>
      <dc:creator>GJHollard</dc:creator>
      <dc:date>2023-02-03T01:36:10Z</dc:date>
    </item>
  </channel>
</rss>

