Forum Discussion
MDI - NNR - blocking NNR for networks with unmanaged and untrusted endpoints - exclusions
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.
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... 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
Configuration recommendations
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
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
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?
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.
- Martin_Schvartzman
Microsoft
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.
