Sign in to Windows virtual machine in Azure using Microsoft Entra ID and Azure Roles Based Access Control

Organizations can improve the security of Windows Server virtual machines in Azure by integrating with Microsoft Entra authentication. You can now use Microsoft Entra ID as a core authentication platform to Remote Desktop Protocol (RDP) into supported versions of Windows Server. You can then centrally control and enforce Azure role-based access control (RBAC) and Conditional Access policies that allow or deny access to the virtual machines.

This article shows you how to create and configure a Windows Server virtual machine and sign in by using Microsoft Entra ID-based authentication.

There are many security benefits of using Microsoft Entra ID-based authentication to sign in to Windows Server virtual machines in Azure. They include:

• Use Microsoft Entra authentication including passwordless to sign in to Windows Server virtual machines. Reduce reliance on local administrator accounts.
• Use Password complexity and password lifetime policies that you configure for Microsoft Entra ID also help secure Windows Server virtual machines.
• Use Azure role-based access control:
  • Specify who can sign in as a regular user or with administrator privileges.
  • When users join or leave your team, you can update Azure role-based access control policy to grant access as appropriate.
  • When employees leave your organization and their user accounts are disabled or removed from Microsoft Entra ID, they no longer have access to your resources.
• Use Conditional Access policy "phishing resistant MFA" and other signals such as user sign-in risk.
• Use Azure Policy to deploy and audit policies to require Microsoft Entra sign in for Windows Server virtual machines and to flag the use of unapproved local accounts on the virtual machines.
• Use Intune to automate and scale Microsoft Entra join with mobile device management (MDM) autoenrollment of Azure Windows VMs that are part of your virtual desktop infrastructure (VDI) deployments. MDM autoenrollment requires Microsoft Entra ID P1 licenses.

MDM autoenrollment requires Microsoft Entra ID P1 licenses. Windows Server VMs don't support MDM enrollment.

Requirements

Supported Azure regions and Windows distributions

This feature currently supports the following Windows Server distributions:

• Windows Server 2025 or later installed with Desktop Experience.

This feature is now available in the following Azure clouds:

• Azure Global
• Azure Government
• Microsoft Azure operated by 21Vianet

Network requirements

To enable Microsoft Entra authentication to virtual machines in Azure, you need to ensure that your network configuration permits outbound access to the following endpoints over TCP port 443.

Azure Global:

• https://enterpriseregistration.windows.net: Device registration.

• http://169.254.169.254: Azure Instance Metadata Service endpoint.

• https://login.microsoftonline.com: Authentication flows.

• https://pas.windows.net: Azure role-based access control flows.

Azure Government:

• https://enterpriseregistration.microsoftonline.us: Device registration.

• http://169.254.169.254: Azure Instance Metadata Service endpoint.

• https://login.microsoftonline.us: Authentication flows.

• https://pasff.usgovcloudapi.net: Azure role-based access control flows.

Microsoft Azure operated by 21Vianet:

• https://enterpriseregistration.partner.microsoftonline.cn: Device registration.

• http://169.254.169.254: Azure Instance Metadata Service endpoint.

• https://login.chinacloudapi.cn: Authentication flows.

• https://pas.chinacloudapi.cn: Azure role-based access control flows.

Authentication requirements

• User account type: Only standard Microsoft Entra user accounts from the same tenant as the azure windows virtual machine are supported. Guest accounts (B2B users) cannot be used for authentication.

• Managed identities: You must enable system-assigned managed identity on your Azure virtual machine before installing the Microsoft Entra sign in virtual machine extension. Managed Identities are stored in a single Microsoft Entra tenant and currently don't support cross directory scenarios.

• Role assignments: Users must be assigned either the Virtual Machine Administrator Login or Virtual Machine User Login role to sign in to the VM. Having the Owner or Contributor role alone doesn't grant sign-in privileges.

• Virtual Machine Administrator Login: Users who have this role assigned can sign in to an Azure virtual machine with administrator privileges.

