Registration Failure - Connectivity Issues

Copper Contributor

I've been able to get the sensor installed on a few DCs, but on others I just get the error "The Sensor failed to register due to connectivity issues."  I don't see anything obviously different about the DCs where the install works and where I am getting this error.  I've looked at the logs in AppData\Local\Temp and there aren't any errors there.  


Does anyone know what it needs to be able to connect to in order for me to troubleshoot further?

9 Replies
Hi Eric, Check the sensor log directory under c:\program files\azure advanced threat protection sensor.

The failure is before that folder is created, so no logs.  I was able to get a couple more to run by watching the network.  They needed an outbound rule added to allow HTTPS to  Are there any other IPs we need, or a way to tell the sensor to use a proxy?

Hi Eric, There is information about how to connect via a proxy in "What you will need to on board Azure ATP – a list of prerequisites" entry. Under "For the Azure ATP Sensors to communicate with Azure ATP cloud service" there are specific details on connectivity through a proxy.

Firewall/proxy open - For your Domain Controllers to communicate with the cloud service, you must have open: * port 443 in your firewall/proxy. The configuration needs to be at the machine level (=machine account) and not a user account. Note that you need to setup access to the DNS name not individual IP addresses as there are subject to change.


Thanks.  Our firewalls don't support rules by DNS name, so I'll have to figure out some way around that.


A couple of these are core, so the URL probes won't work for testing connectivity.  It doesn't appear that core supports authenticated proxies, so that's out too.


Are there any plans for a forwarding server like the OMS Gateway?

The only forwarding-like solution we have right now is the stand-alone sensor - you would need to port mirror the traffic from the Domain Controllers to the stand-alone sensor and also forward windows events from either the DCs or from a SIEM. The stand-alone sensor rather than the DCs would communicate with Azure ATP.

Just following up on this issue again.


Are there any options on the road-map that can utilise forwarding of ATP data to the standalone sensor without requiring the port mirror option?


It would be great if we can have something like the Windows Defender ATP setup where the OMS / Log Analytics gateway can be used to collect logs from other endpoints and then send it out over HTTP rather than requiring port mirror setup. ( )

There are no plans to support forwarding of the Azure ATP Sensor data through a gateway server.


Our recommendation is to run the sensor directly on the Domain Controller (port mirroring through a stand-alone sensor cannot collect ETW data so some detections will not work in this configuration), and then use a web proxy to send the data to Azure ATP. For those proxies which do not support URL filtering, the Azure Networking subnet range can be used for the region which contains your Azure ATP instance: 

@Astrid McClean Thanks for the response.


This is challenging to fully deploy as there are many use cases where Domain Controllers have no access to proxy via policy given that these are highly valuable assets.


Is there any security analysis and discussion around use of sensors with Internet access on Domain Controllers that can be shared with security teams to allay concerns around this setup?

@Ejaz Rahman  When the connection from the Domain Controllers is restricted to port 443 and the Azure ATP service (there is a specific URL for each Azure ATP instance) we have seen few concerns.


Happy to followup with you offline if there are specific concerns you or your security team has. Please email me directly or send feedback to aatpfeedback@microsoft,com and we can continue the conversation.