Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Low success rate of active name resolution using RPC over NTLM

Copper Contributor

Hello all -- 

I'm looking to resolve this last warning/alert from AATP;  we've had warnings about NetBIOS and reverse DNS, but those seem to have resolved on their own.  This last warning about RPC over NTLM is sticking around.

Unfortunately, I'm not even sure where to start.  I've looked thru Microsoft.Tri.Sensor.log on the server noted in the alert, and I'm seeing plenty of Warn's, but I don't know what to do about them. The vast majority are similar to this:

Warn EntityResolver ResolveNtlmEventAsync [Time=10/28/2019 22:20:16 SourceAccountName=domain\svcAccount SourceAccountId=34562b44-f302-43ef-9f53-a93e676514ef SourceComputerName= SourceComputerId= SourceIpAddress= DomainControllerName=DomainName= Name=DC01.ht.dom DomainControllerId=1d3c2345-954b-4d3c-aaf3-7753afcea337 ErrorCode=Success ResourceIdentifier=]

Am i even looking in the right log file for clues?  Is there a more descriptive/helpful location for details on exactly where the communication is failing and how to fix it?  

Thanks

3 Replies

@thatguy000 , You can ignore this warn message you found on the logs. it's unrelated.

AS for the name resolution issue, it's a bit tricky to resolve it on your own, I strongly suggest to open a support ticket and get guidance from the support engineer about which data you need to collect and how. 

 

Eli

@Eli Ofek 

Well that's disappointing.. one would think if a service is deemed "Ready for the public" then it would have documentation and tools available to the enduser to resolve these issues. So much for logic. 

 

Thank you for the quick response tho.

@thatguy000 , This is indeed the aspiration, sadly, when the service depends on a sensor that still has to run on prem,  there are environmental challenges which we cannot easily control (Yet we always try to improve that in new ways).
The issue you mentioned is not happening  due to misconfiguration of  the product or service, but due to on prem  network characteristics and configuration (Giving that you followed the deployment guide already, and made sure requested ports are properly open).  Those at times can be complicated to troubleshoot for some customers.

While we are currently researching the development of tools that will make it easier for the customers to troubleshoot this issue, currently getting guidance from support is still the quickest way for most customers.