Forum Discussion

thatguy000's avatar
thatguy000
Copper Contributor
Oct 28, 2019

Low success rate of active name resolution using RPC over NTLM

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

  • EliOfek's avatar
    EliOfek
    Icon for Microsoft rankMicrosoft
    Oct 28, 2019

    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

    • thatguy000's avatar
      thatguy000
      Copper Contributor
      Oct 28, 2019

      EliOfek 

      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.

      • EliOfek's avatar
        EliOfek
        Icon for Microsoft rankMicrosoft
        Oct 28, 2019

        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.

Resources