Enterprise deployment with different external/internal domains

[LanceCole]

Hello All, 

We got Enterprise 11.1 deployed on our test platform and all our migration details worked out.  However, IT announced this morning that the update of our internal domain name will not be implemented at this time.  We had planned on using the same internal and external domain to facilitate the deployment of our new 11.1 Enterprise system.  The web adapters were to be placed in a DMZ and the Portal and GIS Servers placed on the internal network behind the firewall.

I understand the ArcGIS Enterprise portal supports only one DNS for public portal URL.  Can this be set to the internal domain with internal server and portal web adapters then add a second pair of Web Adapters in the DMZ as noted below?   We do not have a reverse proxy available.

Modified from  Deployment Patterns for Exposing ArcGIS Enterprise Secured Services to External Users 

How would the two additional Web Adapters be configured?  I assume external.domain.com to the internal.domain.net, all on 443. 

[John_Tyll]

Hi LanceCole,

I feel your pain. I have been planning out my new deployment. My current production is on 10.6.1 and TLS is not being used. Going to 11.1 and being required to use TLS has really baffled me. I initially had the same layout you are showing. I discovered Web Adapter configuration is basic and only allows you to point to (Identify) your "site" not another web adapter. My problem was I needed to have internet access for the public and for authenticated users using web tier authentication with active directory. I am eager to see other responses so if you get this working please post details. 

I decided, for now, to just have a standalone server in this scenario. If it helps this is what I did.

In the DMZ I am using IIS with 2 rewrite rules in the web.config file to direct traffic to my internal web adapters. I also added a HOST entry of my internal.domain.net. On my ArcGIS Server I have 2 web adapters, "public" and "arcgis" that are specified in my rewrite rules. In IIS on internal.domain.net I am binding the site with the external.domain.com certificate. It is opposite to what you are suggesting but this does allow me to use external.domain.com\public - anyone can access any services we publish as public and external.domain.com\arcgis - only "internal.domain.net" AD users may access.  This does mean my internal calls go to the DMZ but I don't think it will be a burden in my case. I am not sure this is best practice, but it is difficult to find details on specifics (host name, certificate to use, etc...).  

[Scott_Tansley]

You can't go web adaptor to web adaptor.  You'd need to allow 6443 and 7443 from the DMZ Web Adaptors to the internal servers.  The hardest part is getting your IT team to open the none-standard ports.  An alternative would be to create a route from the Internet through the DMZ using 443 only, and terminate at the internal web adaptors.  It literally comes down to the standards/practices of your Enterprsie Architecture, but I've done both of the above multiple times.  

[LanceCole]

Thanks, @John_Tyll  and @Scott_Tansley for your input and feedback.

I ended up using the following configuration after coordinating with our IT department and ESRI Support.

1) The external.domain.com is passed through the external firewall on port 443 to the IIS server in the DMZ via NAT and a Web Application Firewall.  The IIS server hosts the Portal and server web adapters using a CA-issued certificate for the external domain.  However, the IIS server is a member of the internal domain but on a different subnet.

2) The Web Adapters were set to the external 443 port on the IIS server and configured using the external URLs https://external.domain.com/portaladaptername/webadapter  and https://external.domain.com/serveradaptername/webadapter. These are pointed to the internal Portal and Server names - https://portalserver.domain.local:7443 and https://arcgisserver.domain.local:6443.

3) We set up a Split-DNS on our internal domain for external.domain.com.  This directly directs the internal request to the IIS web adapters in the DMZ.  The external DNS directs the external IP to our network edge where the external firewall uses NAT to the internal DMZ IP.

4) We use SSL certificates from our internal domain CA on all internal ArcGIS and Portal Servers.  These were requested and installed on each server in place of the self-signed certificates.  We also added our domain CA root and intermediate certificates to these servers.  We could have added each server's certificate to each ArcGIS server, but this quickly gets complicated with multiple servers.  The IIS server is using a commercial CA for the external domain name. 

5) At this point, everything was working, and we integrated Portal using IWA.  This allowed us to set up a domain administrator account on Portal before federating.  All the existing services were referenced into Portal under the domain account used to federate.

6) We chose to go ahead and federate the Portal with our ArcGIS server site.  We logged onto Portal using https://external.domain.com/portaladaptername/home.  For the Services URL we used https://external.domain.com/serveradaptername.  We have multiple ArcGIS GIS servers running on our ArcGIS Server site; therefore, the same URL was used for the Administration URL rather than one of the 6443 URLs.  I missed this requirement the first time - thank goodness for hourly server snapshots.  This does require Administration to be enabled on the server web adaptor.  

https://enterprise.arcgis.com/en/portal/latest/administer/windows/federate-an-arcgis-server-site-wit...