I have been remoting into Windows machines for over a decade. Domain-joined, workgroup, across VPNs, across the internet. RDP is one of those things that just works once you flip the toggle and open port 3389. Until it does not.

This week I spent hours chasing an RDP failure on an Entra-joined machine. The machine was on the same subnet, on the same switch, plugged into the same network as the source machine. Everything about it should have been a two-minute connection. Instead, I ended up knee-deep in packet captures, NIC driver investigations, certificate stores, and registry edits before I found the actual problem.

There were two problems, actually. And they stacked on top of each other in a way that made the troubleshooting significantly harder than either one would have been alone.

The Setup#

The target machine is called PC-Non-Gamer, sitting at 192.168.1.122. The source machine is Fragbox at 192.168.1.109. Both are on the same local subnet, both wired into the same Cisco managed switch. No VPN, no routing, no NAT. Just two machines on the same wire.

PC-Non-Gamer is joined to Entra ID (formerly Azure AD) and managed by Microsoft Intune. There is no on-premises Active Directory domain controller anywhere on this network.

That last detail matters. A lot.

The Symptom#

RDP from Fragbox to PC-Non-Gamer failed with the standard “Remote Desktop can’t connect to the remote computer” error. Not helpful. Never helpful.

I ran Test-NetConnection from Fragbox targeting port 3389. Failed. Ping timed out too. But here is the part that made me pause: PC-Non-Gamer could ping Fragbox just fine. One-way connectivity. The network path existed, but only in one direction.

Why Entra-Joined Machines Are Different#

Before I walk through the diagnostic steps, it is worth explaining why Entra-joined machines behave differently from domain-joined or workgroup machines when it comes to RDP and network profiles. If you are migrating clients from traditional Active Directory to Entra ID with Intune, this is something you need to understand up front.

Network Profile Behavior#

On a traditional domain-joined machine, Windows detects the presence of a domain controller on the local network and automatically assigns the Domain network profile. The Domain profile is the most permissive of the three profiles (Domain, Private, Public) and allows things like ICMP echo requests, file sharing, and Remote Desktop inbound by default.

On a workgroup machine, you manually set the profile to Private during setup or through the Network & Sharing Center. Private is less permissive than Domain but still allows most LAN services.

On an Entra-joined machine, there is no domain controller on the local network. Windows has nothing to detect. It cannot assign the Domain profile because the domain relationship exists in the cloud, not on the wire. So Windows defaults to Public. The Public profile blocks nearly all unsolicited inbound traffic. ICMP, SMB, RDP – all blocked. The machine can reach out, but nothing can reach in.

This is the single biggest gotcha with Entra-joined machines on a local network. The machine looks like it is online and healthy. It can browse the internet, sync with Entra, pull Intune policies. But from the perspective of any other device on the same subnet, it is a black hole.

RDP Authentication#

The authentication model is different too. On a domain-joined machine, you authenticate with DOMAIN\username or username@domain.local. On a workgroup machine, you use a local account.

On an Entra-joined machine, the credential format is AzureAD\user@domain.com. This trips people up because it looks like a domain credential but uses the AzureAD prefix instead of a NetBIOS domain name. The user also needs to be a member of the local Remote Desktop Users group, and you need to add them using the same AzureAD\user@domain.com format.

Certificate Handling#

This is the one that got me. On a domain-joined machine, the domain PKI infrastructure typically handles certificate enrollment for RDP. On a workgroup machine, Windows auto-generates a self-signed certificate when Remote Desktop is enabled. Both processes are mature and reliable.

On an Entra-joined machine, the certificate generation process can fail silently. There is no domain CA to issue a cert, and the auto-generation of a self-signed cert depends on the NETWORK SERVICE account having proper permissions to the machine key certificate store. If those permissions are missing or corrupted, the certificate never gets created. The RDP service starts – TermService shows as “Running” – but the listener never binds to port 3389 because it has no certificate to use for TLS negotiation.

The service lies to you. It says it is running. It is not.

The Diagnostic Path#

Here is the full sequence I went through. I am including everything because the process of elimination matters as much as the fix, especially when you are dealing with two overlapping problems.

Confirming the Failure#

From Fragbox:

Test-NetConnection -ComputerName 192.168.1.122 -Port 3389

