Using Azure MFA cloud based protection with the RD Gateway


Last week Microsoft released Azure MFA cloud based protection from your on premise servers/devices. In this blogpost Microsoft announced this functionality and showed how this can be used with a VPN device. Before yesterday you had to install the Azure MFA server to provide MFA to RDS sessions through the RD Gateway. Since the MFA Server and the cloud based MFA were different systems with different settings for users this was not the most ideal situation. But with this new functionality we can use the cloud based MFA for the RD Gateway role. If you’re looking for a detailed description about how to setup the RD Gateway with the on premise MFA servers please check this blogpost.

This blogpost focuses on setting up the new public preview NPS extension to provide cloud based MFA to the RD Gateway role. Note that this extension is currently in public preview. This post focusses on a HA RD Gateway server configuration. The overall infrastructure and configuration will look like this:

The following actions need to be executed to configure the above scenario:

  1. Install a new server if you don’t have a central NPS Server and install NPS through Windows Roles and Features;
  2. Create a Connection Request Policy and a Network Policy (Copy the settings of the policies from the original NPS configuration on the RD Gateway);

  3. Add both of your RD Gateway servers as RADIUS client on your Central NPS Server:

  4. Configure both RD Gateway servers to use the NPS server as the central NPS Server;
  5. Important: Test if the primary authentication configuration works, if it works continue with the next step;
  6. Then download the plugin from this location:;
  7. Install the AzureAD Powershell cmdlets (V1.1.166.0) by downloading and installing the following file: Note that you this functionality is not working with the 2.0 PowerShell cmdlets.
  8. Copy the downloaded bits to your RD Gateway Server. Start the ‘NpsExtnForAzureMfaInstaller.msi’ for installing the extension.
  9. Click on the Install button:

  10. Start a new Powershell screen as Administrator and go to the following location: C:\Program Files\Microsoft\AzureMfa\Config
  11. Execute the following script which will completes the installation. This script will execute the following actions:
    1. Create a self-signed certificate.
    2. Associate the public key of the certificate to the service principal on Azure AD.
    3. Store the cert in the local machine cert store.
    4. Grant access to the certificate’s private key to Network User.
    5. Restart the NPS.

    You will need your Azure Active Directory TenantID, this can be found in the properties blade of Azure Active Directory in the new Azure portal:

    The output of the script looks like this:

This is it! Now logon with a user which is synced through AzureAD Connect to AzureAD and configured for Azure Cloud MFA. The user should get a MFA request and on the NPS server you should see the following event logged:

I want to finalize this blogpost with some handy information regarding this solution:

Disable NPS MFA Extension

  1. Stop the Network Policy Server Service
  2. Create a backup of the key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters’
  3. Remove the values inside this key (DO NOT the Parameters key itself)
  4. Start the Network Policy Server Service

Re-Enable the NPS MFA Extension

  1. Stop the Network Policy Server Service
  2. Import the backup of the key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters’
  3. Start the Network Policy Server Service

If the MFA request is not successful or not send to the user check the following:

  1. The user is synced through AzureAD connect to Azure Active Directory
  2. Azure MFA is enabled on the user and the user has configured his profile within AzureAD MFA
  3. Preferred Authentication method is set

Prepare for users that aren’t enrolled for MFA

If you have users that aren’t enrolled for MFA, you can determine what happens when they try to authenticate. Use the registry setting REQUIRE_USER_MATCH in the registry path HKLM\Software\Microsoft\AzureMFA to control the feature behavior. This setting has a single configuration option:



Not set (equivalent to TRUE)


When the key does not exist, is not set, or is set to TRUE, and the user is not enrolled, then the extension fails the MFA challenge. When the key is set to FALSE and the user is not enrolled, authentication proceeds without performing MFA.

Leave a Reply