Portal Redirecting away from DNS Alias to Hostname

[CodyMcDonald]

I'm running ArcGIS Server and Portal 10.6.1 with a web adaptor configured for each on the same server. Everything was working fine, but suddenly viewer pages are not loading. Upon inspection, I realized that the viewers are being redirected to {servername}.com instead of {alias}.com. On our intranet, {servername}.com does not resolve because it is not secure (our ssl certificate is set to {alias}.com). On the server, when I try to login to Portal, it does the same redirection, away from {alias}.com/portal to {servername}.com:7443/arcgis/home. At first I suspected the web adaptor, but then I tried to login at {alias}.com:7443 and it still redirects. Interestingly, I can login to portaladmin at (alias}.com/portal/portaladmin. I've rebooted the server, tried unregistering and re-registering the web adaptor, added a web context url to system properties (https://{alias}.com/portal), however I keep hitting this redirect problem. Anyone know what may have happened?

[CodyMcDonald]

Additional Info:

Windows Server 2016 utilizing IIS

Attempted to add {alias}.com as a trusted server within Portal Security Settings

This redirection does not happen with any other web services, such as {alias}.com/arcgis/rest/services, so I do not believe there is a widespread DNS issue.

[CodyMcDonald]

I have read that a hostname change is not supported with Portal. I have not changed the name of my server, but Portal seems to have decided to change the portal.machine.name in portal-config.properties from DNS alias to the server name. I restored a backup of my server from the day prior and I can see it was changed, but how it was changed I am unsure. 

I also noticed three urlrewrite.xml files that appear to be updated based off the portal.machine.name. I tried to set those back to the alias, but they were soon overwritten back to the hostname.domain.com. 

The portal-config.properties has a warning about not modifying it directly, and to use Portal Admin instead, but I do not see anywhere on portal admin where it is determining the portal.machine.name.

[CodyMcDonald]

I would like to try to close the loop on this in case anyone else has the same experience. From an end user's perspective, the map viewer page throws this error: "Unable to load //alias.domain.com/[portal web adaptor]/sharing/rest/portals/self?f=json status: 0"

Through the developer console, I can see two attempts are made to hit self?f=json with the request URL of https://alias.domain.com/[portal web adaptor]/sharing/rest/portals/self?f=json, but the status code is 301 and the response header location is https://hostname.domain.com:7443/sharing/rest/portals/self?f=json. A third attempt is made to reach self?f=json this time with the request URL of https://hostname.domain.com:7443/sharing/rest/portals/self?f=json but the request method is OPTIONS instead of GET, and this is where the page stops loading returning status code 405 method not allowed. 

We were able to resolve the broken map viewer pages by simply unregistering the web adaptor for Portal, uninstalling and then reinstalling it. Our Portal still redirects away from the alias to hostname, but at least the map viewers load. After a server reboot, it reverted back to the same issue which we rectified again by reinstalling the web adaptor. 

[JonathanQuinn]

So the Portal machine has multiple hostnames? When you registered the Web Adaptor, did you use the alias or the hostname.domain.com to reach the web adpator registration page (ex https://alias.domain.com/[portal web adaptor]/webadaptor/portal)?

[CodyMcDonald]

The server hosting portal has a single hostname, which is different than the alias our ssl certificate is granted for. Users access our web content at alias.domain.com. When the web adaptor was originally installed, it was registered with the alias. Now, with or without the web adaptor installed, the portal login redirects to hostname.domain.com:6443/arcgis/home. After uninstalling and reinstalling the web adaptor, I attempt to re-register it at the alias. This works, and it says you may now login to your portal at https://alias.domain.com/[web adaptor name]. Although our map viewers begin working again after the web adaptor reinstall, attempting to access portal still redirects to hostname.domain.com:6443/arcgis/home.

I initially though that the background redirection was breaking our map viewers, but that does not appear to be the case as the redirection is still occurring.

[NathanielRoth1]

Have you been able to solve this issue? We're experiencing this now with an Azure deployment. Jonathan Quinn Cody McDonald

[CodyMcDonald]

Unfortunately, no. After each reboot we still have to go through the whole process of unregistering the Portal web adaptor, uninstalling it, rebooting the server again, and then re-install and configure the new web adaptor with Portal. I'm still unsure where Portal's affinity for our server name as opposed to the DNS alias stems from, what corrupts the web adaptor during a reboot, or why re-installing it resolves the issue partially (the redirection still occurs, but the Portal map viewers work again).

[DavidColey]

Hi Cody - As I am preparing to upgrade to 10.7.1 from 10.7 I began looking at posts for any gothchas.  I ran across this exact issue at 10.6.  Basically you get around this by using the FQDN for the machine when registering the Portal with web adaptor and then the web context and redirect uri settings in portal admin keeps it from bouncing back to the machine name:

From Portal Admin>Home>System>Web Adaptors > web adaptor item name:

Machine name: webadaptor_machine_name.bcc.scgov.local
Machine IP: 10.140.20.125
URL: https://webadaptor_machine_name.bcc.scgov.local/portal
Description:
HTTP port: 80
HTTPS port: 443

Once registered, the web adaptor shows:

https://portal_machine_name.bcc.scgov.local:7443

as the url and shows the web server machine name as the machine registered with portal:

scggiswb01pw.bcc.scgov.local

We use F5 so our web server does not have a DNS entry.  The F5 handles the redirect from web_server_machine_name to public_facing_url_name (F5Name.scgov.net).  When I register the webadaptor with Portal from the webserver, I bypass the F5 first by uncommenting the IP addresses in my Hosts.ini file. We could never get it to register otherwise.

{"WebContextURL":"https://F5Name.scgov.net/portal","privatePortalURL":"https://PortalDNSName.scgov.net:7443/arcgis","disableSignup":true}

{"appId":"arcgisonline","redirectURIs":["https://ags3.scgov.net","https://PortalDNSName.scgov.net","https://webserver_machine_name.bcc.scgov.local","https://portal_machine_name.bcc.scgov.local","*.bcc.scgov.local","*.scgov.net","*.arcgis.com"]}

We have found, for us anyway, the order of the redirect uri's does matter.  So the user comes into portal at ags3, is redirected to PortalDNSName.  The machine names then associate with the DNS

[DavidColey]

Also, here is a thread that Jonathan Quinn‌ and I went back and forth on when I was having issues a few months ago that may be of help to you-

https://community.esri.com/thread/121507