Cannot connect to highly available portal version 10.8.1 with error message: You are not authorized to use this resource.

[MichailMarinakis1]

Hi all, 

we have the following issue in our highly available (HA) portal, version 10.8.1. 

Our configuration is:

• 2 portal machines, running on windows server 2019, on premise, with https only connection and domain certificates.
• ArcGIS portal content is located to a shared folder, highly available, both machines have stable access to the folder (using a domain account for the service)
• 2 web adaptors pointing to each server
• 1 load balancer, pointing to the 2 web adaptors. The value of the load balancer is set to the WebContextURL
• No federation yet.

Workflow to reproduce the issue:

1. After initial installation, we checked the health status of every server, everything was fine.
2. We checked, from the portaladmin page, the SSL Certificates for each machine, they are properly set. 
3.  The links to generate tokens for both machines work properly e.g. https://standbymachine.domain.com:7443/arcgis/sharing/rest/generateToken 
4. Index status is aligned properly with the store.
5. We stop the windows portal service for the primary portal machine.
6. HA function kicks in, switches the standby to primary. Everything OK. 
7. We restart the stopped windows service, approximately some minutes after the stop.

Expected Behavior:

• No issues... 

Actual Behavior:

• In D:\arcgisportal for both servers, we have extra folders with name e.g. db1606979894714
• When we click on the ssl certificates for the standby machine, all the values are null 

• The links to generate tokens for the standby machine (sometimes for both machines!) is not accessible with error 404 e.g. https://standbymachine.domain.com:7443/arcgis/sharing/rest/generateToken. In general the arcgis/sharing/rest is not accessible.
• We cannot connect to the portaladmin, using the url ...:7443/arcgis/portaladmin with error message: You are not authorized to use this resource. 

Workaround:

Stop the windows service for the standby machine again.

Sometimes, when we wait a bit and stop the standby machine again, wait some more, and start it again, then everything is back to normal. 

Similar issue has been reported here.

Any feedback will be very useful. Thanks!

[MichailMarinakis1]

We have found the solution. Eventually, it was the value of  privatePortalURL.

There is a small note at the documentation of configuring a highly available portal:

If the privatePortalURL is different from the WebContextURL, do not set the X-Forwarded-Host header for this URL.

I used the same value for the two parameters privatePortalURL and WebContextURL. We have also configure our portal for IWA.

The privatePortalURL is not only used for communication between the federated ArcGIS Server and the portal, but also between the portal machines that participate in the portal site.

When the primary machine restarted, then the internal communication was happening via the public load balancer and that was triggering a windows authentication. 

If IWA is configured, then the privatePortalURL must have a different value than the WebContextURL.

I have unset temporarily the privatePortalURL and everything works fine. We have asked from our system administrator a load balancer address which goes through the 7443 port, bypassing the windows authentication. 

[NicolasGIS]

Hello @MichailMarinakis1,

Wahou, your configuration is almost identical as mine except that I am not using IWA but I do have Web Adaptor for reverse proxying. I already have a load balancer balancing on 7443 private portal URL which in my case is different that the public one.

But I still face the same issue. If one portal is deconnected and reconnected again, then the whole portal is messed up and you cannot access 'portaladmin', etc..

So I am wondering what could be the issue for me as Windows authentification is already out of the equation...

[MichailMarinakis1 · Accepted solution]

Hi Nicolas,

At the end it was a bug in the portal. We solve it by installing the latest patch here: https://support.esri.com/en/download/7864

Further details about the topic can be found here: https://community.esri.com/t5/arcgis-enterprise-questions/aws-10-8-1-ha-portal-not-restarting/m-p/10...

Hope this helps!

[NicolasGIS]

Such good news 🙂

Thanks !

[BenjaminBlackshear]

Following up on this, is it true that if IWA is configured, then the privatePortalURL must have a different value than the WebContextURL? Or was this just thought to be the issue when it was really the bug that the patch resolved?

I'm setting up a new 10.8.1 deployment where we are using IWA and currently have the privatePortalURL and WebContextURL set to the same value, the web adaptor registered with the portal. This hasn't caused any issues so far but I want to make sure I'm following best practices and not setting myself up for problems later.

I have installed the HA patch, do I need to set a different privatePortalURL and WebContextURL if using IWA?

[MichailMarinakis1]

Hi Benjamin, 

for us yes, it was necessary to use a different value. The privatePortalURL has to point to the 7443 port and not to the port 443. Issues appeared when we federated an arcgis server. We didn't observe any issues without a federated arcgis server.

We needed to federate an arcgis server so we used for WebContextURL e.g. https://gis.portal.com/arcgis that redirects to port 443 for each of the machines behind and for privatePortalURL we used e.g. https://gis.portal.com:7443/arcgis that redirects to port 7443 for each of the machines behind. 

Hope this answer your question!