Your Brand-New Entra ID Joined Devices Hate Your Corporate LAN — Here’s How to Fix It

TL;DR: When you move to pure Entra ID–joined devices, they lose the ability to see traditional Active Directory Domain Controllers. Because Windows Network Location Awareness can’t complete its legacy LDAP domain-authentication handshake, it defaults to the Public firewall profile — blocking inbound management traffic like Ping, RPC, and WMI on your own LAN. The fix is to stand up redundant internal HTTPS “beacon” servers and use Intune’s Network List Manager CSP to point cloud-only devices at them. Once the device can reach the beacon and validate its certificate, NLA flips the firewall back to DomainAuthenticated.

The Setup: Everything Was Going Great… Until It Wasn’t

You’ve been grinding through your modernization roadmap. Windows Update for Business? Check. Edge management? Check. Apps? Check. Baseline configs? Beautiful.

With hybrid stabilized, you’re ready for the real prize: pure Entra ID–joined devices.

You build your Autopilot profile, tune your ESP, set up your dynamic groups, drop the device on the network, and watch it deploy like a cloud-native dream.

And then — BAM.

Despite being plugged directly into your secure corporate LAN, your shiny new cloud device thinks it’s sitting in a Starbucks.

You just achieved perfect Zero Trust by accident. Nobody can talk to the machine. The machine can’t talk to anything local. It’s online, but it’s basically on an island.

Cue the confetti and the balloons.

The Coffee Shop Conundrum

The culprit isn’t your switches or routing. It’s Network Location Awareness (NLA).

Traditionally, when a domain-joined Windows device connects to a network, NLA:

• Looks for a domain controller
• Checks DNS for domain records
• Performs an LDAP challenge/response to validate the domain GUID

If that succeeds, Windows says: “Cool, we’re at the office.” And it applies the Domain firewall profile.

But your Entra ID–joined devices don’t — and shouldn’t — talk to domain controllers.

So NLA does what it’s designed to do: It fails domain authentication and falls back to the Public profile.

Which means:

• No inbound management
• No remote tools
• No ping
• No RPC
• No WMI
• No local admin tools
• No VPN interface trust

💡 Remote users too: If your VPN interface isn’t recognized as trusted, remote devices stay stuck in the Public profile even after connecting.

The Fix: Teaching NLA a New Trick

Since these devices will never authenticate to a domain controller, we give NLA a modern signal instead: a trusted internal HTTPS endpoint.

Microsoft added this capability through the Network List Manager CSP.

You tell Windows:

“If you can reach this internal HTTPS URL and the certificate validates, treat the network as trusted.”

This flips the device into DomainAuthenticated, which activates your Domain firewall rules.

Step 1: Build the HTTPS Beacon

You don’t need anything fancy. Spin up two internal IIS or Apache servers that return a simple 200 OK.

Rules:

• Redundancy: At least two servers. Put them behind an internal load balancer if you want seamless failover.
• No authentication: No login prompts, no MFA, no pre-auth.
• Valid certificates: Use your internal CA, but make sure your Entra ID–joined devices receive the Root and Intermediate certs via Intune. If the cert chain fails, NLA silently ignores the beacon.

Step 2: Configure Intune

Go to:

Devices → Configuration → Create → Windows 10 and later → Settings Catalog

Search for Network List Manager and configure:

1. Allowed TLS Authentication Endpoints Add your internal URLs (e.g., https://beacon.internal.local).
2. Configured TLS Authentication Network Name A friendly name like Corporate Secure LAN.

Assign to your Entra ID–joined device group.

Step 3: Deal With Firewall Rules

Once NLA flips to DomainAuthenticated, you need Domain firewall rules in Intune.

Two approaches:

• Lift-and-shift Import your existing GPO firewall rules into Intune. Fastest path to parity.
• Tech debt cleanse Start fresh. Build a clean Intune firewall policy and add rules only as needed.

Step 4: Prove It Worked

Run:

Get-NetConnectionProfile

Before the fix: NetworkCategory : Public

After the fix:

Name             : Corporate Secure LAN
InterfaceAlias   : Ethernet
InterfaceIndex   : 6
NetworkCategory  : DomainAuthenticated
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Once you see DomainAuthenticated, your Intune-managed Domain firewall rules apply automatically.

Your tools work again. Your VPN behaves. Your LAN stops pretending it’s a coffee shop.