Having trouble connecting to Portal in ArcGIS Pro with two Portal Web Adaptors

[AbigailStephens]

We are in the final stages of stetting up a new ArcGIS 10.7.1 Enterprise deployment and are running into some configuration hiccups.

Our deployment is a Linux deployment on AWS and follows the standard ArcGIS base deployment - ArcGIS Portal, ArcGIS Server (with GeoEvent Server also installed), ArcGIS Datastore, and web adaptors.  The only thing different from the norm is that we have 4 web adaptors - 2 for each portal and server. For each, portal and server, there is an “external” and an “internal” web adaptor. The “external” web adaptors use SSO and are available on the open web, while the “internal” web adaptors are only available on a VPN and with an ArcGIS Enterprise level log-in, not SSO.

Our current problems appear to be related to the “WebContextURL” property in our ArcGIS Portal.

When the “WebContextURL” is set to the “external” web adaptor, everything works as expected, except we cannot connect to the portal in ArcGIS Pro. When we try to connect using the “external” web adaptor, the connection is added to the list of Portals, but when you go to sign in, get an error reading “Unable to establish connection to {external web adaptor/arcgis}” appears. If using the “internal” web adaptor or the actual portal location (using port 7443), the connection is added and the portal is marked “available”, but when you go to sign in, it allows you to sign in, but then is marked “Not signed in”.

When the “WebContextURL” is set to the “internal” web adaptor, you can successfully connect and sign into the portal in ArcGIS Pro. However, we begin to see problems with our Portal through the “external” web adaptor, including being unable to overwrite CSVs hosted on Portal, enabling Time Settings on hosted feature layers, and being unable to view  maps through “external” web adaptor links without a VPN connection.

We would like to keep the “WebContextURL” is set to the “external” web adaptor but figure out how to connect to portal in Pro, using any of the three URLs we have set up to access the Portal (“external” web adaptor, “internal” web adaptor, and direct link with port).

One last thing to note is that we also have a 10.5.1 deployment running simultaneously. There are some bugs with that deployment, and we chose the simultaneous deployment instead of a stepped upgrade (10.6 to 10.7.1) to avoid bringing those bugs into the 10.7.1 environment.

Has anyone else encountered these problems or have any ideas on working through them? We have read through Esri’s documentation on using a reverse proxy server in Portal, as well as setting the “WebContextURL” property in portal, and tried all variations of the property in portal that we can think of, but are still arriving back at this point.

[JonathanQuinn]

Portal can only have one "public" URL, so setting up separate URLs for internal and external users can present a challenge. You have two options:

1) Look into SAML/ADFS which will give you the option for AD users to achieve a single sign on like experience, (they'll just need to click on the button to use their SAML accounts), but also give you anonymous access. The publicly accessible URL will be the only URL/endpoint that users will use to reach the portal

2) Look into a Split-DNS type approach, where external users reach an externally available endpoint, but internal users reach a different one, but both have the same FQDN. Depending where the user is, DNS is resolving the FQDN differently but to the same FQDN.

[AbigailStephens]

Jonathan Quinn,

Thanks for your suggestions!

Working with our DevOps team, we were able to make a change to the SSO set-up for the "public" web adaptor, similar to your first suggestion. This system doesn't have any anonymous users; everyone who accesses maps on this portal have named accounts accessed through SSO, but this change to the SSO settings allows our Portal Admin account to log-in without going through SSO, and therefore log into Portal through ArcGIS Pro.