SOLVED

Error Communication WebClient

New Contributor

We are deploying Azure ATP Sensor on a DC and are getting the following error:

 

2019-12-04 15:06:10.3678 Error CommunicationWebClient+<SendWithRetryAsync>d__8`1 Microsoft.Tri.Infrastructure.ExtendedException: Sanitized exception: [Type=System.Net.Http.HttpRequestExceptionMessage=7INzM3PVZQKggOiiHcWjqw==StackTrace

 

We are using a proxy to connect to the Internet. As a troubleshooting step, we have got the IP address for the DC is whitelisted on our proxy to allow connections through to the Internet. The error still continues.

 

On the ATP portal, we see the Service Status changing from "Starting" to "Stopped" status as the service keeps on retrying to connect. However, the Health status shows as "Syncing". I have attached a screenshot as well showing the status. Ignore the ones that are masked out in BLACK, the one that is causing us issues is the one masked out in YELLOW.

 

Has anyone come across this issue yet and is there is a known fix for it?

8 Replies

@tanves 

This error means there is still a networking issue which blocks the sensor from contacting the AATP Azure backend via HTTPS/443.

Although  white listed, it might still be blocked int he proxy or somewhere else.

Note: If you install the sensor in silent mode, you have an option to install it with proxy support, including a proxy that requires an authentication, so instead of trying to bypass the proxy, maybe try to work with it...

  https://docs.microsoft.com/en-us/azure-advanced-threat-protection/atp-silent-installation#proxy-auth...

@Eli Ofek 

Thanks for the quick turnaround! Very much appreciated!

 

We did start off with setting the proxy authentication and attempting connection via that route by using the silent mode install method. Gradually we then started troubleshooting and reached a point where we had to whitelist the server IP on the proxy without any success.

 

We are going to check our perimeter firewall to validate if any traffic is being dropped there.

 

In the meanwhile, does anyone know if there are any specific ports that need to be opened up for traffic related to ATP sensor communication?

@tanves 

Just 443, both to azure, and to localhost.

(The sensor service is communicating with the updater service via localhsot 443 as well).

@Eli Ofek 

Thanks for your assistance so far! We had traffic on 443 getting dropped on our Perimeter Firewall. Once the DC IP was allowed to communicate over that port, we saw a new set of errors.

 

These errors have been discussed in the Tech Community

https://gorovian.000webhostapp.com/?exam=t5/Microsoft-Advanced-Threat/Azure-Advanced-Thread-Protection-Se...

 

In our case, we have a forest where the root domain is root.com with two child domains, partner.root.com and partner1.root.com (I have used example names). We are testing ATP sensor install on partner.root.com. We are using an account which is created in partner1.root.com as that is our user domain. Questions I had were, under Directory Services config on the portal:

 

- In the user name do I put just the SAM account or the UPN excluding the domain name

- In the domain, do I put partner1.root.com or partner.root.com or root.com

 

Any help on this matter would be greatly appreciated!

best response confirmed by tanves (New Contributor)
Solution
Both SamName and full UPN formats should work. Set the dc domain of the account. This is if all domains have full 2 way trust.

@Eli Ofek 

 

Thanks a bunch for all your guidance! We entered the UPN as per your advice along with the DC Domain and all communications started working!

@Eli Ofek 

 

I tried the silent installation but it doesnt install or give any error.

Tried UPN in the silent installation as below:

 

 

.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="xxxxxxxxxxxxxxxxxxxxxxxxx==" ProxyUrl="https://proxy.corp.abc.com:8080" ProxyUserName="xxxxxxx@corp.abc.com" ProxyUserPassword="xxxxxxxxx"

 

Is it correct?

 

 

@Amin7RDR The format is correct, I can only guess that the values are correct as well :)

In order to sww what went wrong you need the deployment logs,  the interactive console/ UI won't tell you much without the logs.

www.000webhost.com