Remote Desktop to Microsoft Entra Joined Devices: RDP with Windows Hello for Business, NLA, and Web Sign-In Explained

Many organizations are moving away from traditional domain-joined Windows devices and adopting Microsoft Entra joined devices as part of their cloud-first or AD minimization journey.

This shift brings many benefits: simplified device onboarding, better integration with Intune, modern authentication, Conditional Access, Windows Hello for Business, and reduced dependency on on-premises Active Directory.

But during almost every Windows cloud transformation discussion, one practical question comes up:

“If the device is Microsoft Entra joined, how do we connect to it using Remote Desktop?”

This is a valid question. In the traditional Active Directory world, Remote Desktop was straightforward. The device was domain joined, users authenticated with domain credentials, Kerberos or NTLM handled authentication, and access was controlled using local groups or Group Policy.

With Microsoft Entra joined devices, the identity model is different. The device is no longer joined to Active Directory. The user signs in using a cloud identity. Authentication can involve Microsoft Entra ID, online identity certificates, Conditional Access, and in some cases Windows Hello for Business.

So, let us break this down in a practical way.

Can We RDP to Microsoft Entra Joined Devices?

Yes, Windows supports Remote Desktop connections to devices joined to Microsoft Entra ID. 

Microsoft also introduced support for Microsoft Entra authentication for RDP starting with Windows 10/11 devices that have the October 2022 cumulative updates or later.

But the connection method matters.

There are mainly two ways to connect:

1. Connect using Microsoft Entra authentication
2. Connect without Microsoft Entra authentication

Both options work, but they behave differently and have different requirements.

Option 1: RDP Using Microsoft Entra Authentication

This is the modern and recommended approach when you want to use Microsoft Entra ID directly during the Remote Desktop sign-in process.

In this method, the RDP client uses the option:

Use a web account to sign in to the remote computer

This option is available in the Advanced tab of the Remote Desktop Connection client.

Technically, this uses the RDP property: enablerdsaadauth:i:1

This method can be used when both the local and remote devices are running supported Windows versions, including Windows 11 with October 2022 updates or later, Windows 10 20H2 or later with October 2022 updates or later, and Windows Server 2022 with the relevant October 2022 update or later.

The important advantage here is that the device from which you are connecting does not need to be domain joined or Microsoft Entra joined. It can be:

• Microsoft Entra joined
• Hybrid Microsoft Entra joined
• Active Directory joined
• Workgroup joined

That makes this option useful for modern environments where IT admins, support engineers, or users may connect from different types of Windows devices.

Prerequisites for Microsoft Entra Authentication RDP

Before this works, a few things must be ready.

The remote device must have Remote Desktop enabled under:

 Settings > System > Remote Desktop

The recommended setting is enabling: Require devices to use Network Level Authentication to connect

The user must also be allowed to connect to the remote device. Example users or support engineers need access, they must be added to the local Remote Desktop Users group on that remote device.

You can add an Entra ID user manually using: net localgroup "Remote Desktop Users" /add "AzureAD\user@domain.com"

This command must be run with local administrator privileges.

For enterprise deployments, this should ideally be handled using Intune policy instead of manual configuration.

How to Connect Using Microsoft Entra Authentication

Let’s check the Entra joined device status and RDP settings before we connect to this machine over RDP.

Open Remote Desktop Connection: mstsc.exe

Go to the Advanced tab. Select: Use a web account to sign in to the remote computer

In this example, we are trying to connect from a Windows Server 2022 machine that is joined to a workgroup.

Enter the remote computer name and connect.

When prompted, use the user format: user@domain.com

Once the username and password are accepted, the user will be prompted for MFA, provided no other Conditional Access policy restrictions are blocking access.

Finally, the user is able to successfully sign in to the Entra joined device using web sign-in.

One very important point: IP address cannot be used with this method.

