nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

IIS-WebAdaptor running on non-standard Port: Some resources are requested using internal Port 7443

MarcWilkes

I have a WebAdaptor set up at a non-standard Port 447. A ReverseProxy and the Portal's WebContext-URL are configured as well. When accessing the Portals /home/ Page, all reqeusts are routed correctly. But after Login, some resources are requestes with port 7443 included. Here is my setup:

ArcGIS Enterprise 10.9.1
Reverse Proxy: https://reverseproxy.domain.com/arcgisportal
Web Server: https://webserver.internal.com:447/arcgisportal
Portal Server: https://portalserver.internal.com:7443/arcgis

I followed the documentation (https://enterprise.arcgis.com/de/portal/latest/administer/windows/use-a-non-default-port-for-the-portal-s-web-adaptor.htm) and at some point after Login a resource is requested using the internal portal port:

https://reverseproxy.domain.com:7443/arcgisportal/sharing/rest/portals/self/subscriptionInfo?f=json

This happens in the base.js --> getSecureUrl function. For some reason the property esriGeowConfig.self.httpsPort is set to 7443. The property location.hostname is set to the reverseproxy. When that method is entered, the given url is just fine:

https://reverseproxy.domain.com/arcgisportal/sharing/rest/portals/self/subscriptionInfo

Within that method that if-statement basically does this:

b = b.replace(location.hostname, location.hostname + ":" + esriGeowConfig.self.httpsPort)

As result, the url is returned as

https://reverseproxy.domain.com:7443/arcgisportal/sharing/rest/portals/self/subscriptionInfo

Note: I do have another webadaptor running on webserver.internal.com which uses the default port 443. As expected, everything works fine. (I need those two webadaptors, because I have one set up for IWA and the other for anonymous access).

Find more posts tagged with

Accepted answers

All comments

DavidHoy

Hey Marc,

do you have the portal's WebContextURL set to https://reverseproxy.domain.com/arcgisportal ?

MarcWilkes

Yes, WebContextUrl is set to https://reverseproxy.domain.com/arcgisportal

And when accessing via WebAdaptor 1 which is running on the default port, all requests are using the reverse proxy and default port 443.

This is how the WebAdaptors are registered in portaladmin -> system -> webadaptors:

WebAdaptor 1 (port 443) is registered as follows:

Machine name: webserver.internal.com
Machine IP: 172.27.11.118
URL: https://webserver.internal.com/arcgisportal
Description:
HTTP port: 80
HTTPS port: 443

WebAdaptor 2 (port 447) is registered as follows:

Machine name: webserver.internal.com
Machine IP: 172.27.11.118
URL: https://webserver.internal.com:447/arcgisportal
Description:
HTTP port: 80
HTTPS port: 447

DavidHoy

I wonder if the problem is you are using the same context "arcgisportal" for two different web adaptors on the same server and this is causing some confusion. When a request comes via the :447 WA the Portal doesn't recognise it as coming from its known WebContextURL, so redirects and responds with its internal :7443 address.
Unfortunately, I don't know what would repair that - perhaps add https://webserver.internal.com:447/arcgisportal to the redirects list allowed for the portal (go to sharing/rest/self - run getAppID for "arcgisonline", then run updateAppID and include the URL with :447)

MarcWilkes

As a test, I did unregister WebAdaptor 1 (port 443). Having only one registered WebAdaptor (port 447) did not fix the issue.

I also tried to have both Webadaptors running on port 443 with different context-names (webserver.internal.com/arcgisportal1 and webserver.internal.com/arcgisportal2). Then, I don't get any port-issues, but context-issues instead. E.g., some URLs now include the Webadaptors context-name instead of what is expected at the reverse proxy: https://reverseproxy.domain.com/arcgisportal1/sharing/rest/...

MarcWilkes

Adding the webadaptor host with the specific port 447 to the list of redirectURIs did not solve the problem, either.

ChristopherPawlyszyn

Have you confirmed the reverse proxy is setting the X-Forwarded-Host header (if layer 7) before passing the request to the Web Adaptor target? Are you using a non-default port in the WebContextURL portal system property?

Reference Doc: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm

MarcWilkes

The WebContextUrl property uses the default port 443: https://reverseproxy.domain.com/arcgisportal

I have no access to the reverse proxy configuration, but according to the Admininstrator the X-Forwarded-Host header is set. I asked for the specific configuration of the X-Forwarded-Host header and the Location Headers in order to double check. Maybe the FQDN of the GIS-Portal-Server and the reverse proxy server have been mixed up.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.