Logging Into Azure VMs with Microsoft Entra Credentials

The default approach to accessing Windows virtual machines in Azure — local accounts or domain credentials with a password — works, but it creates credential management overhead and doesn’t leverage the identity infrastructure most organizations already have in place. Authenticating with Microsoft Entra credentials instead centralizes access control, integrates with Conditional Access policies, and supports MFA without requiring additional tooling.

The setup involves a few moving parts, particularly when MFA is in play. This post walks through the full configuration.

Entra-based login is enabled through a VM extension. It can be added during VM creation or applied to an existing VM.

During VM creation — On the Management tab of the creation wizard, enable Login with Microsoft Entra ID. This also selects the system-assigned managed identity option, which is required.

On an existing VM — Navigate to the VM, go to Settings → Extensions + applications, and click Add. Search for Azure AD-based Windows Login, select it, and complete the installation. The extension will appear as either AADLoginForWindows or AADLogin depending on how it was installed.

If the extension shows an available update, select it and apply the update before proceeding.

Step 2: Enable System-Assigned Managed Identity

The extension relies on a system-assigned managed identity to authenticate the VM with Entra. To verify or enable it, navigate to the VM and go to Security → Identity. If the status is Off, toggle it to On and save.

Step 3: Assign the Correct Role

Users need one of two role assignments to log in with Entra credentials:

Virtual Machine User Login — Grants access as a standard user
Virtual Machine Administrator Login — Grants access with local administrator rights

These roles can be assigned directly to individual users on the specific VM, or applied to a group and inherited. They can also be inherited from assignments at the subscription, resource group, or management group level.

To check whether a user has the right role, go to the VM’s Access Control (IAM) tab and use Check Access to search for the user. If neither role appears in the results, that user won’t be able to log in with Entra credentials regardless of other permissions they may hold.

Step 4: Configure the RDP File

This is where most of the manual configuration lives. Azure’s Entra login requires a specific RDP file format — the standard downloaded file won’t work as-is.

Download the RDP file by navigating to Connect → Connect on the VM and clicking Download RDP file. Open the file in any text editor. It will look something like this:

full address:s:XXX.XXX.XXX.XXX:3389
prompt for credentials:i:1
administrative session:i:1
Username:s:admin username

Two changes are required:

Replace the IP address in full address with the VM name — Azure’s Entra authentication requires the VM name, not an IP address or FQDN. The VM name can be found on its Overview page.
Replace the username with the user’s UPN — The format is username@domain.com.

Then add the following line at the end of the file:

Enablerdsaadauth:i:1

The completed file should look like this:

full address:s:AzureVMName:3389
prompt for credentials:i:1
administrative session:i:1
username:s:username@domain.com
Enablerdsaadauth:i:1

Step 5: Update the Hosts File

Because the RDP file now references the VM by name rather than IP address, the local machine needs a way to resolve that name. Azure VMs don’t have public DNS records by default, so the resolution has to be added manually.

The hosts file on Windows is located at C:\Windows\System32\drivers\etc\hosts. Open it with a text editor running as administrator and add a line at the end in the format:

XXX.XXX.XXX.XXX  AzureVMName

Use the public IP address of the VM (or private IP if connecting over VPN), followed by the VM name exactly as it appears in the RDP file.

With that in place, running the modified RDP file will prompt for Entra credentials and, if MFA is configured, the user’s MFA method as well.

Closing Thoughts

Entra-based VM login eliminates local credential sprawl and brings VM access under the same identity and policy controls used for everything else in the tenant. The process has more manual steps than setting up a local account, but it only needs to be done once per VM — and the RDP file can be distributed to users without any further changes on their end.

For environments where MFA is enforced (which should be most environments), this approach integrates cleanly without requiring any exemptions or workarounds.