This is an important design point for customers. If you are planning RDP access to Microsoft Entra joined devices, proper name resolution is required. This could be internal DNS, VPN DNS, or another trusted name resolution method depending on the network design.

Conditional Access Support

One of the biggest advantages of this method is Conditional Access integration.

Conditional Access policies can be applied to the Microsoft Remote Desktop cloud application(Microsoft Remote Desktop (a4a365df-50f1-4397-bc59-1a1564b8bb9c) for controlled access.). This means organizations can enforce controls such as MFA, compliant device requirement, trusted location, or other access conditions before allowing RDP using Microsoft Entra authentication.

This is very powerful because RDP access is no longer just a network-level decision. It can become an identity-driven access decision.

For example, an organization can say:

Allow RDP to Microsoft Entra joined devices only when the admin is using a compliant device and completes phishing-resistant MFA.

This is where Microsoft Entra joined devices provide a much better security model compared to traditional unmanaged RDP access.

Disconnection when the session is locked

The Windows lock screen in the remote session doesn't support Microsoft Entra authentication tokens or passwordless authentication methods like FIDO keys. The lack of support for these authentication methods means that users can't unlock their screens in a remote session. When you try to lock a remote session, either through user action or system policy, the session is instead disconnected and the service sends a message to the user explaining they've been disconnected.

Disconnecting the session also ensures that when the connection is relaunched after a period of inactivity, Microsoft Entra ID reevaluates the applicable conditional access policies.

GUI There is no session lock option available; only sign-out is supported.

Option 2: RDP Without Microsoft Entra Authentication

By default, RDP does not automatically use Microsoft Entra authentication, even if the remote PC supports it. another supported method called connecting without Microsoft Entra authentication.

In this method, you simply open Remote Desktop Connection, enter the computer name\IP, and sign in using one of the supported username formats: user@domain.com or AzureAD\user@domain.com

Avoid using the traditional format: domain\user For Microsoft Entra joined devices, that format can fail because the remote machine is not joined to the traditional AD domain.

There is one major limitation here: both the local and remote device must be in the same Microsoft Entra tenant(Entra Joined\Entra Hybrid Joined\Entra Registered).Microsoft Entra B2B guests are not supported for this Remote Desktop scenario.

Let’s validate the same by connecting over RDP from an Entra registered device to an Entra joined device.

This is our Entra registered device, which will connect to an Entra joined device over RDP without using web account sign-in.

We are making sure the connection is not using web account sign-in, as this option is unchecked on the client.

Let’s connect to Remote Desktop using the UPN format: AzureAD\user@domain.com

We can see that the RDP connection is successfully established to the Entra joined device.

Important: When a Microsoft Entra group is added to the Remote Desktop Users group on a Windows device, it isn't honored when the user that belongs to the Microsoft Entra group logs in through RDP, resulting in failure to establish the remote connection. In this scenario, Network Level Authentication should be disabled to allow the connection.

Testing RDP Connectivity to Entra Joined Devices from Standalone Windows Machines

Now let’s see what happens when we try to access an Entra joined device over RDP from a standalone machine that is not Entra joined, Entra hybrid joined, or Entra registered. We will also look at the user experience in this scenario and how a standard Windows device can connect to an Entra joined device without using web account sign-in or Entra authentication.

The same device has now been converted to a standalone machine with no Entra registration or join status. Let’s connect to the Entra joined device over RDP and see the result.

Let’s connect to the Entra joined device. As you can see, we receive an authentication error. Even though the correct UPN format and password are used, the sign-in still fails.

How to Access the Device in This Scenario

In some cases, especially when connecting to a Microsoft Entra joined device from a standalone or workgroup workstation, RDP authentication may fail during the normal pre-authentication stage.

One common workaround is to edit the .rdp file in Notepad and add or modify the following value: enablecredsspsupport:i:0 & authentication level:i:2

To understand why this helps, we need to understand how the normal RDP authentication flow works.

Normal RDP Authentication Flow with CredSSP / NLA

