Portal and Reverse Proxy: Too Many Redirect Errors

[IrfanClemson]

Hello,

I have not been able to find step by step directions for ArcGIS for Portal and Reverse Proxy which uses IIS as a server. I have a setup in place which mostly work but fails at one critical point. Here's the setup:

1) Reverse Proxy Server (Windows) with static IP address accessible from the outside (only ports 80/443 allowed in).

2) An internal machine ('GIS') which has ArcGIS for Portal and Server installed along with their respective Web Adaptors ('portal' and 'arcgis' respectively).

3) The Portal also has WebContextURL of like 'https://gis.mydomain.com/portal'

4) The RP server has a couple of URL Rewrite entries--basically, direct to Server Farm which has the 'GIS' machine.

5) A proper SSL certificate is install as gis.mydomain.com in the IIS of both the RP server and the 'GIS' server.

So far this setup works great: I am able to access all content from the outside, such as https://gis.mydomain.com/portal/home and Gallery etc. But clicking on the Signup link in the Portal home page generates a browser error: Too Many Redirects (Header of 302). So the header being passed backed from the internal machine is 302 instead of 200.

I don't know what's happening. Maybe some extra security comes in picture when the signup.html page is called? 

Any idea?

Thanks!

Irfan

*** Update: Reverse Proxy Rules Screen Cap Added in this Question***

[IrfanClemson]

I will check later. Only difference, top of the head, is in my case the 'scheme' is http and not https in the Action Properties. The rest of the settings are default/similar to your's. I will be back. Thanks

[IrfanClemson]

No luck. Changing from http to https actually returns an error like Invalid response from the server while acting as Reverse Proxy. 

It would be nice if your setup is detailed in a documentation:

1) Where to set the Web Context URL (mine was set at the Portal Admin page; just tried at ArcGIS Server admin page but not luck).

2) SSL certificate(s) on be installed on the internal machine's IIS (or elsewhere as well?)

3) URL Re-write Rules, Server Farm setting.

Being so close and yet so far for me.

Or maybe resetting the environment is needed on my end!

Thanks

[JonathanQuinn]

I think we'd rely on the vendor of the load balancer to provide necessary documentation on configuring it before we put it in our documentation as they are more familiar with how to configure their own products. If there's something that our software expects, (for example, setting the Web Context URL for Portal and Server or what headers should be included in any request), then we do our best to document those steps or information. In response to your numbered points:

1) I set the WebContextURL in the Portal and Server's Administrator Directory (from the links above):

   Portal

Server

It isn't always necessary to set the privatePortalURL for Portal. You'd only use it if you are setting up an HA Portal or Server can't communicate directly with the Portal over 7443.

2) SSL Certificates likely won't cause a redirect. They have to be installed on any IIS instance which includes the reverse proxy and the IIS instance hosting the web adaptors. They are certificates from our domain signing authority. Even if they were self-signed certificates, they shouldn't cause redirects, only certificate warnings. I'm not sure of the behavior if the reverse proxy machine doesn't trust the certificate that is used for the Web Adaptor machine, so that's definitely something to look into. This can be checked by navigating to the Portal or Server through the Web Adaptor URL.

3) Again, I would refer to the vendors documentation on URL Rewrite rules and Server Farm configurations as it's technically a third party component and not directly supportable. There are a number of blogs on the URL Rewrite module:

URL Rewrite : The Official Microsoft IIS Site 

Setting HTTP request headers and IIS server variables | Microsoft Docs 

Modifying HTTP Response Headers | Microsoft Docs 

The documentation on the Windows site will be far more detailed and will likely be kept up to date more accurately than information we transpose to our documentation.

If it turns out there was a setting or configuration that was necessary to make things work in your environment, then we can consider adding that as a general note, but not include within a larger step by step guide.

In my configuration, I didn't make any changes other than adding the machine to a new Server Farm. I left everything else default.

[IrfanClemson]

Thank you.

[IrfanTak]

My issue is resolved now! Kind of own it's own. Here's what happened: I had to reformat the host system (the one which has the Reverse Proxy setup) to start fresh. The VM containing the GIS system (Portal) was not touched. In the Reverse Proxy's IIS, installed the ARR 3 module, which also installed the URL Rewrite module. Re-installed the SSL Certificate on the IIS (I had the .pfx file). Created a Server Farm to point to the internal GIS system. Created two URL Rewrite Rules with httpS schemas: One with 'portal*' and one with 'server*' as Wild Cards and redirected these rules to the Server Farm. That's it!

