MDI - NNR - blocking NNR for networks with unmanaged and untrusted endpoints - exclusions

[Anwar Mahmood]

Microsoft Defender for Identity (MDI) uses Network Name Resolution (NNR).

But that should not apply to networks with unmanaged and untrusted endpoints.

An example explains.

Alice using her Windows Laptop

Alice works for Contoso. Contoso IT provider Alice with a laptop. Contoso IT manage the laptop.

The laptop is joined to Active Directory Domain Services (AD DS).

It is connected to the internal network via Ethernet.
The internal network has IPv4 172.16.0.0/16.

This should allow traffic flow between her laptop managed by her IT department, and the domain controller.

Network Name Resolution (NNR) can and should succeed against Alice's Windows Laptop.

Alice using her Personal Mobile Phone

Alice has a personal mobile phone.

Contoso IT provide an isolated WiFi network for employees - "STAFFWIFI". Let's say it provides Internet access only - no access to the internal network. In this context, Alice's phone is unmanaged and untrusted.

"STAFFWIFI" is IPv4 172.17.0.0/16.

Alice connects her personal mobile phone to "STAFFWIFI". Alice uses her username and password to logon, using 802.1X.

The WiFi network connects to a RADIUS server, which verifies Alice's credentials against AD DS.

Microsoft Defender for Identity (MDI) detects this.

MDI then begins Network Name Resolution (NNR) to establish connections to Alice's personal mobile phone - such as RDP/3389.

This NNR attempt isn't required, and will not succeed.

For NNR, Microsoft say...

Configuration recommendations

Network Name Resolution - Microsoft Defender for Identity | Microsoft Learn

• NTLM over RPC:

  • Check that TCP Port 135 is open for inbound communication from Defender for Identity Sensors, on all computers in the environment.
  • Check all network configuration (firewalls), as this can prevent communication to the relevant ports.

• NetBIOS:

  • Check that UDP Port 137 is open for inbound communication from Defender for Identity Sensors, on all computers in the environment.
  • Check all network configuration (firewalls), as this can prevent communication to the relevant ports.

• RDP:

  • Check that TCP Port 3389 is open for inbound communication from Defender for Identity Sensors, on all computers in the environment.
  • Check all network configuration (firewalls), as this can prevent communication to the relevant ports.

But I suspect they mean

all [trusted organisational Windows] computers in the environment

Hence, NNR to unmanaged and untrusted endpoints [networks] is blocked | disabled.
In this example, NNR to IPv4 network 172.17.0.0/16 is blocked | disabled.
You can do this using ACLs on routers, etc. Which is fine.

HOWEVER

Using this example, should IPv4 network 172.17.0.0/16 be excluded at

Identities Settings - Microsoft 365 security
https://security.microsoft.com/settings/identities?tabid=globalExclude

Based on
Detection exclusions in Microsoft 365 Defender - Microsoft Defender for Identity | Microsoft Learn
https://learn.microsoft.com/en-us/defender-for-identity/exclusions

Should I add IPv4 network 172.17.0.0/16 to global excluded entities?

[#2 · Accepted solution]

@Anwar Mahmood 

Don't use the exclusions for this, as it would exclude the detections for that IP range.

We have an option to exclude an IP and/or range from NNR.

But you'll need to open a support ticket for that, as it's something that needs to be configured in the backend.