By default, Remote Desktop uses CredSSP together with Network Level Authentication, also known as NLA.

In this flow, the user enters credentials before the full remote desktop session is created.

The process looks like this:

RDP client opens

↓

User enters credentials on the local machine

↓

CredSSP / NLA sends the credentials to the remote PC

↓

The remote PC validates the credentials

↓

Only after successful validation, the RDP session opens

This is why it is called Network Level Authentication.
The user is authenticated before the remote desktop session is fully established.

What Happens with enablecredsspsupport:i:0

When you add this setting:enablecredsspsupport:i:0

you are telling the RDP client: Do not use CredSSP pre-authentication.

So instead of completing the normal NLA/CredSSP authentication before the session starts, the RDP client opens the remote connection first and lets the remote Windows sign-in screen handle the authentication.

The flow becomes:

RDP client opens
↓
RDP transport/session starts
↓
Remote Windows sign-in screen appears
↓
User enters AzureAD\user@domain.com or user@domain.com
↓

The remote Microsoft Entra joined PC validates the account

This is why this setting has commonly been used as a workaround for Microsoft Entra joined devices, especially when the source machine is a standalone or workgroup device.

In simple terms, it avoids failures where the local RDP client is unable to properly process the Microsoft Entra / Azure AD credentials during the pre-authentication stage.

Important Catch

There is an important limitation. When you set: enablecredsspsupport:i:0

you are disabling the newer CredSSP-based RDP security flow.

This can make the connection incompatible with devices that require Network Level Authentication.

So, if the target Microsoft Entra joined device has this option enabled: Require devices to use Network Level Authentication to connect

then this workaround may not work.

That means this method can be useful for testing or specific legacy scenarios, but it should not be considered the preferred production approach.

RDP Connection failed due to NLA Settings

Once Network Level Authentication (NLA) is disabled on the target device and we try to connect again, the RDP session is allowed to open first. 

After that, the remote Windows sign-in screen appears and the user can enter the Microsoft Entra account credentials directly on the remote device.

What Does authentication level:i:2 Do?

Another setting often added along with this workaround is: authentication level:i:2 This setting is about server authentication, not user authentication.

In simple terms, it controls what the RDP client should do if it cannot fully verify the identity or certificate of the remote computer.

With this value: authentication level:i:2

the behavior is:

If the remote computer identity cannot be fully verified, show a warning and allow the user to decide whether to continue or cancel the connection.

So this setting means:

Warn me if the remote PC identity cannot be verified, but still allow me to continue if I trust the device.

This is commonly seen when connecting to standalone, workgroup, or Microsoft Entra joined devices where the RDP certificate may not be issued by a trusted internal Certificate Authority.

It is important to understand that this setting does not authenticate the Microsoft Entra user. It only controls how strictly the RDP client validates the identity of the remote computer.

Together, they make RDP behave more like this:

Connect to the remote PC first, then allow me to enter credentials directly on the remote Windows sign-in screen.

However, this should be used carefully.

 For modern environments, the recommended approach is to use Microsoft Entra authentication for RDP by enabling: enablerdsaadauth:i:1

or selecting: Use a web account to sign in to the remote computer

This provides a better modern authentication experience and allows Microsoft Entra Conditional Access controls to be applied.

RDP Experience Between Two Microsoft Entra Joined Devices Using Windows Hello for Business Without Web Account Sign-In

Now let’s look at the experience when one Microsoft Entra joined device connects to another Microsoft Entra joined device.

In this scenario, the user is signed in to the source device using Windows Hello for Business. Remote Desktop is enabled on the destination device, and Network Level Authentication (NLA) is also enabled.

Now, when the user tries to connect using the normal Remote Desktop client without selecting “Use a web account to sign in to the remote computer”, the authentication experience is different from the modern Entra RDP web sign-in method. Here, the RDP client attempts to complete the standard RDP authentication flow before the remote session opens.

