Azure ATP running in Azure IaaS Environment

[Brian_Sutton]

My company has multiple different domains we are protecting with AATP.  All of the domains except 1 are located on premise.  We have a single domain running on Windows VMs located in Azure IaaS.  This domain is not connected to anything on premise.  We are using AD DNS servers for name resolution within the domain.  I have full access open outbound in the network security groups from the DC subnet to all other subnets AND full access open inbound in the other subnets from the DC subnet.  I am able to ping the different Windows servers by their NetBIOS name from the DCs.  I am receiving the following health warning in the Azure IaaS environment.

Low success rate of active name resolution using NetBIOS.
2 Sensors have low success rates of active name resolution using NetBIOS. Azure ATP may issue more false positive alerts and accurate detection capabilities may be affected.

Are there known 'issues' with using AATP in Azure IaaS environments?  Is there a place were AATP specifies which server(s) it is having issue resolving their NetBIOS names?

Thanks,

Brian

[#2]

@Brian_Sutton  The sensor will try to contact endpoints that contacted the DC via port 137/Udp.

If they failed to respond, this health alert will be generated.

it usually happens of for most machines this 137/udp port is not accessible, or fails to respond within 500 ms.

[#3]

@Eli Ofek I double checked our Azure Network Security Group setup and the appropriate access is open. I also tested connecting to UDP 137 from our DCs using the Test-Port.ps1 Powershell script and it returned Open = True. 

We do have 2 Linux firewalls in the environment but I don't believe AATP even knows that they exist.  UDP 137 access was already open from the DC subnet however name resolution wasn't working.  I temporarily patched the hosts file on the DCs and will see if the health warning returns tomorrow.

Do you have any other ideas?  The message states the sensors are having 'low success rates'.  Is there a log somewhere that specifies which system(s) the sensors are having issues connecting to?  Is it the same message if the sensors can't connect to a single server vs. multiple/all servers?

Thanks again for your input!

[#4]

Host file would not work for this..

This is not a DNS based name resolution.

The idea is that if we see this IP on network traffic, we verify its identity using multiple methods.

One of these methods is sending a crafted payload to Udp/137 that is expected to make the endpoint reply with it's netbios name....

The alert will pop up if more that 90% of our tries failed. 

this could be due to blocked port or high latency to many endpoints or to few endpoints that responsible for most of the traffic.

We can turn on a trace for a few hours which will tell us which IPs are failing, but you need to contat support for that.

[#5]

@Eli Ofek Per your recommendation, I opened a support ticket (6/26 at 9:02 AM ET) however I haven't received a single update from Microsoft support yet. I updated the case twice asking for an update but still haven't heard from anyone.  Can you assist with pushing this forward (ID = 119062624001365)?  Thanks!

[#6]

@Brian_Sutton , Apologies for the delay, it seems that support are currently under heavy load,

I will see what I can do to push this faster.