Unable to log into ArcGIS Server Manager after Federating

LucasScharenbroich · ‎06-02-2017

I have federated Portal 10.5 with a single-machine ArcGIS Server 10.5 site. Portal is configured to use Active Directory for its Identity Store. Portal and ArcGIS Server are on different virtual servers and their respective web adaptors are on a separate Web Server and configured under different IIS sites. I have done ArcGIS Enterprise Basic deployment in the past successfully.

This table summarized the configuration

URL	Description
https://ags-web-dev.mydomain.org/server	Web Adaptor pointing to the ArcGIS Server
https://ags-web.mydomain.org/portal	Web Adaptor pointing to the Portal for ArcGIS Site
https://ags-dev.mydomain.org:6443/arcgis	Direct URL to the ArcGIS Server machine
https://ags-portal.mydomain.org:7443/arcgis	Direct URL to the Portal for ArcGIS

Almost everything appears to work correctly. For example

I can log into Portal using the primary site administrator account
I can log into Portal using my Domain account
After Federating, all of the ArcGIS Server services appeared as Portal items, as expected
I can log into the ArcGIS Server Administrative service directory using the ArcGIS Server site administrator credentials, or by manually generating a Portal token.

The only issue if that attempting to open ArcGIS Server Manager fail. The interface hangs on the "Please wait..." progress bar and the network traffic shows repeated failures to POST to the portal generateToken page via the ArcGIS Server proxy

https://ags-dev.mydomain.org:6443/arcgis/manager/proxy?_proxyUrl=https%3A%2F%2Fags-web.mydomain.org%...

The network inspector shows that ArcGIS Server returned a 500 server error caused by a "Connection closed" (see screenshot).

Are there any good ways to go about diagnosing the root cause of an issue like this?

Update

Installing Fiddler and enabling HTTPS traffic snooping shows that request is being sent from the ArcGIS Server machine to the Portal Web Adaptor.

This may be a side-effect of enabling Fiddler as a MITM proxy, but the Portal logs show this WARNING:

ArcGIS Server services URL 'https://ags-web-dev.mydomain.org/server' cannot be validated against 'https://ags-web-dev.mydomain.org/server/rest/info'. If the service URL is a proxy URL verify it is accessible to clients.

The JSON at the /info endpoint is

{  "currentVersion": 10.5,  "fullVersion": "10.5.0",  "soapUrl": "https://ags-web-dev.mydomain.org/server/services",  "secureSoapUrl": null,  "owningSystemUrl": "https://ags-web.mydomain.org/portal",  "authInfo": {   "isTokenBasedSecurity": true,   "tokenServicesUrl": "https://ags-web.mydomain.org/portal/sharing/generateToken"  } }

What information is being used to attempt this 'validation'?

LucasScharenbroich · ‎06-13-2017

A workaround!

The actual issue appears to be a lack of support for SNI in the ArcGIS Server proxy. Our web server was set up with multiple sites, each bound to a FQDN. On a hunch, I added a default HTTPS binding to the site that contains the Portal Web Adaptor and things began working.

