locked
LWGW installation attempt "Failed to register Gateway" RRS feed

  • Question

  • Dear all,

    we needed to reinstall one LWGW 1.9.7321.32791 to one of our DCs on a Hyper-V with connection to the Center 1.9.7321.32791. Both servers are running Win 2012R2 at current patch level and have .NET 4.7.03062 installed.

    So far we failed to install the LWGW with "Failed to Register" in the "Configure the Gateway" tab of the installer although:

    • Any previous installion has been removed, no residuum is in the Center's configuration
    • Proxy is disabled
    • The Centers' FQDN is in the list of Trusted Sites in the IE Settings
    • The install user is member of the "Microsoft Advanced Threat Analytics Administrators" group
    • We temporarily disabled the Windows Firewall and no IPS or similar is installed in the network path from the LWGW to the Center
    • TLS 1.2 was enabled on all via [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
      [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
      [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] " SchUseStrongCrypto"=dword:00000001
      and netmon 3.4 has shown that the LWGW and the Center communicate properly.
    • The are no keys on any of the servers like that:
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
      "DisableRenegoOnServer"=dword:00000001
      "DisableRenegoOnClient"=dword:00000001
    • The Center's certificate is an official one and the certificate chain is installed and valid. The LWGW json file shows the right thumbprint.
    • The query "Get-WmiObject -Namespace root\standardcimv2 -class “MSFT_NetEventSession” | Select Name" yields "Microsoft-ATA-NDISCAP-LiveCapture"

    The installation log reads:

    [1044:1030][2019-03-25T16:29:32]i001: Burn v3.11.0.1701, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\XXX\AppData\Local\Temp\{1A640771-0AD3-4FB6-92B2-3FB1D423B2C3}\.cr\Microsoft ATA Gateway Setup.exe
    [1044:1030][2019-03-25T16:29:32]i000: Initializing string variable 'InstallationConfigurationFilePath' to value '[WixBundleOriginalSourceFolder]\GatewayInstallationConfiguration.json'
    [1044:1030][2019-03-25T16:29:32]i000: Initializing hidden variable 'ConsoleAccountPassword'
    [1044:1030][2019-03-25T16:29:32]i000: Initializing hidden variable 'ManagementAuthenticationToken'
    [1044:1030][2019-03-25T16:29:32]i000: Initializing string variable 'NetFrameworkCommandLineArguments' to value '/passive /showrmui'
    [1044:1030][2019-03-25T16:29:32]i009: Command Line: '"-burn.clean.room=C:\XXX\Microsoft ATA Gateway Setup.exe" -burn.filehandle.attached=308 -burn.filehandle.self=316'
    [1044:1030][2019-03-25T16:29:32]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\XXX\Microsoft ATA Gateway Setup.exe'
    [1044:1030][2019-03-25T16:29:32]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\XXX\'
    [1044:1030][2019-03-25T16:29:32]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\XXX\AppData\Local\Temp\Microsoft Advanced Threat Analytics Gateway_20190325162932.log'
    [1044:1030][2019-03-25T16:29:32]i000: Setting string variable 'WixBundleName' to value 'Microsoft Advanced Threat Analytics Gateway'
    [1044:1030][2019-03-25T16:29:32]i000: Setting string variable 'WixBundleManufacturer' to value 'Microsoft Corporation'
    [1044:1030][2019-03-25T16:29:32]i000: Loading managed bootstrapper application.
    [1044:1030][2019-03-25T16:29:33]i000: Creating BA thread to run asynchronously.
    [1044:1030][2019-03-25T16:29:33]i100: Detect begin, 7 packages
    [1044:1030][2019-03-25T16:29:33]i000: 2019-03-25 15:29:33.5343 4164 1   Debug [\[]DeploymentModel[\]] DetectBegin [\[]Installed=False[\]]
    [1044:1030][2019-03-25T16:29:33]i000: Setting string variable 'NetFrameworkRegistryValue' to value '461814'
    [1044:1030][2019-03-25T16:29:33]i000: Setting string variable 'ServerLevelsServerCoreRegistryValue' to value '1'
    [1044:1030][2019-03-25T16:29:33]i000: Setting string variable 'ServerLevelsServerGuiShellRegistryValue' to value '1'
    [1044:1030][2019-03-25T16:29:33]i000: Registry key not found. Key = 'SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_for_KB3047154_RTM~31bf3856ad364e35~amd64~~6.3.2.0'
    [1044:1030][2019-03-25T16:29:33]i000: Setting numeric variable 'KB3047154Exists' to value 0
    [1044:1030][2019-03-25T16:29:33]i052: Condition 'NetFrameworkRegistryValue >= 394254' evaluates to true.
    [1044:1030][2019-03-25T16:29:33]i052: Condition 'NetFrameworkRegistryValue >= 394254' evaluates to true.
    [1044:1030][2019-03-25T16:29:33]i052: Condition 'KB3047154Exists' evaluates to false.
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: NetFrameworkPackageServer, state: Present, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: NetFrameworkPackageServerCore, state: Present, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: KB3047154Package, state: Absent, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: VcRedistributable2013Package, state: Absent, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: PefNdisDriver, state: Absent, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: BundleActionsPackage, state: Absent, cached: None
    [1044:1030][2019-03-25T16:29:33]i101: Detected package: MsiPackage, state: Absent, cached: None
    [1044:1030][2019-03-25T16:29:33]i199: Detect complete, result: 0x0
    [1044:13BC][2019-03-25T16:29:33]i000: 2019-03-25 15:29:33.5655 4164 5   Debug [\[]DeploymentModel[\]] [\[]DeploymentAction=Install[\]]
    [1044:13BC][2019-03-25T16:29:33]i000: 2019-03-25 15:29:33.7685 4164 5   Debug [\[]DeploymentModel[\]] [\[]IsAfterRestartAndConfigured=False[\]]
    [1044:13BC][2019-03-25T16:31:53]i000: 2019-03-25 15:31:53.3144 4164 5   Error [\[]TaskAwaiter[\]] System.Threading.Tasks.TaskCanceledException: A task was canceled.
       at async Microsoft.Tri.Infrastructure.Extensions.HttpClientExtension.GetAsync[\[][\]](?)
       at async Microsoft.Tri.Common.Management.ManagementClient.<>c__DisplayClass9_0.<GetStatusAsync>b__0(?)
       at async Microsoft.Tri.Infrastructure.Extensions.HttpClientExtension.RequestAsync[\[][\]](?)
       at async Microsoft.Tri.Common.Management.ManagementClient.GetStatusAsync(?)
    [1044:13BC][2019-03-25T16:31:53]i000: 2019-03-25 15:31:53.3184 4164 5   Error [\[]DeploymentModel[\]] Failed management authentication [\[]CurrentlyLoggedOnUser=YYY\XXXStatus=Failed Exception=System.Threading.Tasks.TaskCanceledException: A task was canceled.
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.Tri.Infrastructure.Extensions.HttpClientExtension.<GetAsync>d__0`1.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.Tri.Common.Management.ManagementClient.<>c__DisplayClass9_0.<<GetStatusAsync>b__0>d.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.Tri.Infrastructure.Extensions.HttpClientExtension.<RequestAsync>d__4`1.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.Tri.Common.Management.ManagementClient.<GetStatusAsync>d__9.MoveNext()[\]]
    [1044:13BC][2019-03-25T16:33:12]i000: 2019-03-25 15:33:12.7668 4164 5   Debug [\[]GatewayBootstrapperApplication[\]] Engine.Quit [\[]deploymentResultStatus=1602 isRestartRequired=False[\]]
    [1044:1030][2019-03-25T16:33:12]i500: Shutting down, exit code: 0x642
    [1044:1030][2019-03-25T16:33:12]i410: Variable: InstallationConfigurationFilePath = C:\XXX\\GatewayInstallationConfiguration.json
    [1044:1030][2019-03-25T16:33:12]i410: Variable: KB3047154Exists = 0
    [1044:1030][2019-03-25T16:33:12]i410: Variable: NetFrameworkCommandLineArguments = /passive /showrmui
    [1044:1030][2019-03-25T16:33:12]i410: Variable: NetFrameworkRegistryValue = 461814
    [1044:1030][2019-03-25T16:33:12]i410: Variable: ServerLevelsServerCoreRegistryValue = 1
    [1044:1030][2019-03-25T16:33:12]i410: Variable: ServerLevelsServerGuiShellRegistryValue = 1
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleAction = 5
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleElevated = 1
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleLog = C:\Users\XXX\AppData\Local\Temp\Microsoft Advanced Threat Analytics Gateway_20190325162932.log
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleManufacturer = Microsoft Corporation
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleName = Microsoft Advanced Threat Analytics Gateway
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleOriginalSource = C:\XXX\Microsoft ATA Gateway Setup.exe
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleOriginalSourceFolder = C:\XXX\
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleProviderKey = {7409b4bb-004f-4f5d-a9d0-fa07360655b4}
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleSourceProcessFolder = C:\XXX\
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleSourceProcessPath = C:\XXX\Microsoft ATA Gateway Setup.exe
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleTag =
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleUILevel = 4
    [1044:1030][2019-03-25T16:33:12]i410: Variable: WixBundleVersion = 1.9.7312.32791
    [1044:1030][2019-03-25T16:33:12]i007: Exit code: 0x642, restarting: No

    Any help would much be appreciated!

    G.



    • Edited by G47HJKL Monday, March 25, 2019 3:49 PM
    Monday, March 25, 2019 3:47 PM

Answers

  • We got it solved :-)

    The problem was: The Center's certificate is issued by an officially trusted authority, and its certificate chain is installed and shown as valid, and we use a proxy with SSL scanning in our firewall. So far, we switched off the proxy usage on the GW to establish the direct communication to the Center as needed. However, in this way, we unfortunately blocked access to the authority's revocation list. Now, we switched on the proxy usage on the GW but put the Center's FQDN into the IE Proxy Seetings exception list "Do not use proxy server for ...". So, both the Center and the revocation lists are reachable - and both, installation and GW work!

    Please:

    • Check whether you may extend the debug information from your installer accordingly.
    • Feel free to add this to the "Troubleshooting known issues" since I would expect that most of the ATA users have a FW with a proxy running, and some of them now also switch to "official" certificates for the Center once the origininal installation ones become outdated.

    Thanks again for your support!

    G.


    • Edited by G47HJKL Thursday, March 28, 2019 4:36 PM
    • Marked as answer by G47HJKL Thursday, March 28, 2019 4:36 PM
    Thursday, March 28, 2019 4:35 PM

All replies

  • Are you able to browse the console UI from this GW machine?

    Are you using a FRESH package downloaded from the console UI ?

    Monday, March 25, 2019 4:18 PM
  • Yes, I'm able to browse the console UI from the intended LWGW machine, and

    Yes, it is a "fresh" package download - the json file shows all relevant data correctly.

    Monday, March 25, 2019 4:24 PM
  • Eli,

    any more ideas?

    As said before, the install user is member of the "Microsoft Advanced Threat Analytics Administrators" group. Concerning "Failed management authentication [\[]CurrentlyLoggedOnUser=YYY\XXXStatus=Failed Exception=System.Threading.Tasks.TaskCanceledException: A task was canceled." we checked that we also can sign into the console UI with.

    We furthermore ran "dism /online /cleanup-image /restorehealth" without issues.

    Your help will be much appreciated.

    G.

    Tuesday, March 26, 2019 9:20 AM
  • Try to capture a network trace during this authentication. any chance the GW machine and the center are hardened to use a different authentication model which results in a failure?

    For example, one is forced to kerberos and the other NTLM ?

    Is the center machine domain joined?

    Tuesday, March 26, 2019 9:56 AM
  • Concerning authentication models we found:

    • Our ATAcenter is domain joined
    • On the intended GW a GPO enforces
      "Network security: LAN manager authentication level - Send NTLM response only" and
      "Domain member: Digitally encrypt or sign secure channel data (always) - enabled" and
      "Microsoft network server: Digitally sign communications (always) - Enabled" and
      "Microsoft network server: Digitally sign communications (if client agrees) - Enabled" and
      "Domain controller: LDAP server signing requirements - None"
      whereas on the ATAcenter none of these are set. Could that cause a failure?
    • With netmon 3.4 we captured the following exchange. Please advise in case you need further details out of certain packages ...
    Tuesday, March 26, 2019 11:20 AM
  • Tuesday, March 26, 2019 11:31 AM
  • Same GPO is enforced on the Center machine as well?

    I am asking because I had a case where the center had  a mismatched GPO that conflicted, which prevented the authentication from working. 

    Tuesday, March 26, 2019 11:36 AM
  • We thought it is but so far the Center machine appears not to see this GPO ...

    We investigate the issue and come back to you later - please stay tuned :-)

    BTW, thanks for taking care of our problem!

    G.

    Tuesday, March 26, 2019 11:52 AM
  • The Gateway is seeing its configuration from the default domain controllers policy.

    The ATACenter is seeing its configuration from the default domain policy.

    For me it looks that the secure channel is made between the GW and the Center and then somthing fails.

    Regards

    S.

    Tuesday, March 26, 2019 1:44 PM
  • Does the ATACenter have to draw the same MS default domain controllers' GPO's? We didn't find any clues in the MS ATA documentation in this respect, and are hesitant to enfoce this because there might be unintended side effects.

    To us, the above netmon trace appears to have established a communication. But would you have some test tool or powershell script to check authentication from the GW to the Center?


    • Edited by G47HJKL Tuesday, March 26, 2019 3:48 PM
    Tuesday, March 26, 2019 3:23 PM
  • We do not state any requirement that the GPO has to be identical, but if 2 machines (GW -> Center) got to a state where they get authentication settings that collide and break kerberos/ntlm authentication, its a problem, regardless of ATA specifically, and I have seen that happen.

    Not saying that for sure this is the issue here, just that it happened before with similar symptoms.

    on previous cases it was resolved by setting the authentication settings specifically on both machines to match.

    I don't have a PS script that will simulate the exact same thing the registration authentication do... 

    Wednesday, March 27, 2019 10:31 AM
  • We got it solved :-)

    The problem was: The Center's certificate is issued by an officially trusted authority, and its certificate chain is installed and shown as valid, and we use a proxy with SSL scanning in our firewall. So far, we switched off the proxy usage on the GW to establish the direct communication to the Center as needed. However, in this way, we unfortunately blocked access to the authority's revocation list. Now, we switched on the proxy usage on the GW but put the Center's FQDN into the IE Proxy Seetings exception list "Do not use proxy server for ...". So, both the Center and the revocation lists are reachable - and both, installation and GW work!

    Please:

    • Check whether you may extend the debug information from your installer accordingly.
    • Feel free to add this to the "Troubleshooting known issues" since I would expect that most of the ATA users have a FW with a proxy running, and some of them now also switch to "official" certificates for the Center once the origininal installation ones become outdated.

    Thanks again for your support!

    G.


    • Edited by G47HJKL Thursday, March 28, 2019 4:36 PM
    • Marked as answer by G47HJKL Thursday, March 28, 2019 4:36 PM
    Thursday, March 28, 2019 4:35 PM
  • Thanks for sharing!

    We are aware of the proxy issue, but its mostly relevant for AATP, where the sensor contacts the backed in Azure/Internet.

    For most customers, The Center & GW are on the same Intranet, and never heard of a case where there is a proxy between them :-)

    As for additional debug info - What was missing? I am not sure the HTTP API when failing can tell you exactly why it failed ... as in this case there is a man in the middle who messes with the transport, I am not aware of a way to find out what exactly happened, but if you have a specific idea I would be happy to learn.

    Thursday, March 28, 2019 10:34 PM
  • Maybe I didn't describe our setup clearly enough: Our Center and the GWs are on the same Intranet, there is no proxy inbetween them, but we run a proxy at the firewall to the outside world - a setup which is likely quite common! In this, the GW proxy settings must point to the proxy to make the authority's revocation list in the outside world accessible, but the GW must not use the proxy for contacting the Center. We initially followed the ATA "Troubleshooting known issues" at

    System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required The ATA Gateway communication with the ATA Center is being disrupted by a proxy server. Disable the proxy on the ATA Gateway machine.
    Note that proxy settings may be per-account.

    which caused our trouble that an SSL connection is set up partly but then obviously closes since the authority's revocation list in the outside world can't be accessed.

    As for additional debug info: The logfile to date essentially only says "Error [\[]TaskAwaiter[\]] System.Threading.Tasks.TaskCanceledException: A task was canceled." and "Error [\[]DeploymentModel[\]] Failed management authentication [\[]CurrentlyLoggedOnUser=YYY\XXXStatus=Failed Exception=System.Threading.Tasks.TaskCanceledException: A task was canceled." while the root cause was an unaccessible certificate revocation list. I would expect that your code internally sees something like "System.Net.WebException. The Underlying Connection Was Closed. Could Not Establish Trust Relationship with Remote Server." (see e.g. https://support.microsoft.com/da-dk/help/823177/prb-system-net-webexception-the-underlying-connection-was-closed-could), and it would have been helpful to find that (or even more) in the logfile.



    • Edited by G47HJKL Friday, March 29, 2019 7:50 AM
    Friday, March 29, 2019 7:47 AM
  • Thanks for your feedback, I will add this to the backlog.

    Will also check if we can add this scenario to the troubleshooting page.

    It's weird that I haven't see it before. Maybe most customers use a cert from a local CA thus does not need the internet to validate the cert?

    Sunday, March 31, 2019 11:08 AM