RDP over VPN into AzureAD-joined machine

[HCHTech]

I haven't run into this before, but after setting up a new computer at the office for someone, they were unable to RDP into it, credentials not accepted no matter what I tried:

• Machine was AzureAD-joined (Business Premium licenses for everyone)
• Remote desktop was enabled
• Windows Hello configured with PIN login on machine
• Username for the RDP session was the Work-or-school account email address (although I also tried AzureAD\Username and AzureAD\emailaddress in desperation)
• Password was confirmed correct, Office & Sharepoint were accessed successfully on the computer with those same credentials
• Reviewed both Windows firewall and network firewall for any stupidity, none found
• Resetting both the password and the Windows Hello PIN had no impact on the problem

Ultimately, I made it work by disabling "Allow connections only from computers running Remote Desktop with Network Level Authentication", then adding:

enablecredsspsupport:i:0

to the RDP shortcut. In other words, NLA wasn't working over the VPN for some reason. The old office machine that this new machine replaced was Windows 10 and was not AzureAD-joined, and the worker had been using RDP-over-VPN for a couple of years successfully.

I'm glad to get it working, but not very happy disabling NLA to do so. Is there some hidden checkbox in Entra or Intune I need to check? Anything else I can try?

 

[YeOldeStonecat]

Fun stuff, actually ran across this last week....

https://www.reddit.com/r/Intune/comments/10gh460/rdp_to_azuread_joined_device

I have not come up with a 100% smooth solution yet....so far band-aided with the enablecredsspsupport and unchecking that NLA...which I also don't like. But my case is internal only...so I'm not overly worried.

 

[thecomputerguy]

I haven't run into this before, but after setting up a new computer at the office for someone, they were unable to RDP into it, credentials not accepted no matter what I tried:

• Machine was AzureAD-joined (Business Premium licenses for everyone)
• Remote desktop was enabled
• Windows Hello configured with PIN login on machine
• Username for the RDP session was the Work-or-school account email address (although I also tried AzureAD\Username and AzureAD\emailaddress in desperation)
• Password was confirmed correct, Office & Sharepoint were accessed successfully on the computer with those same credentials
• Reviewed both Windows firewall and network firewall for any stupidity, none found
• Resetting both the password and the Windows Hello PIN had no impact on the problem

Ultimately, I made it work by disabling "Allow connections only from computers running Remote Desktop with Network Level Authentication", then adding:

enablecredsspsupport:i:0

to the RDP shortcut. In other words, NLA wasn't working over the VPN for some reason. The old office machine that this new machine replaced was Windows 10 and was not AzureAD-joined, and the worker had been using RDP-over-VPN for a couple of years successfully.

I'm glad to get it working, but not very happy disabling NLA to do so. Is there some hidden checkbox in Entra or Intune I need to check? Anything else I can try?

Had this same issue, the only solution I found was the same workaround you found. I felt it was safe enough since the computer wasn't public facing and the RDP connection was internal only. Same as @YeOldeStonecat

 

[HCHTech]

Oh - for once it's not must me - haha.

I have run into a couple of odd things lately with new Win11 setups. In one case, I found out quite by accident that I couldn't ping the device from inside the network. I found out that "Core Networking Diagnostics - ICMP) was set to block in the Windows firewall settings. This was a fresh install of Win11 so somewhere along the way, they must have changed the default setting for this to 'block'.

Edit: That Reddit thread @YeOldeStonecat linked is 2 years old! I guess that means this issue is here to stay.

 

[thecomputerguy]

Oh - for once it's not must me - haha.

I have run into a couple of odd things lately with new Win11 setups. In one case, I found out quite by accident that I couldn't ping the device from inside the network. I found out that "Core Networking Diagnostics - ICMP) was set to block in the Windows firewall settings. This was a fresh install of Win11 so somewhere along the way, they must have changed the default setting for this to 'block'.

I find that sometimes I can't ping a device unless file and printer sharing is turned on.

When I share a file I do it the old school way in properties by manually sharing it. Then I'll goto the client computer and find I can't access or ping the share by UNC or by IP, then I remember I forgot to turn on File and Printer sharing.

Seems inconsistent... maybe ICMP is disabled by default in new W11 installs and a side effect of enabling file and printer sharing is then set to Enabled as well.

 

[Markverhyden]

Oh - for once it's not must me - haha.

I have run into a couple of odd things lately with new Win11 setups. In one case, I found out quite by accident that I couldn't ping the device from inside the network. I found out that "Core Networking Diagnostics - ICMP) was set to block in the Windows firewall settings. This was a fresh install of Win11 so somewhere along the way, they must have changed the default setting for this to 'block'.

Edit: That Reddit thread @YeOldeStonecat linked is 2 years old! I guess that means this issue is here to stay.

Don't you mean undocumented feature?

 

[Sky-Knight]

NLA will never work unless the machine you're connecting with is also joined to the same directory. This is also true with the cred support switch. The reason this process fails is the machine level auth fails. Disabling NLA allows the connection, enabling cred support gives you a local login context on the target machine that can access the cloud directory. Both steps are required if you're going to connect from machine that isn't on the same directory UNLESS you've federated your source directory to the destination directory.

