Microsoft Entra ID multi-factor authentication in RDP

June 28, 2024

Introduction

Microsoft Entra ID, formerly known as Azure Activate Directory (AAD), is replacing classic on-premise Active Directory installations slowly but surely. It replaces “legacy” protocols such as LDAP and Kerberos with “modern” protocols such as SAML, OIDC and OAuth2. However, the client-side support in various operating systems such as Windows, Linux and MacOS is spotty, to say the least. You can make things work, but only if the stars (or rather, bits) are aligned just right. This article explains how multi-factor authentication in RDP works with Azure VMs when using Microsoft Entra ID. Note the emphasis on MFA: without MFA you can make logins with Entra ID work more easily by using the normal username + password authentication in RDP.

If you’re interested in Microsoft Entra ID authentication options for Linux VMs please have a look at this article.

Terminology

Some of the key terms in this article are:

Microsoft Entra ID: the identity provider formerly known as “Azure Active Directory”. Integrated with Azure.
MFA: multi-factor authentication.
Security defaults: set of default security settings in Azure which are probably(?) turned on by default on new Azure accounts and includes mandatory MFA for all users. Security defaults can be turned on and off in Microsoft Entra admin center which is similar, but not identical to the Microsoft Entra ID you can find from Azure Portal. Nor is it the same thing as Microsoft Intune, which looks deceptively similar to both of them.
Mstsc.exe: the “classic” remote desktop client built-in into Windows. The name is derived from “Microsoft Terminal Services Client” and predates the invention of the term Remote Desktop (RDP).
Windows Store Remote Desktop app: a “modern” remote desktop client for Windows.
Azure Windows VM: the Azure Windows VM you wish to login to with RDP.
Workstation: the laptop or desktop you’re connecting with RDP from.

Assumptions

We make the following assumptions in this article:

You wish to use Microsoft Entra ID multi-factor authentication in RDP when logging in to your Azure Windows VMs.
Your Microsoft Entra ID uses Security Defaults or otherwise forces multi-factor authentication (MFA) for all users.
You’re not willing to turn off MFA just to login to use Microsoft Entra ID authentication (a sane policy, I might add).
You wish to use the classic “Remote Desktop Connection” Windows application (mstsc.exe).

This use-case is so common that is should be trivial to do, right?

You would think so, but nothing could be farther from the truth. In the classic Microsoft style all the documentation you need seems to be or is there, but you still have to fight your way through a jungle to get it to work. For me the main culprit was the confusing terminology used in the official documentation:

Passwordless authentication with Microsoft Entra ID: this refers to Microsoft Entra ID authentication that is not just plain password authentication. If you have MFA enabled (e.g. through Security Defaults) then your are doing “Passwordless authentication” even if you do use a password coupled with another factor such as Microsoft Authenticator app.
Password/limited passwordless authentication with Microsoft Entra ID: this refers to normal password-only authentication. If you have not enabled MFA in Entra ID, you should be able to RDP in with username (e.g. ".\AzureAD\john.doe@acme.org") and password, just as if you had a local user on the VM.

The requirements for these two use-cases are very different. In this article we’re interested in what Microsoft calls “Passwordless authentication with Microsoft Entra ID”, but what should probably be called “Multi-factor authentication with Microsoft Entra ID”. The login workflow in that case a web-based one, essentially the same as what you’d use to login to, say, Microsoft 365.

Making Windows Microsoft Entra ID login with MFA work for Azure Windows VMs is moderately easy to do after you know what you need to do. Hopefully this article helps make the process less painful for other poor souls who have been tasked to do the same thing I was tasked with.

Requirements for multi-factor authentication in RDP

Microsoft has kindly provided a detailed article which contains most of the steps we need.:

I don’t want to waste space by repeating what is said in that article, but a summary is nevertheless in order:

The Workstation connecting to the Azure VM needs to be registered or joined to Microsoft Entra ID.
Normal users should have the “Virtual Machine User Login” role in Microsoft Entra ID.
Admin users should have the “Virtual Machine Administrator Login” role in Microsoft Entra ID.
The Azure AD (Microsoft Entra ID) login extension needs to be enabled on the Azure VM.
- It is best to enable this at VM creation.
- Installing it afterwards is possible, but you need to make sure you install the correct plugin version to avoid failures and debugging.
- This extensions joins the Azure VM to Microsoft Entra ID (look under “Devices”)
The Microsoft Entra ID login/metadata endpoints need to be reachable from the Azure VM.
The RDP configuration file needs to be modified (see below)
DNS zones and records, Azure VM name and Workstation’s DNS settings need to be configured properly
Guest accounts can’t be used to login to Azure VMs with Microsoft Entra ID authentication

We’ll cover a few of the more interesting and challenging topics below.

Creating the mstsc.exe configuration file

When in Azure Portal go to the Azure VM you’re interested in, click on Connect -> Connect -> Download RDP file. This file will not work as-is for Microsoft Entra ID authentication, but is a reasonable basis for our modifications. The file Azure gives you by default looks like this:

full address:s:10.50.0.10:3389 
prompt for credentials:i:1 
administrative session:i:1
username:s:adminuser

For an admin users you need to change the RDP config file to look like this:

full address:s:azure-vm:3389
prompt for credentials:i:1
enablerdsaadauth:i:1

The first important part here are the hostname (here: azure-vm) which must not be a fully-qualified domain name (e.g. azure-vm.contoso.com). The second important part is the enablerdsaadauth setting which must be set to 1 to enable Microsoft Entra ID (that is, Azure AD/AAD) authentication. The rest of the RDP configuration settings are optional (look here for a reference).

The VM extension that joins the Azure VM to Microsoft Entra ID is one major source of problems. I noticed that if you install the extension as per official instructions with Powershell I got a newer version of the extension (2.x) than what I got when I enabled Entra ID authentication when creating the VM (1.3.0.0). This newer 2.x version did not join the Azure VM to Entra ID, which in turn meant that logging in to it with Microsoft Entra ID + MFA did not work, either.

So, my advise is to immediately verify from Microsoft Entra ID “Devices” pane that the Azure VM is listed there as “Microsoft Entra joined”. If it is not, follow the VM extension troubleshooting steps in here. If you see any messages that tell that joining to AAD (Microsoft Entra ID) failed then replace the extension with some other (older) version and see what happens.

Domain search suffixes, Azure VM name and Microsoft Entra ID device name

This is where the fun stuff really begins. As noted above the Azure VM needs to be referred to with just its hostname in the RDP (mstsc.exe) configuration file. You cannot use the fully-qualified domain name. This is because the hostname (azure-vm, above) is used by Microsoft Entra ID to locate a matching joined Device name.

So, it is not enough to have A/AAAA records in DNS for you Azure VM. Instead, you need to be able to resolve hostnames to IPs without their domain suffixes. For example in the above case you must be able to connect to azure-vm. If you need to use azure-vm.acme.org to connect then tinker some more. And no, you cannot “fix” the issue by renaming the Azure VM so that it contains the domain name (e.g. azure-vm.acme.org), because:

You cannot (trivially) rename Azure VMs
Azure VM names can’t have dots in them

In an office environment you should configure your router to push DHCP option 135 (domain search list) with the proper domain search suffix.

Connecting through an Azure VPN Gateway

You can connect to Azure VMs with RDP through an OpenVPN-based Azure VPN Gateway. The only special requirement is that the domain search suffix needs to be configured by the Azure VPN client. Basically you need to get the client configuration ZIP file from Azure Portal, extract it and edit the AzureVPN\azurevpnconfig_aad.xml to include the domain search suffixes and DNS servers:

<clientconfig>
--- snip ---
  <dnsservers>
    <DnsServerEntry>
      <dnsserver>10.100.50.11</dnsserver>
    </DnsServerEntry>
    <DnsServerEntry>
      <dnsserver>10.100.50.12</dnsserver>
    </DnsServerEntry>
  </dnsservers>
  <dnssuffixes>
    <dnssuffix>.acme.org</dnssuffix>
  </dnssuffixes>
--- snip ---
</clientconfig>

This assumes that the two DNS forwarders (10.100.50.11 and 10.100.50.12) are configured so that VPN client can resolve private DNS zones (here: acme.org) though the VPN. Without proper DNS setup your client can’t resolve either hostnames or fully-qualified names, and you have bigger issues than Microsoft Entra ID authentication. For details about this have a look at the VPN client configuration documentation.

Once the client configuration file is edited it needs to be re-imported to Azure VPN client.

Things you don’t need to do

The Internet is full of anecdotes about what you should do when you enable Microsoft Entra ID authentication for an Azure VM. Few if any of those work. Here’s a non-exhaustive list of things you don’t need to do:

Adding the following to mstsc.exe’s config file only makes things worse (one example source here)
- username:s:.\AzureAD\YOURNAME@YOURDOMAIN.com
- enablecredsspsupport:i:0
- authentication level:i:2
Disabling NLA (“Network Level Authentication”) on the Azure VM.
- In the best case it does not help at all
- In the worst case this may actually prevent Azure Windows login with Microsoft Entra ID logins and MFA completely
Logging in to your Workstation with your organization’s Microsoft Entra ID credentials
- You can do this, but it is not required to connect to the Azure VM using your organization
Logging in to Azure VPN Gateway with your organization’s Microsoft Entra ID credentials, should you use it
- Any network connection through Azure VPN Gateway will be fine

What if I don’t have MFA enabled in Microsoft Entra ID?

Well, you should definitely have MFA enabled for security reasons. But if you don’t, then you’re you’re using what Microsoft calls “password” login. That works without setting the enablerdsaadauth in mstsc.exe configuration file. If you wish to set the username in the config then you probably have to use the .\AzureAD\username@domain.com syntax, but I have not tested it myself.

External links

Deep-Dive

Azure