NNR When Coming through "NAT"

[archedmeerkat]

Just wanted to see if there is any real solution or ideas on handling NNR when a workstation/client is behind a NAT.

Workstations are remote but able to access Domain Controllers through a "proxy" and do not have an IP address on the local network, so none of the four Network Name Resolution methods will work. There is no way for direct outbound communication to reach workstations and no IP address to Hostname to resolve with DNS.

[#2]

MDI learns over time (should be relatively quick for active NATs) that certain source IP addresses are "NAT" and stop trying to resolve them using NNR.
What is exactly the problem you see?

[#3]

@Eli Ofek - Not a major problem, really, just that I would prefer the hosts be able to be resolved. In conjunction with some other tools and logs, we can in many cases go back and determine the host if needed. 

Hunting through the raw data Defender for Identity provides to CloudAppSecurity, Office365, and Sentinel has proven helpful. This has come mostly in the form of "you shouldn't be doing that" type of policy violations, but also shows where there are some apps that are not configured correctly. I'm not directly concerned (too much) with DFI's direct ability to detect. I do miss having some of that host data there in the raw logs, but this isn't specifically a DFI issue but one that comes from NAT being used. Wanted more to see if there are any thoughts/ideas around this. I'm not sure there is a real trivial solution or one at all, just normal difficulty of dealing with NATs/Proxys/Load Balancers.

[#4 · Accepted solution]

We do have some features where we sometimes can give clues about the machine name, but it's not always possible, as it's usually protocol dependent.