What About Remote Credential Guard?

Remote Credential Guard is often discussed when securing RDP, but it is important to understand where it fits and where it does not.

Remote Credential Guard protects credentials during an RDP session by redirecting Kerberos requests back to the device initiating the connection. This helps ensure that credentials and credential derivatives are not sent to the remote host.

This is very useful when connecting to Active Directory joined servers or workstations, especially for admin access.

But there is a key limitation:

Remote Credential Guard cannot be used when connecting to remote devices that are Microsoft Entra joined.

So, if the target device is Microsoft Entra joined, do not design your RDP access model around Remote Credential Guard.

Helpdesk Support Scenario: Be Careful

For helpdesk teams, the conversation is slightly different.

When support engineers connect to end-user devices, they may use highly privileged credentials. If the target endpoint is already compromised, using a normal RDP session can expose credentials or allow attackers to abuse the session.

Microsoft does not recommend Remote Credential Guard for helpdesk scenarios where personnel require administrative access through RDP. Instead, Microsoft recommends using Restricted Admin mode with the /RestrictedAdmin switch for helpdesk scenarios.

Example: mstsc.exe /RestrictedAdmin

Restricted Admin mode helps ensure that credentials and other user resources are not exposed to a potentially compromised remote host.

To enable RestrictedAdmin mode on Entra Joined device run this command as Local Admin

 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 0 /f

Note: Restricted Admin mode requires local administrator membership on the remote host, add the user to the local Administrators group on the target Entra joined device:

Then restart the device or restart Remote Desktop Services.

Its always recommended implementing Windows LAPS to manage local administrator passwords and reduce the risk of lateral movement caused by shared local admin passwords.

This is very important for Microsoft Entra joined device environments.

A better helpdesk model would be:

• Use Intune Remote Help where possible
• Use least-privilege local admin elevation
• Use Windows LAPS for local admin password management
• Avoid sharing high-privileged cloud credentials into remote sessions
• Use Restricted Admin mode where applicable
• Monitor RDP access events

Recommended Design for Customers

For most modern Microsoft Entra joined Windows environments, I would recommend the following approach.

For User-to-Own Device RDP

Use Microsoft Entra authentication with:

Use a web account to sign in to the remote computer

Make sure:

• Remote Desktop is enabled
• NLA is enabled
• Hostname resolution is working
• The user is allowed in Remote Desktop Users
• Conditional Access is applied to Microsoft Remote Desktop
• IP-based RDP is avoided for this method

This gives a more modern identity-based experience and allows Conditional Access evaluation.

For IT Admin or Helpdesk Access

Do not treat RDP as the first support option.

For helpdesk support, consider:

• Microsoft Intune Remote Help
• Quick Assist, where suitable
• Microsoft Defender for Endpoint Live Response for security operations
• LAPS-managed local admin account for break-glass support
• Restricted Admin mode for RDP-based administrative access where applicable

Avoid using highly privileged Entra ID accounts directly inside a potentially compromised user endpoint(Mainly Global Admin Accounts & Cloud Device Administrator).

Final Thoughts

Remote Desktop to Microsoft Entra joined Windows devices is supported, but it should not be treated exactly like traditional domain-joined RDP.

In the old world, RDP mostly depended on Active Directory, Kerberos, NTLM, local groups, and network reachability.

In the modern Microsoft Entra joined world, RDP depends more on cloud identity, supported Windows builds, device join state, hostname resolution, Conditional Access, and proper local authorization.

For most organizations moving towards Microsoft Entra joined Windows devices, the best approach is:

Use Microsoft Entra authentication for standard RDP scenarios, enforce Conditional Access, avoid IP-based RDP, manage Remote Desktop Users through Intune, and use LAPS or Restricted Admin mode for secure helpdesk scenarios.

Microsoft Entra joined devices do not remove the ability to use RDP. They simply change the way we should design, secure, and manage it.