Defender for Identity Sync Errors

Copper Contributor

Hello All - I am getting the following error:

 

2022-10-28 11:09:42.8219 Error Socket SendReceiveAsync failed with socket exception [ipEndpoint=0.0.0.1:137 AddressFamily=InterNetwork] exceptionFormattedDetails=[NativeErrorCode=10051]
System.Net.Sockets.SocketException (0x80004005): A socket operation was attempted to an unreachable network
at int System.Net.Sockets.Socket.EndSendTo(IAsyncResult asyncResult)
at void Microsoft.Tri.Infrastructure.TaskExtension.AsyncCallback<TResult>(IAsyncResult asyncResult, Func<IAsyncResult, TResult> endMethod, TaskCompletionSource<TResult> taskCompletionSource)
at async Task<UdpReceiveResult> Microsoft.Tri.Common.UdpClientWrapper.SendReceiveAsync(IPEndPoint ipEndpoint, byte[] data)

 

This feels like a DNS thing. The sensor is installed on a DC and works fine. Showing as running in the portal.

4 Replies
This is a name resolution attempt over UDP/137 to address 0.0.0.1.
So this will happen if the DC got a network packet from this address.
The weird thing this is a reserved IANA range, probably for local host config or something.
I am not expecting this address to really respond on UDP/137.
But we are also not filtering the 0.0.0.0/8 range as effectively I don't think we saw actual traffic from there.
Is there anything running on the host that will initiate a connection from this special address ?
How often do you get this error?
Maybe capture a network trace to get more clues where is it coming from ?

Anyway, it shouldn't effect the sensor work.
Thanks Eli - I get this error pretty much every hour from what I can see. I have ran PacketMon and captured the logs for over an hour but nothing has shown up with that address and yet when I look at the MS Tri Sensor log the error is still there.

I have even tested connectivity as per the MS website (https://learn.microsoft.com/en-us/defender-for-identity/configure-proxy) and it works fine. Not sure what is really going on.
Based on looking at the logs and the Defender portal, MDI is working fine. I noticed that 0.0.0.1 Endpoint was showing in the portal when I went to look at my sensitive devices as a device that could be added along with a number of other unknown devices.
This shouldn't effect the sensor work.
0.0.0.1 is a local address, probably u sed by some software running on the machien itself, which explain why capturing won't see it.

The idea is to understand what on the machine uses this address... and to know it's legit.