Portal design question DMZ and intranet

[MichaelNüßlein]

We have a portal 10.8.x installation (Portal + Hosted Server + Data Store) behind a firewall (Intranet) which is linked to an AD via LDAP. There is no need to log into the Portal from the internet. However, it should be possible to publish map content to the public on the internet.

We are interested in the questions which infrastructure must be available in the DMZ, which in the intranet and how must the firewall be configured so that the content of the portal is visible on the Internet

Is there anybody who had simular questions and have found a successful solution?

Thanks

Armin 

[JayHodny]

Hi.  We have a similar multi-machine setup for ArcGIS Enterprise 10.8.1 with AD.  Our two web adaptors sit in our DMZ server to allow us access through the firewall with appropriate permissions.  I don't know the deeper details on configuration, but I hope this helps.  Regards, Jay

[MichaelNüßlein]

Thank you for your response. One additional question. You said you have both web adaptors (portal and arcgisserver) in the dmz. Does this mean your log into portal is done from the dmz-url?

[NoahMayer]

I wanted to emphasize that ArcGIS Enterprise portal supports only one DNS for public portal URL (the web context URL), so there cannot be an internal-url and a dmz-url - the URL must be the same for internal and external users, and as @DavidHoy mentioned in his response you can use Split-DNS configuration for that. Also please note that this URL must be an externally resolvable URL, e.g. https://gis.company.com/portal and not an internal URL, e.g. https://gis.company.domain/portal 

[Faris_Esri · Accepted solution]

Hello! 

That's a great question and one that comes up pretty often with our customers. Take a look at our documentation on setting up a reverse proxy to facilitate public accessibility:

• Configure your portal to use a reverse proxy server

To sum it up, you can install your Portal Web Adaptor on a designated Web Server in the DMZ that handles routing requests back to your portal internally. The Web Server would be identified by the reverse proxy alias (typically a DNS), and you can configure the Web Adaptor as you normally would with a Web Adaptor installation that leverages a DNS. This means that when setting that up you need to make sure you use the public-facing URL in the Web Adaptor configuration page as opposed to the default localhost (i.e. the URL for configuration would be https://webAdaptorHost.domain.com/webAdaptorName/webadaptor)

One thing to note before delving into this process is that it affects your portal's WebContext, so it would be advisable to set that up before installing the applications, and especially before federating any ArcGIS Servers to the Portal. Make sure to review the document above as it highlights the process with greater detail. Additionally, make sure you plan how it would be set up in your own environment as some environment-specific variations implemented by your own IT might require a different level of implementation. 

Hope that helps!

Cheers!

[MarcBate · Accepted solution]

When it says reverse proxy server, does that mean ArcGIS Web Adaptor, or do we need to use some 3rd party one on our IIS server in the DMZ?

[DavidHoy]

you can choose to include a reverse proxy as well as web adaptors if you want - but it is adding a tier you may not need. It depends on how much isolation from the internet you need to provide and what ICT security policies you need to meet.
See this great post from @NoahMayer 
Deployment Patterns for Exposing ArcGIS Enterprise... - Esri Community

[DavidHoy · Accepted solution]

there may be a little more nuance here.

If the new Web Adaptors in the DMZ are accessible from within the organisation (behind the firewall) then you should be OK to do this so long as the DNS alias for the Web Adaptor server matches the public facing URL used for the Portal and Servers' WebContextURL.
We have seen sites where the organisation's firewall rules will not allow access to Web Adaptors in the DMZ. In these cases, we have needed to set up separate Web Adaptors inside the firewall for internal use. As the Portal and Servers must use the same WebContextURL, this means the internal WA server (or Load Balancer if used) must have the same DNS alias as the WA server in the DMZ

- the solution is to use "Split-DNS" - a configuration that allows a different domain name resolution depending on the IP address range of the calling client.

i.e users inside the firewall get the IP address of the internal WA server

public users see the IP address of the DMZ WA server