• Virtual Machine User Login: Users who have this role assigned can sign in to an Azure virtual machine with regular user privileges.

• Authentication methods:

  • Passwordless authentication is recommended and supported via Microsoft Entra credentials
  • Password-based authentication is supported with proper role assignments
  • Windows Hello for Business is supported using the certificate trust model only (not key trust model)
  • Local administrator accounts created manually by adding users to local groups aren't supported

Enable Microsoft Entra sign in for a Windows virtual machine in Azure

To use Microsoft Entra sign in for a Windows virtual machine, you must:

1. Enable the Microsoft Entra sign in extension for the device.
2. Configure Azure role assignments for users.

Enable Microsoft Entra sign in extension

• Azure virtual machine running Windows

You must enable system-assigned managed identity on your Azure virtual machine before you install the Microsoft Entra sign in virtual machine extension. Managed Identities are stored in a single Microsoft Entra tenant and currently don't support cross directory scenarios.

The following sample demonstrates Azure templates for Azure Virtual Machine extensions.

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vmName": {
      "type": "string"
    },
    "location": {
      "type": "string"
    }
  },
  "resources": [
    {
      "name": "[concat(parameters('vmName'),'/AADLogin')]",
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "location": "[parameters('location')]",
      "apiVersion": "2015-06-15",
      "properties": {
        "publisher": "Microsoft.Azure.ActiveDirectory",
        "type": "AADLoginForWindows",
        "typeHandlerVersion": "1.0",
        "autoUpgradeMinorVersion": true
      }
    }
  ]
}

Configure role assignments

To assign user roles, you must have the Virtual Machine Data Access Administrator role, or any role that includes the Microsoft.Authorization/roleAssignments/write action such as the Role Based Access Control Administrator role. However, if you use a different role than Virtual Machine Data Access Administrator, we recommend you add a condition to reduce the permission to create role assignments.

• Virtual Machine Administrator Login: Users who have this role assigned can sign in to an Azure virtual machine with administrator privileges.
• Virtual Machine User Login: Users who have this role assigned can sign in to an Azure virtual machine with regular user privileges.

The following documentation provides step-by-step details to add user accounts to role assignments in Azure:

• Assign Azure roles by using the Azure portal
• Assign Azure roles by using the Azure CLI
• Assign Azure roles by using Azure PowerShell

Sign in by using Microsoft Entra credentials to a Windows VM

You can sign in over RDP using one of two methods:

• Passwordless using any of the supported Microsoft Entra credentials (recommended)
• Password/passwordless using Windows Hello for Business deployed using certificate trust model

Sign in using passwordless authentication with Microsoft Entra ID

To use passwordless authentication for your Windows Server VMs in Azure, the session host (VM) must be running:

• Windows Server 2022 with 2022-10 Cumulative Update for Microsoft server operating system (KB5018421) or later installed.
• Windows Server 2025 or later installed.

To connect to the remote computer:

• Launch Remote Desktop Connection from Windows Search, or by running mstsc.exe.
• Select Use a web account to sign in to the remote computer option in the Advanced tab. This option is equivalent to the enablerdsaadauth RDP property. For more information, see Supported RDP properties with Remote Desktop Services.
• Specify the name of the remote computer and select Connect.

• When prompted for credentials, specify your user name in user@domain.com format.
• You're then prompted to allow the remote desktop connection when connecting to a new PC. Microsoft Entra remembers up to 15 hosts for 30 days before prompting again. If you see this dialogue, select Yes to connect.

Sign in using password/passwordless authentication with Microsoft Entra ID

Both Password-based authentication, and Passwordless authentication are supported to sign in to Windows virtual machines.

To sign in to your Windows Server 2019 virtual machine by using Microsoft Entra ID:

1. Go to the overview page of the virtual machine enabled with Microsoft Entra sign in.
2. Select Connect to open the Connect to virtual machine pane.
3. Select Download RDP File.
4. Select Open to open the Remote Desktop Connection client.
5. Select Connect to open the Windows sign in dialog.
6. Sign in by using your Microsoft Entra credentials.