TCP test failed. ICMP timed out. But on PC-Non-Gamer, pinging Fragbox at 192.168.1.109 worked fine. One-way connectivity confirmed.

Checking the Obvious#

On PC-Non-Gamer, I verified the basics:

# Is Remote Desktop enabled?
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections"
# Result: 0 (enabled)

# Is the service running?
Get-Service TermService
# Result: Running, StartType Automatic

# Are the firewall rules in place?
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction
# Result: Rules present and enabled

Everything looked correct. Remote Desktop was enabled, the service was running, the firewall rules existed.

The Network Profile#

Get-NetConnectionProfile

Network profile: Public. There it is.

I changed it to Private:

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

Inbound traffic was still blocked. I even disabled the Windows Firewall entirely on the Private profile to eliminate it as a variable. Still nothing. That was unexpected.

Ruling Out the Physical Layer#

I swapped another device onto the same switch port PC-Non-Gamer was using. It worked fine. The switch port, cable, and VLAN were not the problem.

I checked for Intune-managed firewall rules:

Get-NetFirewallRule | Where-Object { $_.PolicyStoreSource -ne "PersistentStore" }

Nothing from Intune. All rules were local.

Going Deeper – NIC and Packet Analysis#

I checked the NIC adapter bindings for third-party filter drivers. Clean. Standard Microsoft bindings only.

Then I ran a packet counter test:

Get-NetAdapterStatistics -Name "Ethernet"

I pinged from Fragbox while watching the counters. ReceivedUnicastPackets incremented. Packets were hitting the NIC. The hardware was receiving traffic.

Next I ran a packet capture with netsh trace:

netsh trace start capture=yes tracefile=C:\temp\nettrace.etl
# Ran pings from Fragbox
netsh trace stop

The trace showed no packets from 192.168.1.109. The NIC was receiving them, but the OS network stack was not processing them. Something between the NIC driver and the IP stack was dropping traffic.

This led me to the NIC driver. PC-Non-Gamer was running a 2017 Microsoft generic Realtek driver (v1.0.0.14) on a Realtek PCIe GbE Family Controller. I updated it to the December 2025 manufacturer release.

I also performed a full network stack reset:

netsh int ip reset
netsh winsock reset
Restart-Computer -Force

After the reboot, inbound connectivity was restored. Ping worked. But RDP still did not.

Finding the Real Problem#

With the network path confirmed working, I created a quick TCP listener test:

# On PC-Non-Gamer
$listener = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, 8080)
$listener.Start()

From Fragbox, Test-NetConnection to port 8080 succeeded. The network was fine. The problem was specific to the RDP service.

I checked what was actually listening:

netstat -an | findstr "3389"

Nothing. Port 3389 was not in a LISTENING state. The TermService was “Running” but the listener had never started.

I queried the RDP configuration:

Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices | Select-Object SSLCertificateSHA1Hash

The SSL certificate hash was all zeros: 0000000000000000000000000000000000000000. No valid certificate was bound to the RDP listener. Without a certificate, the listener cannot perform TLS negotiation and will not bind to the port.

The event log confirmed it:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" | Where-Object { $_.Id -eq 17 } | Select-Object -First 5

Repeated Event ID 17 entries: “Remote Desktop Service start failed. The relevant status code was 0x80070005” – ACCESS_DENIED. The NETWORK SERVICE account did not have permissions to the machine key certificate store, so Windows could not auto-generate the self-signed RDP certificate.

The Fix#

Everything below was performed locally on PC-Non-Gamer in an elevated PowerShell session.

1. Set the Network Profile to Private#

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

2. Enable the Remote Desktop Firewall Rules#

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

3. Fix the Certificate Store Permissions#

icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "NETWORK SERVICE:(OI)(CI)F"

This grants NETWORK SERVICE full control with inheritance on the machine key store. Without this, Windows cannot generate or access the self-signed certificate it needs for RDP.

4. Remove the Stale Certificate Hash#

Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "SSLCertificateSHA1Hash" -ErrorAction SilentlyContinue

5. Create the Remote Desktop Certificate Store#

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("Remote Desktop", "LocalMachine")
$store.Open("ReadWrite")
$store.Close()

6. Generate a New Self-Signed Certificate#

$cert = New-SelfSignedCertificate -DnsName (hostname) -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec KeyExchange -KeyLength 2048 -NotAfter (Get-Date).AddYears(5)

