Why is administering Server with Web Adaptor not recommended, but is often the only option?

2829
3
08-03-2017 05:18 PM
TabithaFraser
New Contributor II

I've installed several web adaptors now, and I keep running into this paradox:

1) When you install the web adaptor, the help documentation states "By default, administration of the site through ArcGIS Web Adaptor is disabled. This is the recommend...." I am assuming that's because of some sort of security risk, like the one described here?

2) However, if you want to make your services publishable through the web adaptor, as far as I know the only way to do that is to enable administration of the site through the web adaptor. In fact there's a help document that recommends you disable access through port 6080 and only use the web adaptor URL: Disabling administrative access to ArcGIS Server on port 6080—ArcGIS Server Administration (Windows)... 

So my question is, what actually is the best practice for server administration through web adaptor? Does anyone have any insights on this? Does it depend on your server setup? If both methods have security risks, which is the least problematic?

In our case, we have services that need to be kept inside the network, and services that need to be fully accessible for the public.

0 Kudos
3 Replies
MatthewLofgren
Occasional Contributor

I think if you are using HTTPS, administration through web adapter is fine. If you allow HTTP (and probably a lot of folks do) and you log into server manager using HTTP, your admin credentials are sent in clear text which would allow anyone, that cared enough, to get them.

I think they recommend disabling admin access through port 6080 when you are using web-tier auth. In which case you would have to authenticate at the web-tier (which is only done at the web adaptor). The only user that could authenticate through :6080 would be the primary site admin account. Web tier auth pretty much requires HTTPS unless you are behind a firewall.

0 Kudos
RebeccaStrauch__GISP
MVP Esteemed Contributor

If you haven't seen this already Server Implementation Guidance—Trust ArcGIS | ArcGIS if is worth a look.

What I've been told is it is best to disable the admin thru the web adaptor, i.e.  http://<URL>/webadaptor/admin/login   (or the https version of it), but that it is alright to use the machinename:port  http://<machinename>:6080/arcgis/admin/login  or https://<machinename>:6443/arcgis/admin/login  since this is typically within the firewall.

That does not mean that you can not connect as ad administrator thru the web adaptor using ArcCatalog or ArcMap, and is sometimes needed for certain tasks.

0 Kudos
RandallWilliams
Esri Regular Contributor

I think I see the confusion here. Matthew above is correct.

You mention the DOC here:

http://server.arcgis.com/en/server/latest/administer/windows/disabling-administrative-access-to-arcg...

This workflow would only apply if you're leveraging Windows users and roles and Web tier authentication.

Assume:

a. The Primary Site Admin (PSA) credentials are kept under clock and key,

b. Web tier authentication is used

When using web tier auth and when the PSA account credentials are not shared amongst users, then only members in the enterprise user and role store who are themselves members of an ArcGIS Server ADMIN role can administer the GIS Server.

If admin access via the web adaptor is disabled, only the PSA can admin the server - which we're assuming nobody has these credentials. So...you'd HAVE to allow users to admin the machine through the web adaptor - otherwise users wouldn't be able to authenticate correctly.

If my GIS Server is publicly accessible, I don't like using windows users and roles and web tier authentication. I'd disable admin access via the web adaptor and enable internally at the GIS tier.

In ANY condition, as is alluded to earlier, administrative access should be via HTTPS - if via the GIS tier that's port 6443. In general and in any web site/application, it's preferable that any information passed through a form use HTTPS. Otherwise, it's very easy for a man in the middle to intercept whatever data is passed - including user credentials.

0 Kudos