AD used to do the same thing... we just sort of brute forced past it.

Not being able to ping a device unless file and printer sharing is enabled is by design... the machine will not respond to the short name resolution without this.

Ping via IP will not work unless the firewall is set to private mode AND the ping is coming from the same IP range as well, this too... is by design.

All of this has been true since default Windows 10 installations for ages. I'm somewhat shocked there are those around here that do not know these things. However, the security settings for the NLA and enforced directory membership components were NOT on by default. Now... they are, and I don't think you can turn them off fully either.

These are all cases where Microsoft demands people be more secure for reasons of their own. They aren't going to back off here either.

 

[HCHTech]

NLA will never work unless the machine you're connecting with is also joined to the same directory. This is also true with the cred support switch. The reason this process fails is the machine level auth fails. Disabling NLA allows the connection, enabling cred support gives you a local login context on the target machine that can access the cloud directory. Both steps are required if you're going to connect from machine that isn't on the same directory UNLESS you've federated your source directory to the destination directory.

This makes sense, of course. For on-prem AD or just plain workgroups, when you VPN in, you ARE on the same directory, so that also makes sense why we didn't see this as an issue for those setups. We are only just now starting to build a critical mass of SMB customers using AzureAD, so we haven't bumped into this limitation before. I only forced my own company to do this at the beginning of the year - it was high time to "eat our own dogfood" on this topic. I guess I haven't tried to remote into my own machine since this change either. That means I'm past due for a vacation - haha.

 

[Sky-Knight]

This makes sense, of course. For on-prem AD or just plain workgroups, when you VPN in, you ARE on the same directory, so that also makes sense why we didn't see this as an issue for those setups. We are only just now starting to build a critical mass of SMB customers using AzureAD, so we haven't bumped into this limitation before. I only forced my own company to do this at the beginning of the year - it was high time to "eat our own dogfood" on this topic. I guess I haven't tried to remote into my own machine since this change either. That means I'm past due for a vacation - haha.

This is true! On all accounts! Also... I need to follow your example. This year can truly bite me.

But, to take a turn back on topic. There is one final angle to this.

If you're using the cloud correctly, you no longer need to RDP to anything, or and this is a hot take too... VPN to anything.

Identity is the modern control plain. And if your systems are controlled correctly, you can do all the things, from any machine, anywhere...

Think about this from a financial perspective, why maintain two machines for a user when a single one that moves with them will do?

For the rest... we have Windows 365, and Azure Virtual Desktop. I've deployed either of these ONCE in the last year. It's EXTREMELY NICHE and deployment of these products means in effect, the business has made the decision to not modernize something, and they're going to eat the cost of maintaining this infrastructure to keep that thing alive. But now it's in the cloud, with an authenticated proxy in front of it, subject to Conditional Access policy, and the users just RDP to the proxy, that lives on the Internet.

IMHO the only VALID use of this technology anymore is compliance. If we're working with PHI, or CMMC / ITIL controlled information, it can be extremely useful to create a secure enclave based on Active Directory somewhere, and leverage a VDI of some sort to access it. Then we get two different authentication control systems to get at the endpoint, and we can be very aggressive on the audit logging and permissions.

You will run into the above as soon as you work with a medial clinic or military contractor. And since these two business types come in the small variant too, it's helpful for everyone to at least be aware this reality exists.

Anyway, RDP is a VPN in and of itself, also SMB is too! So again if you're Zero Trusting correctly, and leaning on the cloud like you're supposed to, you never need to VPN or RDP into anything UNLESS you're an IT admin, and if you are then you've got all the room in the world for custom hackery as needed.

 

[YeOldeStonecat]

The issue my client ran into where I saw this...their home rigs were AzureAD joined...and the rigs they were remoting into....also AzureAD joined. VPN into the office first...RDP through VPN tunnel.

My answer was "You already have Splashtop...just...use it!"
But..the curious in my...why doesn't this work like it used to (RDP)

 

[Sky-Knight]

The issue my client ran into where I saw this...their home rigs were AzureAD joined...and the rigs they were remoting into....also AzureAD joined. VPN into the office first...RDP through VPN tunnel.

My answer was "You already have Splashtop...just...use it!"
But..the curious in my...why doesn't this work like it used to (RDP)

Now that I cannot explain.

I use Zero Tier for the "VPN" because it's stupid cheap, and so much better than traditional VPN.

Two Azure AD joined machines, used by the same person, the TPM modules of both rigs are registered to the M365 account, and access is granted as soon as the PIN is provided.

Now here's the part that might be getting you... if RDP wants a PIN, it wants the PIN FROM THE CONNECTING MACHINE. You're unlocking the LOCAL TPM module, which in turn authenticates against the cloud directory, which authorizes the connection to the target machine. I've seen many default into using the remote PIN, and that won't work. PINs are never transmitted over the wire, they are local only devices.

Hello for Business is your friend! And all of this is default behavior of M365, even without Intune. It's just Entra ID joined machines doing their default thing. I'm not sure why it's not working for you!