7. Bind the Certificate to the RDP Listener#

$thumbprint = $cert.Thumbprint
$bytes = for ($i = 0; $i -lt $thumbprint.Length; $i += 2) { [convert]::ToByte($thumbprint.Substring($i, 2), 16) }
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "SSLCertificateSHA1Hash" -Value ([byte[]]$bytes)

8. Update the NIC Driver#

Replace the 2017 Microsoft generic Realtek driver with the current manufacturer release. In my case, the December 2025 Realtek package (DRV_LAN_Realtek_8111_SZ-TSD_W11_64_V11682750919_20251230R).

9. Reboot#

Restart-Computer -Force

10. Verify#

After reboot:

# Confirm port 3389 is listening
netstat -an | findstr "3389"

# Confirm a valid certificate hash
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices | Select-Object SSLCertificateSHA1Hash

# From the source machine
Test-NetConnection -ComputerName 192.168.1.122 -Port 3389

All three checks passed. RDP connected successfully from Fragbox.

Quick Reference: RDP Across Join Types#

Here is a summary of how RDP behavior differs depending on how the machine is joined.

Domain-Joined (On-Premises AD)

  • Network profile auto-detects as Domain when a DC is reachable on the LAN.
  • Inbound RDP is typically allowed by default on the Domain profile.
  • Authentication uses DOMAIN\username or username@domain.local.
  • Certificate is usually handled by the domain PKI or auto-generated reliably.
  • Group Policy controls RDP settings centrally.

Workgroup

  • Network profile is set manually to Private during setup.
  • Inbound RDP requires enabling the toggle and confirming the firewall rule.
  • Authentication uses local accounts only.
  • Self-signed certificate is auto-generated when Remote Desktop is enabled.
  • Settings are managed locally on each machine.

Entra-Joined (Azure AD / Entra ID)

  • Network profile defaults to Public because there is no local DC to trigger Domain detection.
  • Inbound RDP is blocked by the Public profile even if the Remote Desktop toggle is on.
  • Authentication uses AzureAD\user@domain.com.
  • Self-signed certificate generation can fail silently if NETWORK SERVICE lacks key store permissions.
  • Settings can be managed through Intune, but network profile policy needs to be explicitly deployed.

Recommendations#

If you are deploying Entra-joined machines in any environment where local network access matters, do these things proactively:

Deploy an Intune Settings Catalog policy to force the network profile to Private for your internal networks. Without this, the profile will revert to Public after a Windows update, a network change, or sometimes just a reboot. Do not rely on manual configuration.

Pre-verify the RDP certificate on every Entra-joined machine after enrollment. Query Win32_TSGeneralSetting and confirm the SSLCertificateSHA1Hash is a valid non-zero value. If it is all zeros, fix the NETWORK SERVICE permissions and regenerate the certificate before anyone reports a problem.

Standardize NIC drivers. If your machines ship with the generic Microsoft inbox driver for Realtek NICs, replace it with the manufacturer driver during your imaging or Autopilot process. The 2017 generic driver caused inbound packet processing failures in my environment. That is not a theoretical problem – it blocked all inbound traffic at the OS level while the NIC hardware received packets normally.

Document the credential format. Your help desk and your end users need to know that Entra-joined RDP uses AzureAD\user@domain.com. Put it in the KB. Put it in the onboarding docs. They will not guess it.

Monitor certificate expiration. The self-signed cert I generated has a five-year lifespan. That is long enough to forget about it entirely. Build a check into your monitoring – whether that is Wazuh, ConnectSecure, or a scheduled script – to flag RDP certificates approaching expiration across your Entra-joined fleet.

Conclusion#

The frustrating thing about this issue is that both problems are individually simple. A Public network profile is a one-line fix. A missing RDP certificate is a few PowerShell commands. But when they stack on top of each other, the troubleshooting path gets significantly more complex because each problem masks the symptoms of the other.

The bigger lesson is that Entra-joined machines are not drop-in replacements for domain-joined machines on a local network. They behave differently in ways that are not immediately obvious, and Microsoft does not go out of its way to warn you. If you are running an MSP or managing any fleet of Entra-joined devices, build the network profile policy and the certificate validation into your deployment checklist. Do it before the first support call comes in.