You're now signed in to the Windows Server 2019 Azure virtual machine with the role permissions as assigned, such as VM User or VM Administrator.

Enforce Conditional Access policies

You can enforce Conditional Access policies, such as "phishing resistant MFA" or user sign-in risk check, before users can access Windows Server virtual machines in Azure. To apply a Conditional Access policy, you must select the Microsoft Azure Windows Virtual Machine Sign-in app from the cloud apps or actions assignment option.

Conditional Access policies that restrict sign in using device configuration rules aren't supported when connecting from a Windows Server device. For a guide on setting conditional access policies, see: Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication.

Use Azure Policy to meet standards and assess compliance

Use Azure Policy to:

• Ensure that Microsoft Entra sign in is enabled for your new and existing Windows Server virtual machines.
• Assess compliance of your environment at scale on a compliance dashboard.

With this capability, you can use many levels of enforcement. You can flag new and existing Windows Server virtual machines within your environment that don't have Microsoft Entra sign in enabled. You can also use Azure Policy to deploy the Microsoft Entra extension to Windows virtual machines in Azure.

In addition to these capabilities, you can use Azure Policy to detect and flag Windows machines that have unapproved local accounts created on their devices. To learn more, review Azure Policy.

Troubleshoot deployment problems

The AADLoginForWindows extension must be installed successfully for the device to complete the Microsoft Entra join process. If the extension fails to be installed correctly, perform the following steps:

1. Connect to the device and examine the CommandExecution.log file under C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\1.0.0.1.

   If the extension restarts after the initial failure, the log with the deployment error will be saved as CommandExecution_YYYYMMDDHHMMSSSSS.log.

2. Open a PowerShell window on the device. Verify that the following queries against the Azure Instance Metadata Service endpoint running on the host return the expected output:

   For Azure virtual machines:

   Command to run	Expected output
   curl.exe -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2017-08-01"	Correct information about the Azure virtual machine
   curl.exe -H Metadata:true "http://169.254.169.254/metadata/identity/info?api-version=2018-02-01"	Valid tenant ID associated with the Azure subscription
   curl.exe -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2018-02-01"	Valid access token issued by Microsoft Entra ID for the managed identity that is assigned to this virtual machine

3. Ensure that the required endpoints are accessible from the device via PowerShell:

   • curl.exe https://login.microsoftonline.com/ -D -
   • curl.exe https://login.microsoftonline.com/<TenantID>/ -D -
   • curl.exe https://enterpriseregistration.windows.net/ -D -
   • curl.exe https://device.login.microsoftonline.com/ -D -
   • curl.exe https://pas.windows.net/ -D -

   Replace <TenantID> with the Microsoft Entra tenant ID associated with the Azure subscription. login.microsoftonline.com/<TenantID>, enterpriseregistration.windows.net, and pas.windows.net should return 404 Not Found, which is expected behavior.

4. View the device state by running dsregcmd /status. The goal is for the device state to show as AzureAdJoined : YES.

   Microsoft Entra join activity is captured in Event Viewer under the User Device Registration\Admin log at Event Viewer (local)\Applications and Services Logs\Microsoft\Windows\User Device Registration\Admin.

If the AADLoginForWindows extension fails with an error code, you can perform the following steps.

Device name already exists

If a device object with the same displayName as the hostname of the Azure virtual machine exists, the device fails to join Microsoft Entra with a hostname duplication error. Avoid duplication by modifying the hostname.

Terminal error code 1007 and exit code -2145648574

Terminal error code 1007 and exit code -2145648574 translate to DSREG_E_MSI_TENANTID_UNAVAILABLE. The extension can't query the Microsoft Entra tenant information.

Connect to the device as a local administrator and verify that the endpoint returns a valid tenant ID from Azure Instance Metadata Service. Run the following command from an elevated PowerShell window on the device:

curl -H Metadata:true http://169.254.169.254/metadata/identity/info?api-version=2018-02-01

