Login link fails when accessed from web adaptor

[CoryDavis]

My client has ArcGIS Portal and Server running behind their firewall and both web adaptors running on a DMZ server. There are secured feature services I need to access, but cannot reach because the login link doesn't work from the web adaptor. When clicked, it takes the user to a blank page and sits there. It doesn't time out or display an error. Unsecured resources are still accessible.

I've only noticed this behavior when using the web adaptor URL; I can still log in directly to the Portal instance.

I suspect either something went wrong when the web adaptor was configured or the firewall isn't configured correctly. I need help narrowing down the cause of the failure before I recommend any actions to my client's IT team, so any help would be greatly appreciated.

[RachelSears]

Hi Cory,

What type of authentication is configured with your web adaptor? Are you using built-in authentication or is it configured with an authentication provider such as IWA?

Also, is your Server allowing administrative access through the web adaptor? You can check this in ArcGIS Server Manager > Site > Web Adaptor.

If I am understanding your post correctly, you have two web adaptors? If they are both running through the same port/site, they will need to have different names in order to work properly. 

Also, if you recently upgraded to a different version of Enterprise, you will need to uninstall the old web adaptor to install the new version.

Hope this helps!

[CoryDavis]

Rachel,

The Portal is federated with IWA. Yes, there are separate web adaptors for Portal and Server running on the DMZ server, but they are configured to ports 7080 and 6080, respectively on the application server.

I can confirm that the new Enterprise deployment was installed on a brand new server, so there was no previous one to uninstall.

I currently don't have permission to access server manager, so I'll update you when I know if administrative access is granted through the web adaptor. Can you let me know what it would mean if it is not enabled in relation to the login link not working? It would help if I could explain why I need permission to check that setting.

Thanks a lot!

[RachelSears]

Hi Cory,

Based on those port numbers, does this mean that your site is configured to use HTTP Only? If you are running the Portal Web Adaptor using non-default ports (80 and 443 are the defaults), you will need to maintain HTTPS communication and use an HTTPS port. See: Use nondefault ports for the portal's ArcGIS Web Adaptor—Portal for ArcGIS (10.7 and 10.7.1) | ArcGI... 

I am also assuming that the required ports are allowed access through the firewall and aren't in use by other applications?

Best,

Rachel

[CoryDavis]

Rachel,

External applications hit the web adaptors using default ports 80 and 443. The web adaptors are pointing at ports 6080 and 7080 on the server behind the firewall where the instances of ArcGIS Server and Portal are running. The Enterprise deployment was installed using the wizard and I believe all the default settings were selected.

I'm putting in a request with my client's IT desk to confirm those ports are allowed through the firewall. They already responded to a ticket to open ports 80 and 443 on the DMZ server and 6080, 6443, 7080 and 7443 on the application server, but I will double-check.

Do you know why I am still able to access the unsecured services? If the firewall is blocking traffic, shouldn't all the services be unavailable?

[RachelSears]

Hi Cory,

Have you opened developer tools (Ctrl-shift-i in Chrome) during the behavior to see if anything shows up in the network tab or console? This might give us some more insight into what may be happening. Testing in different browsers may also help.

Also, what kind of certificate is bound to your site? You may need to import it as a trusted certificate in your Internet Options if not using a CA-signed certificate.

Best,

Rachel

[Travis_Esri]

Hello,

I believe the issue here may be related to the IWA configuration. Remember that the DMZ is a separate location/domain and has very limited functionality and high security (as it is accessible to the public). It is likely that your DMZ web server does not have access to your active directory, which is likely only internal. With IWA, the authentication is taking place at the web-tier level (in IIS), not the Portal-level. With IWA, your web server is doing this authentication referencing active directory. Should active directory not be accessible to the web server on the DMZ (which is how most environments are), your IWA logins are not going to work. I would suggest looking into alternative login methods such as SAML-logins. This is probably also a limitation of IIS being able to authenticate across different domains. This is why most internal-only environments utilize IWA as it is not designed for external access.

Thanks,

Travis

[CoryDavis]

Thank you. I also believe the security configuration is the cause of failure. I just made the suggestion to implement SAML to my client.