search

Esri / arcgis-powershell-dsc

This repository contains scripts, code and samples for automating the install and configuration of ArcGIS (Enterprise and Desktop) using Microsoft Windows PowerShell DSC (Desired State Configuration).
Apache License 2.0
121 stars 62 forks source link

Current DSC-config produces a security-recommendation with the Server Scan-tool #297

Closed scma-esrich closed 3 years ago

scma-esrich commented 4 years ago

Community Note

Module Version

Affected Resource(s)

Most likely:

Potentially other modules are also affected.

Configuration Files

# Copy-paste your DSC JSON configurations here - for large configs,
# please use a service like Dropbox and share a link to the ZIP file.

Relevant parameters:

"AllNodes": [{ "NodeName": "servermachine1234", "Role": ["Server"], "SslCertificates": [{ "CNameFQDN": "servermachine1234.internal.domain", "Password": "***", "Path": "\\fileshare\arcgis\servermachine1234.pfx", "Target": ["Server"] } ] }, ...

"ConfigData": {
... "Server": {
"ExternalLoadBalancer": "www.gisplatform.com", "InternalLoadBalancer": "servermachine1234.internal.domain" }, ... }

It's a multi-tier setup, where Web Adaptor is on another machine than Server and Portal. The Web Adaptor-host is used as a "Push"-host and the one where the deployment is started from. I initially tried to use fully qualified hostnames (i.e. "servermachine1234.internal.domain") in the "AllNodes"-section, but WinRM was not able to connect to the other hosts this way.

So I had to fall back to non-fully qualified Node-names in the "AllNodes"-section (i.e. "servermachine1234"). To compensate for this, I had to set the "InternalLoadBalancer"-parameter to the fully qualified internal hostname of the server-machine (i.e. "servermachine1234.internal.domain") due to some other issues that came up, when not setting it. I can't remember exactly, what these problems were. I think it had to do with the "privateHostingServerUrl" of the Server Security-section and/or the "Admin Url" of Portal's Server Federation-section.

Expected Behavior

One Web Adaptor should have been registered. Two with respect to your answer from https://github.com/Esri/arcgis-powershell-dsc/issues/260.

Actual Behavior

Three Web Adaptors have been registered. These are:

Is this due to my use of the "InternalLoadBalancer"-value (misleading parameter-name in my opinion) to set the fully qualified hostname of the server-machine in combination with using the "ExternalLoadBalancer"-value for the reverse proxy? Most likely at least line 90 within "ArcGIS_ServerSettings.psm1" is involved when the WA-URL is incorrectly set to the WA-hostname in combination with port 6443.

So far, I have not seen any functional issues yet. I stumbled across this issue due to the Server Scan-tool throwing an issue-type "SS10" due to the registration of the Web Adaptor with the HTTP port set.

I am worried though, that the WA-URL is at least once pointing to the WA-host but to port 6443, where nothing is running and awaiting requests. Any info is appreciated.

Steps to Reproduce

Create a JSON-config for a multi-tier setup - WA-host separated from Server - with the Node-names in the "AllNodes"-section set to non-fully qualified hostnames. Then set the "InternalLoadBalancer"-parameter for server to the fully qualified Node-name of the Server-machine and the "ExternalLoadBalancer"-parameter to an existing Reverse Proxy.

Important Factoids

References

cameronkroeker commented 4 years ago

Hi @scma-esrich ,

In regards to "I initially tried to use fully qualified hostnames (i.e. "servermachine1234.internal.domain") in the "AllNodes"-section, but WinRM was not able to connect to the other hosts this way." For this I recommend adding the fully qualified hostnames to the trusted hosts. For example run the following command in powershell on the orchestrating node and all target nodes:

winrm s winrm/config/client '@{TrustedHosts="servermachine1234.internal.domain,webadaptormachine1234.internal.domain"}'

This should hopefully fix the winrm issue when using fully qualified hostname for "NodeName".

Additionally, I do not recommend using the the "InternalLoadBalancer" parameter for this particular use case. This is meant to use when there is a third party Load Balancer\Reverse Proxy listening on port 6443 which proxies requests to the internal ArcGIS Server Admin url that is also listening on port 6443 (https://internalloadbalancer.domain.com:6443/arcgis -> https://servermachine1234.internal.domain:6443/arcgis).

Thanks, Cameron K.

scma-esrich commented 4 years ago

Thanks for the quick reply! 

winrm s winrm/config/client '@{TrustedHosts="servermachine1234.internal.domain,webadaptormachine1234.internal.domain"}'

This should hopefully fix the winrm issue when using fully qualified hostname for "NodeName". I forgot to mention that this is part of my standard-procedure when working with the DSC-module. All hosts have been added to the TrustedHosts-lists (fully qualified) but I still wasn't able to connect via WinRM, when using the fully qualified node-names in the AllNodes-section. It only worked when adding the non-fully qualified nodes in the AllNodes-section of the config-JSON.

To my knowledge, the "InternalLoadBalancer" is used as the Admin-URL during the federation-process, right? If so, at least at this point of the deployment the fully qualified hostname of the server-machine should be used in my opinion.

How can you reach such a state without using the "InternalLoadBalancer"-parameter, when fully qualified node-names are not supported by WinRM, although all fully qualified node-names are added to the "TrustedHosts"-list on each of the participating machines? Do you know of any WinRM-setting/GPO that allows the use of fully qualified hostnames in the "AllNode"-section? I know of several customer environments where this works without any problem, but I also had several others, where it didn't.

In addition: For Portal we also frequently use the "InternalLoadBalancer"-parameter due to issues with IWA, if we don't. More exactly, the Hosting Server uses the ExternalLoadBalancer-URL of Portal (if this parameter is set) as its privatePortalUrl-value. This renders Portal inaccessible for Server, if IWA on the Web Adaptor-level is configured.

Thanks for any hints!

scma-esrich commented 4 years ago

@nme-esridech, FYI.

cameronkroeker commented 4 years ago

Thanks @scma-esrich for the reply. Yes you're correct, if the Server InternalLoadBalancer parameter is present it will be used for the federated AdminURL. And my apologies as I am not aware of which WinRM-setting/GPO that allows the use of fully qualified hostnames in the "AllNode"-section. It is odd that is works for some and not for others.

I tried following your recommended steps but instead of v3.1.0, I used v3.1.1 and for me it only registered two:

Dummy Web Adaptor

{
  "machineName": "agsserver.domain.com",
  "machineIP": "",
  "webAdaptorURL": "https://agsserver.domain.com:6443/arcgis",
  "id": "16df1e42-3cb1-4ed3-90db-ebc233d08a6b",
  "description": "",
  "httpPort": 6080,
  "httpsPort": 6443,
  "refreshServerListInterval": 1,
  "reconnectServerOnFailureInterval": 1,
  "isAdminEnabled": true,
  "allowedOrigins": "*"
}

Actual Web Adaptor:

{
  "machineName": "webadaptorMachine",
  "machineIP": "10.0.0.1",
  "webAdaptorURL": "https://webadaptorMachine.domain.com/server",
  "id": "041da6b3-3b21-42a2-8ba5-5f2d4ba7cb5c",
  "description": "",
  "httpPort": -1,
  "httpsPort": 443,
  "refreshServerListInterval": 1,
  "reconnectServerOnFailureInterval": 1,
  "isAdminEnabled": true,
  "allowedOrigins": "*"
}

Could you also try with v3.1.1? If issue persists perhaps could you attach the full json file (feel free to scrub out any sensitive information). If at all possible the DSC logs may help as well (I understand if they can't be sent as it is a bit more a challenge scrubbing out sensitive info from them).

Thanks, Cameron K.

scma-esrich commented 4 years ago

@cameronkroeker thanks for your tests.

If everything goes according to plan, the customer will deploy the next stage next week. He will use the module-version 3.1.1 for that and I will give you an update on this issue as soon as I get the info from the customer if this changed the behavior.

cameronkroeker commented 3 years ago

Hi @scma-esrich,

Due to this issue going a bit stale, I am going to close it for now. However, if the issue persists, if possible let's try with v3.2.0:

https://github.com/Esri/arcgis-powershell-dsc/releases/tag/v3.2.0

Feel free to re-open attach fresh logs, json config file, and description and we will be glad to help investigate.

Thanks, Cameron K.