Hi BrianBaldock,
Thank you for the prompt response.
I understand the TLS requirement, and un/authenticated connections should only be a factor if a proxy is a pure L7 proxy, and not AD/Kerberos integrated.
However, I think you may have misunderstood my point about geo-specific IPs. With sites in 5 countries, some routed out via HQ (not proxied, pure IP routing), in a different country we've found that URL-based filtering fails, sometimes. Consider a MDE client in country X in Asia, with local DNS resolving via local breakout to ISP in X: host gets IP for one of the required URLs (say login.microsoftonline.com). This is geo-resolved (in country X) to 9.8.7.6, so MDE client opens a request to 9.8.7.6:443. If that is routed via a site via HQ in country Y in EUR, the following can happen: perimeter firewall in country Y has a permit rule to allow internal traffic out to login.microsoftonline.com:[80|443], which it resolves via DNS from country Y, and gets the IP 5.4.3.2. The original request gets blocked, because - from the firewall's perspective, it doesn't match the permit rule. This is L3 filtering, obviously (and that's the problem).
Worse, I've also observed that not only are the FQDNs in the URL list geo-located, but some also redirect (login.microsoftonline.com redirects to http://www.office.com) which isn't in the URL list at all. The consequence of this is that bits of Defender keep losing contact with the Defender cloud, or onboarding just stops working. (I have a ticket open for this, right now).
Take a look at the DNS records for the documented URLs - they're all (or mostly) CNAMEs, many of which resolve back to CDNs like Akamai, and the whole thing is in constant flux...
Microsoft appears to make the assumption that everyone's network will be configured similarly, with either a non-TLS-inspecting forward proxy they can use, or just unrestricted internet access for every MDE client. MS can happily bounce their listeners around various CDNs as it suits, but these are not helpful assumptions from the customer's perspective.
The question is: does Microsoft actually offer any forward proxy product that can be used for this?
"Windows security on disconnected devices whitepaper.pdf" from an MS blog suggests using an Azure Application Gateway. Is that still valid?
Apols if this sounds like a rant, but this has been driving me round the twist 🙂