In the GIS system, I already had two Web Adapters installed with 'portal' and 'server' as their names. Also, in the GIS system, the IIS had imported (.pfx file) the same SSL certificate which was installed in the Reverse Proxy server; not sure if it mattered or not.

So everything works like a charm now! I just wonder what had caused the issue and why reformatting the host system did the job. There was something wrong in the host system for sure, as I had indicated above, the Reverse Proxy rules would not work at all had there not be the http schemas directed to the Server Farm. 

Hope this helps someone!!

Thank you all, especially Jonathan for the help.

[JonathanQuinn]

Sounds like the one thing that changed was the certificate was imported into the machine hosting the web adaptors? What kind of certificate were you using? Wildcard from your domain signing authority, CA signed certificate from a well-known provider, (Digicert, Verisign, etc)?

[IrfanTak]

The SSL request was issued by the RP (host) machine's IIS, and the CSR file was sent to Comodo as the SSL issuer authority. The file sent by them was used to install using the standard procedure in Windows/IIS on the RP machine. It was not a wild-card certificate. After that, I did export to .PFX format so that I could install in the IIS of the guest (GIS) machine--not sure if needed or not. After the reformat of the host, instead of buying another one, I created another CSR file but simply Completed that request by importing the .PFX certificate which was backed up.

The host machine's IIS would show the Certificate as okay in the browser--it's only the Signup.html page which was causing the problem. Anyway, I think there was something wrong in the host system itself.

[FraserHand1]

Hi Jonathan Quinn‌ - I'm getting this on a new deployment of Cloud Builder 10.7.1 - only change I made was deploying a Lets Encrypt cert via Encrypt the Web - which shouldn't cause this - I'm just not seeing where the redirect is happening - only 2 rules in IIS are redirects, and when I disable them the redirect still happens - which looks like its portal doing it? Any thoughts?

Thanks

Fraser

[IrfanTak]

An interesting thing I just noticed is that inside the protected GIS machine, there's no such Redirect issue. So the internal machine is still finding the external domain of gis.mydomain.com/portal routed to the RP server and then to the signin.html page without any issues. I think this is an SSL Certificate issue: The same CA authority given Certificate is installed in both the RP server and the GIS machine. Inside the GIS machine itself, the browser is, somehow, able to trust the Cert installed on the IIS (on both the Portal and ArcGIS Server Web Adaptors); the response the browser gets is 304 (and not 302).

Should I also install the CA Certificate also using the ArcGIS Server and Portal Admin pages? If so how? 

Hmmm.

[pfoppe]

I recently had this same issue with Microsoft Application Request Routing (ARR) and think I found my resolution.  Same behaviors noted: 

1. Accessing the web-site was generally functional
2. Navigating to the sign-on page ended up in a never ending redirect loop.  

In my situation, my routing looks roughly like: client request -> firewall (content inspection) -> IIS Server (ARR) -> IIS Server (web-adaptor) -> Portal

The IIS Server (ARR) in the middle is really not needed in this situation and the firewall could route traffic directly to my IIS Server (web-adaptor), but my firewall admin resources were tied up so I had to get a little creative.  

On the ARR rule, I had setup a server farm (for the back-end IIS/Web-adaptor server).  And my ARR rule was setup to route traffic to the HTTP (port 80) endpoint of the web-adaptor.  I think what is happening is that: 

1. Client connects to firewall on HTTPS/443 (traffic is terminated, and re-issued)
2. IIS/ARR server receives the request from the firewall on HTTPS-443
3. IIS/ARR server routes request to backend IIS/Web-adaptor server on HTTP/80
4. Esri SW re-directs the sign-on page to HTTPS/443 (since it received it from ARR on HTTP/80).  
5. Client receives re-direct and starts over at step 1... ending up in a never ending loop with too many re-directs

On the ARR rule, I switched to route to the server farm on HTTPS/443, but that immediatly failed because the back-end SSL certificate on the IIS/web-adatpor server was self-signed.  Once I added a valid certicate to the back-end IIS/web-adaptor server, everything worked!

I can re-create this situation by setting the ARR rule to route on HTTP (port 80).  

So key take-aways:

1. Setup ARR rule to route on HTTPS (port 443)
2. Provide a valid SSL certificate to the back-end web-adaptor server

Hope this helps