Web Adaptor on internal ArcGIS Server machine

[WestervilleGIS]

We would like to know if our main federated hosting ArcGIS Server (that is installed behind our firewall) can/should have a web adapter installed on it or if it should be in the DMZ?  We only need to access our REST endpoints of our hosting server from inside our network, so installing the web adapter for that server in the DMZ seems unnecessary. Is that an accurate setup? 

The other ArcGIS Server (not federated with our Portal) will be used to publish services for public facing maps/apps so we want the web adaptor for that to be in the DMZ so people could hit the REST endpoints if necessary.

[JonathanQuinn]

The Web Adaptor doesn't need to be on the Server machine nor in the DMZ. It can be on whatever machine you have that meets the system requirements and meets the intended purpose of the endpoint, (for example, internal vs external access). You can set the WA up on the same as the ArcGIS Server for internal traffic.

[WestervilleGIS]

After several months, we finally have all the pieces of Enterprise installed and mostly functioning however we do have a pretty large problem.  Our Web Adaptor for Portal is in the DMZ and the Portal, Hosting Server, and Datastore machines are all behind our firewall on separate machines.  Users that are either on our network or outside our network can hit the DMZ Portal WA URL (webgis.westerville.org/portal) and use our GSuite credentials to be authenticated and allowed into the Portal.  

Our problem starts with viewing content in the map viewer of portal.  Users that are on our network can log in and view services in the map viewer that are published to the Hosting Server but if they users are NOT on the network (say using a home PC) they get an error saying "The layer XX cannot be added to the map".  The Hosting Server does not have a Web Adaptor associated with it so the services are published using the FQDN in the service URL.  I also checked the developer tools in Chrome (from outside the network) when attempting to view a service in the map viewer and saw it says "dojo.js:141 GET https://<hostingserverFQDN>.westerville.org/host/rest/info?f=json net::ERR_NAME_NOT_RESOLVED”

I am curious if this is a certificate issue?  We are using self signed certificates internally between the servers and a wildcard certificate on the DMZ for *.westerville.org.  Or do we need to have a Web Adaptor in the DMZ for the Hosting Server as well?  The reason why we did not want to do this is because we do not need/want to have the services and services directory available publicly for the Hosting Server. 

Hopefully this makes sense and someone can help us!

[JonathanQuinn]

If you intend on letting users outside of you network access services, then you need to make sure the services URL is accessible. That would mean you need to put the Web Adaptor for the hosting server in the DMZ. You can disable the services directory to reduce the chance someone is going to come across your services directory and make sure that the permissions for the services are correct to ensure there is no unauthorized access.

[WestervilleGIS]

We now have web adaptors for both our Hosting Server and our Portal in the DMZ.  We have wildcard certificates (for our domain *.westerville.org) imported and used on the DMZ machine and the Hosting Server and Portal Server.  When we log into our portal (from on or outside our network), and go to the Organization > Settings > Server page we see the federated server (which is also set as our hosting server) has a red exclamation point and an error message associated with it (see screenshot).  We then click validate and it will validate correctly and show a green check mark however when hovering over it there still is an error associated with it (see second screenshot).

Interestingly enough, everything appears to be working properly regardless.  We can create content, do analysis, log in and view content from everywhere etc.  Any ideas what may be causing these errors and if they are truly an issue or more of warning regarding the wildcard certificates?  These errors did not come up when we were using self-signed certificates for testing.

Any insight on this would be appreciated!

[JonathanQuinn]

Are you using a wildcard certificate from your own domain certifying authority? If the certificate is self signed and the FQDN of the URL using the certificate matches the CN, there's no problem. If the certificate is a wildcard certificate signed by a certificate authority that is not trusted by Portal or Server, then the request will fail. If the certificate CN does not match the FQDN of the URL and it's not a wildcard, the requests will fail.

Try to import the root certificate into Server and see if that helps.

Configure ArcGIS Server with a new CA-signed certificate—ArcGIS Server Administration (Windows) | Do... 

You can also import it into Server using the importRootOrIntermediate API.

Import Root Certificate