Portal & ArcGIS Server Federation Issue with DNS Alias (CNAME record) - Solved!

[PF1]

This is more for informational purposes to hopefully help the community resolve this issue if they come across it (Knowledge Base)

Background:

We have an on-premise deployment of the Portal for ArcGIS product (ArcGIS for Server Extension).  Currently running 10.2.1 but working on an upgrade to 10.2.2.  Config-store/content directories are all local C Drive.  Windows Server 2008 R2 64-bit Virtual Machine (VMWare) with 2 vCPU and 6GB Ram.  The portal has a web-adaptor and is configured with Integrated Windows Authentication (IWA) using kerberos (and/or NTLM if needed).  All communication over HTTPS using a TLS 1.0 or higher connection. 

The portal has 1 federated ArcGIS Server (no web-adaptor) and designated as a hosting server.  We have no publishers, the AGS hosting server is not used to actually host features/services, it is only there to enable users to upload zipped shapefiles (up to 1,000 features). We have a pretty large ArcGIS for Server deployment in our enterprise that our users publish to (outside the portal) and then manually register content with our internal portal if necessary.  

Our Issue:

We had a lot of issues during the upgrade, but finally worked through them all except being able to add the AGS as a federated/hosted arcgis server.  We were not able to do an upgrade in place (10.2.1 to 10.2.2).  After about 90 minutes it would fail starting the windows NT service.  A complete un-install of 10.2.1 and re-install of 10.2.2 pointing to an existing content directory worked.  But the AGS federation was still an issues (for the past 2 weeks). 

We watched network traffic, and when trying to federate the AGS it was calling a page like this:

https://dnsalias.domain/portal/sharing/proxy?https://agsservername.domain:6443/arcgis/rest/info?f=js...

we kept getting an HTTP Error code response 403 (forbidden) and an IIS log entry that looked something like:

#Software: Microsoft Internet Information Services 7.5

#Version: 1.0

#Date: <DATE> <TIME>

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

<DATE> <TIME> <Server-IP> POST /portal/sharing/proxy https://agsservername.domain:6443/arcgis/rest/info?f=json 443 <DOMAIN>\<USERNAME> <CLIENT-IP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/5.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+InfoPath.3) 403 0 0 306

We tried multiple methods of federating the portal (including manually doing it through the portaladmin rest interface).  No matter what we did, we could not get past this 403 forbidden. 

The Resolution:

After exhaustive research... (and about to open a ticket w/ Esri) we finally stumbled across the Configuring a reverse proxy server with your portal help article (which I do not remember when we originally installed our portal @ 10.2).  Executing this configuration setting solved our issue!

Now we technically do not have a reverse proxy (other than the out of the box web-adaptor) in front of the portal, but it seems to have fixed our problem with the alias.  We had also tested this in an environment without the alias and did not need to implement this configuration setting when we had no alias applied. 

[deleted-user-pYdfRjvSAbTJ]

Hello,

how did you create the reverse proxy? Apache? IIS?

Thank you

[PF1]

Hi Roberto, For this thread, we do not actually have a reverse proxy in front of our portal.  We instead applied a DNS alias but that broke our server federation.  Following the configuration steps in the 'Configuring a reverse proxy server with your portal' solved our system issues.  We have, however, on other systems deployed a reverse proxy in front of various solutions.  We have used network appliances (such as NetContinuum and Barracuda Networks Web-Application Firewall) but have also used the Microsoft IIS Application Request Routing (ARR) successfully on a few other projects. 

[deleted-user-pYdfRjvSAbTJ]

Thanks for your reply,

I also tried to use ARR, but I don't understand an issue: the reverse proxy works, but when I try to access the portal home page from the proxy URL, portal response is a redirect (http 302) and the browser is redirected to the original web adaptor URL.

is it something you experienced? because what I expect from a proxy is that it hides the destination URL.

Thank you.

[PF1]

Hi Roberto,

I think it depends on how you setup the ARR configuration.  It appears you are experiencing a URL Re-Direct rather than a URL Re-Write.  We have set it up ARR to do a URL Re-write 2 different ways (depending on requirements):

Option 1: Setup a server farm and then establish an inbound rule with a 'URL Re-write' Rule at the root of the server.  Make sure under 'Actions' that Route to Server Farm is selected:

Option 2: Do not setup the server farm but instead, create a Reverse Proxy Inbound Rule‌ with an action of 'Re-Write':

Good luck!  If you do a URL Re-direct it will look like this and that might be the reason you are getting an HTTP Status Code 302:

Kuddos to Dan Huber‌ who helped us establish rules in a few environments (they get a little tricky).

[JonathanQuinn]

Roberto Messora‌ did you set the Web Context URL, following the use a reverse proxy with Portal documentation that pfoppe‌ mentioned?  That should tell the Portal that there's a different front-end than the web adaptor.  It only redirects to the web adaptor because that's what it knows to be the entry point to the portal.

[simoxu]

Thank you Patrick, it works!