At one point I did have a default binding on the site in order to configure the Web Adaptor (so I could use https://localhost/ to get at the configuration page), which is why it worked for a while and then "stopped". At the time, I didn't associate removing the default binding with the loading failures.

There is an Esri BUG-000093827 that discusses an issue with the Portal proxy and SNI support that was fixed in 10.4.1, but nothing I could find that discussed the state of SNI support in the ArcGIS Server proxy.

I'm hoping to get a resolution from Esri support that either

Confirms this as a bug in the AGS proxy, or
Provides some details on how to enable SNI support

For now, moving on from this issue....

TLS Extension List sent from ArcGIS Server

extensions [extension_type: elliptic_curves,extension_type: ec_point_formats,extension_type: signature_algorithms]

TLS Extension List sent from Chrome Browser

extensions [extension_type: 31354,extension_type: renegotiation_info,extension_type: server_name,extension_type: extended_master_secret,extension_type: SessionTicket_TLS,extension_type: signature_algorithms,extension_type: status_request,extension_type: 18,extension_type: application_layer_protocol_negotiation,extension_type: 30032,extension_type: ec_point_formats,extension_type: elliptic_curves,extension_type: 10794]

RandallWilliams · ‎06-13-2017

OK, yes. That makes sense.

There's a second issue that's fixed in 10.5 - [#BUG-000099854 A proxy call within Portal for ArcGIS does not support Server Name Indication (SNI): GET /arcgis/sharing/proxy?https://server.domain.com/arcgis/rest/services/Hosted/MyService/FeatureServer/0?f=json }

MatthiasFries · ‎10-18-2017

Thanks for this workaround! I had the same issue but never thought that the default https binding could be the cause. I tried many things and contacted support without success, we have a similar setup with multiple sites each bound to a FQDN. Editing the default https binding with an EV SSL certificate solved this issue.

RobertDriessen2 · ‎11-23-2017

Hi Lucas

Thank you for your post. Its the only thing I have found that comes close to solving my problem.

I am getting the exact same problem of not being able to access server manager after federation. I even get a log message which includes "If the service URL is a proxy URL verify it is accessible to clients".

I am having a frustrating time trying to solve this. Have you had a response from ESRI regarding your 2 points? We have two portals joined together in primary/secondary failover mode. Web adapters are on both servers but arcgis is the only site on these servers (so I assume that would make it default anyway). However we do have a f5 load balancer which directs traffic to the primary server if it is up or the secondary server if it is down. I am trying to work out if you fix applies to the load balancer or the servers with the web adapters?

Thanks again, Rob

JonathanQuinn · ‎11-28-2017

I don't have an answer for the SNI problem, but just wanted to chime in and mention it's unnecessary to only send traffic to the primary server. The Web Adaptors are aware of the health of the portal machines and will balance requests to each machine.

LucasScharenbroich · ‎12-11-2017

Rob,

Esri support did confirm the lack of SNI support in the ArcGIS Server proxy and filed BUG-000106097. It is listed as fixed in 10.6.

BUG-000106097: A proxy call within ArcGIS GIS Server does not suppo..

CarolSousa · ‎06-05-2017

I have seen the "Please wait..." message hang, too. I believe it to be an issue with the browser. Do you get the "Not secure" message at the top of your browser? I'm using Chrome, and sometimes when I get that message I get the "Your connection is not private" message, then I go on to 'Advanced' and 'Proceed', then I get to Server Manager. When the browser hangs at "Please wait", I think it is due to that error message, except that it isn't presented to me to proceed around it. If I go back or refresh I'll usually get the privacy error, then I can move on.

JonathanQuinn · ‎06-05-2017

If you're using the default self-signed certificate on 6443, that is actually related to Chrome losing the exception you've made for the self signed certificate. What happens is the following:

1) You try to reach Manager over 6443. Chrome sees that this is a self-signed certificate so you're asked if you want to proceed or not. You select Proceed.

2) Since you're trying to reach a federated Server, you're redirected to the Portal sign in page. This is where the initial exception for the self signed certificate is lost.

3) Once provide your credentials, you're redirected back to Server Manager. Since the initial exception has been lost, and for whatever reason Chrome doesn't prompt you to proceed again, the rest of the requests to Server Manager don't go through. You should see INSECURE_RESPONSE errors or something similar in the dev tools in Chrome.

This is reproducible outside of Server Manager and Portal as well. IE and Firefox don't have this problem.

CarolSousa · ‎06-05-2017

I've got domain certificates on all the Enterprise machines. But I should use IE or Firefox. Thanks!

LucasScharenbroich · ‎06-05-2017

I have seen the behavior you describe caused by self-signed or incorrect SSL certificate, however in this case we do have proper certificates installed on both the ArcGIS Server, Portal and Web Adaptors in IIS.

I have added a screenshot of the browser when connected to the Manager page with the SSL credentials shown. Please let me know if you see anything amiss in this settings.

The issue seems to be pretty clearly caused by a network connection being terminated when the ArcGIS Server proxy page attempts to connect to the Portal generateToken page via the Portal Web Adaptor. This behavior is confirmed by the ArcGIS Server error page that was captured from the Web Server network inspector, and by monitoring the traffic between the ArcGIS Server and Web Adaptors via Fiddler.

I am waiting on IT to grant remote login privileges to the ArcGIS Server domain account in order to test Johnathan Quinn's suggestion of verifying that the ArcGIS Server process identity is not being blocked due to external policy considerations.