This problem can also happen when the admin attempts to install the AADLoginForWindows extension, but the device doesn't have a system-assigned managed identity. In that case, go to the Identity pane of the device. On the System assigned tab, verify that the Status toggle is set to On.

Exit code -2145648607

Exit code -2145648607 translates to DSREG_AUTOJOIN_DISC_FAILED. The extension can't reach the https://enterpriseregistration.windows.net endpoint.

1. Verify that the required endpoints are accessible from the device via PowerShell:

   • curl https://login.microsoftonline.com/ -D -
   • curl https://login.microsoftonline.com/<TenantID>/ -D -
   • curl https://enterpriseregistration.windows.net/ -D -
   • curl https://device.login.microsoftonline.com/ -D -
   • curl https://pas.windows.net/ -D -

   Replace <TenantID> with the Microsoft Entra tenant ID of the Azure subscription. If you need to find the tenant ID, you can hover over your account name or select Entra ID > Overview > Properties > Tenant ID.

   Attempts to connect to enterpriseregistration.windows.net might return 404 Not Found, which is expected behavior. Attempts to connect to pas.windows.net might prompt for PIN credentials or might return 404 Not Found. (You don't need to enter the PIN.) Either one is sufficient to verify that the URL is reachable.

2. If any of the commands fails with "Couldn't resolve host <URL>," try running this command to determine which DNS server Windows is using:

   nslookup <URL>

   Replace <URL> with the fully qualified domain names that the endpoints use, such as login.microsoftonline.com.

3. See whether specifying a public DNS server allows the command to succeed:

   nslookup <URL> 208.67.222.222

4. If necessary, change the DNS server assigned to the network security group that the device belongs to.

Exit code 51

Exit code 51 translates to "This extension isn't supported on this operating system."

The AADLoginForWindows extension is intended to be installed only on Azure virtual machines with Windows Server 2022 or later operating systems. Ensure that your version of Windows Server is supported. If it isn't supported, uninstall the extension.

Troubleshoot sign-in problems

Use the following information to correct sign-in problems.

You can view the device and single sign-on (SSO) state by running dsregcmd /status. The goal is for the device state to show as AzureAdJoined : YES and for the SSO state to show AzureAdPrt : YES.

RDP sign-in via Microsoft Entra accounts is captured in Event Viewer under the Applications and Services Logs\Microsoft\Windows\AAD\Operational event logs.

Azure role not assigned

You might get the following error message when you initiate a remote desktop connection to your device: "Your account is configured to prevent you from using this device. For more info, contact your system administrator."

Verify the Azure role-based access control policies that grant the user the Virtual Machine Administrator Login or Virtual Machine User Login role.

If you're having problems with Azure role assignments, see Troubleshoot Azure role-based access control.

Unauthorized client or password change required

You might get the following error message when you initiate a remote desktop connection to your device: "Your credentials didn't work."

Try these solutions:

• The client device that you're using to initiate the remote desktop connection must be Microsoft Entra joined, or Microsoft Entra hybrid joined to the same Microsoft Entra directory. For more information about device identity, see the article What is a device identity?.

  A Microsoft Entra registered client device is also supported to initiate an RDP connection to your virtual machine. When you're using a client device that's Microsoft Entra registered (not Microsoft Entra joined or Microsoft Entra hybrid joined) as the RDP client to initiate connections to your virtual machine, you must enter credentials in the format AzureAD\UPN (for example, AzureAD\john@contoso.com).

  Verify that the AADLoginForWindows extension wasn't uninstalled after the Microsoft Entra join finished.

  Also, make sure that the security policy Network security: Allow PKU2U authentication requests to this computer to use online identities is enabled on both the server and the client.

• Verify that the user doesn't have a temporary password. Temporary passwords can't be used to sign in to a remote desktop connection.

  Sign in with the user account in a web browser. For instance, sign in to the Azure portal in a private browsing window. If you're prompted to change the password, set a new password. Then try connecting again.

AADSTS293004: The target-device identifier in the request xxx wasn't found in the tenant xxx

Cause:

The computer name entered in mstsc doesn't match with any one of the "hostnames" attributes for target AADJ device. For example, AADJ device host name is the short name like device_1, but the computer name entered in mstsc is the FQDN like device_1.contoso.com.

Try these solutions:

There are multiple ways to resolve the issue:

1. Modify the HOSTS entry on client machine, add an A DNS record that points the correct device name (confirm from AAD Device record) to the IP of target machine. Use that device name in mstsc.
2. Check if the target machine is managed and if the hostname is set through Group Policy or MDM via the DNS Client PrimaryDnsSuffix value ADMX_DnsClient Policy CSP | Microsoft Learn. If this is set and is incorrect, it needs to be removed or set correctly.
3. When customer requires to use FQDN to connect but AAD Device name is a short name, login to the target machine via local admin, add a “Primary DNS Suffix” for their domain suffix. Detailed instructions:

• Navigate to Advanced System Settings/System Properties ->** Computer Name** tab -> select the "Change" button to rename the computer -> select "More..." under the existing computer name -> Type in your domain name and select OK -> Save and reboot.
• Once it’s done, we can RDP with FQDN directly and no need to modify the HOSTS entry.

MFA sign-in method required

You might see the following error message when you initiate a remote desktop connection to your device: "The sign-in method you're trying to use isn't allowed. Try a different sign-in method or contact your system administrator."

If you configure a Conditional Access policy that requires MFA, you need to ensure that the device initiating the connection uses strong authentication such as Windows Hello.

Another MFA-related error message is the one described previously: "Your credentials didn't work."

If you configure a legacy per-user Enabled/Enforced Microsoft Entra multifactor authentication setting and you see the error, you can resolve the problem by removing the per-user MFA setting. For more information, see the article Enable per-user Microsoft Entra multifactor authentication to secure sign-in events.

If Windows Hello for Business isn't an option, configure a Conditional Access policy that excludes the Microsoft Azure Windows Virtual Machine Sign-in app. To learn more about Windows Hello for Business, see Windows Hello for Business overview.

Using Windows Hello for Business authentication during RDP is available for deployments that use a certificate trust model or key trust model.

Share your feedback about this feature or report problems with using it on the Microsoft Entra feedback forum.

Missing application

If the Microsoft Azure Windows Virtual Machine Sign-in application is missing from Conditional Access, make sure that the application is in the tenant:

1. Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
2. Browse to Entra ID > Enterprise apps.
3. Remove the filters to see all applications, and search for VM. If you don't see Microsoft Azure Windows Virtual Machine Sign-in as a result, the service principal is missing from the tenant.

Another way to verify it is via Graph PowerShell:

1. Install the Graph PowerShell SDK.
2. Run Connect-MgGraph -Scopes "ServicePrincipalEndpoint.ReadWrite.All", followed by "Application.ReadWrite.All".
3. Sign in with a Global Administrator account.
4. Consent to the permission prompt.
5. Run Get-MgServicePrincipal -ConsistencyLevel eventual -Search '"DisplayName:Azure Windows VM Sign-In"'.

   • If this command results in no output and returns you to the PowerShell prompt, you can create the service principal with the following Graph PowerShell command:

     New-MgServicePrincipal -AppId 372140e0-b3b7-4226-8ef9-d57986796201

   • Successful output shows that the Microsoft Azure Windows Virtual Machine Sign-in app and its ID were created.

6. Sign out of Graph PowerShell by using the Disconnect-MgGraph command.

Some tenants might see the application named Azure Windows VM Sign-in instead of Microsoft Azure Windows Virtual Machine Sign-in. The application has the same Application ID of 372140e0-b3b7-4226-8ef9-d57986796201.

Unable to use this capability when require compliant device Conditional Access policy is enforced on Azure Windows VM Sign-in resource and you're connecting from a Windows Server device

Windows Server device compliance configuration in Conditional Access policy isn't supported.

Next steps

For more information about Microsoft Entra ID, see What is Microsoft Entra ID?.