azure mfa for rdg

Remote Desktop Gateway client two-factor authentication via Azure Multi-Factor Authentication

Users and Security Methods

Typical users have a lightminded attitude for password security. Our experience shows that even if a company uses strict policies, provides user training, etc., unencrypted devices still make their way outside the office. Review the product list of a well-known company, and you will understand that cracking passwords for unencrypted devices is only a matter of time.

In order to control cloud access from these devices, some companies block remote access by setting up tunnels between the cloud and the office. We believe that this is not the optimal solution. First, you lose some advantages of cloud solutions. And secondly, as noted in the article, there are productivity issues.

Using a terminal server and Remote Desktop Gateway (RDG) is more flexible, because you can set up a high level of security. This method lets you prevent transmitting data from the cloud, and you can simultaneously impose limitations on a user’s work. However, this doesn’t solve the problem of authentication, which is a DLP solution.

Two-factor authentication is probably the best way to guarantee that an intruder doesn’t work under a user’s account. The MFA setup provided by Microsoft and Google for client VPNs is a good choice, but 1) it requires CISCO ASA, which is not always easy to implement, especially in budget-conscious clouds and 2) working via a VPN is inconvenient. Working with a terminal session via RDG is significantly more convenient, and the SSL encryption protocol seems to be more universal and reliable than a CISCO VPN.

There are many solutions for a terminal server with two-factor authentication. For example, here is a free solution . Unfortunately, this solution does not work via RDG.

The advantages of the Microsoft Azure Multi-Factor Authentication Server (MFAS) are described in the article mentioned above, so I won’t repeat them here. Instead, let’s directly with the settings.

To keep this article short, we will skip the process for initial installation and configuration of the RDG server that authorizes users based on a username and password.

For clarity, we will outline the RDG request authentication scheme used by Azure MFA. The Network Policy Server (NPS) role is started on the RDG server, making it possible to redirect Radius requests. The MFA server will be deployed on a separate virtual machine in the company’s internal structure.

The RDG server requests authorization from the MFA server. MFA calls, sends an SMS, or sends a request to the mobile application, depending on the chosen authentication method. The user then confirms or rejects the access request and the MFA server returns the result of the second authentication factor to the RDG server.

For clarity, we will outline the RDG request authentication scheme used by Azure MFA. The Network Policy Server (NPS) role is started on the RDG server, making it possible to redirect Radius requests. The MFA server will be deployed on a separate virtual machine in the company’s internal structure.

rdg request authentication scheme

The RDG server requests authorization from the MFA server. MFA calls, sends an SMS, or sends a request to the mobile application, depending on the chosen authentication method. The user then confirms or rejects the access request and the MFA server returns the result of the second authentication factor to the RDG server.

Azure Multi-Factor Authentication Server setup and installation

Creating an Authentication Provider in the Microsoft Azure Portal

Sign in to Microsoft Azure (the account must have a subscription or trial version) and find Multi-Factor Authentication (MFA).

For now, there is no MFA management in the new version of the Azure portal, so the old version will open.

To create a new multi-factor authentication provider press “Create ->Application services -> Active Directory -> Multi-factor authentication provider -> Quick start”. Specify the name and usage model.

The form of payment depends on the usage model: either based on the number of users, or based the number of authentications.

create mfa provider

Once created, MFA will be displayed in the list. Next, go to Control by clicking the corresponding button.

azure active directory

Go to “Downloads” and download the MFA server.

download mfa server

Deploying the MFA server

You must install the MFA server on a virtual machine separate from the RDG server. MFA supports OSes older than Windows Server 2008 or Windows 7. Microsoft .NET Framework 4.0 is also required.
These addresses should be accessible on port 443:

  • https://pfd.phonefactor.net;
  • https://pfd2.phonefactor.net;
  • https://css.phonefactor.net.

While installing the MFA server, do not use the setup wizard.

On first launch, you must enter credentials that need to be generated on the server’s load page.

mfa credentials

Next, add users. Go to “Users” and click “Import from Active Directory,” then select users to import.

mfas add users

mfas add users

If needed, new users can be automatically added from AD:

“Directory Integration -> Synchronization -> Add”. This process can also add a directory that will be automatically synchronized at a specified time interval.

new users added from AD

Test that the MFA server is working correctly. Go to “Users”. Specify the phone number (if not already set) and select the authentication method “Phone Call”. Click “Test” and enter the username and password. MFA Azure will call the phone. Answer and press #.

test MFA server

Configuring the MFA server to work with Radius requests

Go to “Radius Authentication” and check “Enable RADIUS Authentication”.

Add a new client and specify the IP address of the NPS server and the shared secret. If authentication needs to be performed for all users, check everyone (in this case, all users should already be added to the MFA server).

You also need to confirm that the ports specified for the connection correspond to the ports indicated on the NPS server and are not blocked by the firewall.

enable RADIUS Authentication

Go to “Target” and add the Radius server.

add radius server

Note: If there is no central NPS server in the network, the Radius client’s and Radius server’s IP addresses will be the same.

Configuring RDG and NPS servers to work with MFA

The Remote Desktop Gateway must be configured to send Radius requests to the MFA server. To do this, open the RDG properties and go to the “RDG CAP Store” tab. Select “Central server running NPS” and specify the MFA server address and shared secret.

RDG CAP Store

Next, configure the NPS server. Expand the “Radius clients and servers -> Remote Radius server groups” section. Open “TS gateway server group” properties group (this group is created when you configure the RDG server) and add the MFA server.

When adding the server, increase the server timeout limits on the “Load Balancing” tab. Set the “Number of seconds without response before request is considered dropped” and “the Number of seconds between requests when server is identified as unavailable” in the range of 30-60 seconds.

In “Authentication/Accounting”, check the accuracy of the specified ports and set the shared secret.

Edite Radius Authentication/Accounting

Edite Radius Authentication/Accounting

Go to “Radius clients and servers -> Radius clients” and add the MFA server by entering a “Friendly name”, address, and shared secret.

edite radius clients

Next, go to “Policies -> Connection request policies”. This section should have the policy created during configuration of RDG. This policy directs Radius requests to the MFA server.

Copy the policy and open its settings. Add a condition comparing “Client Friendly Name” with the “Friendly name” specified in the previous example.

copy policy properties Radius

On the “Settings” tab, replace the Authentication service provider with a local server.

policy properties settings Radius

This policy will guarantee that when you receive a Radius request from the MFA server it will be processed locally and prevent request loops.

Check that this policy is placed above the original policy.

network policy server

For now, the RDG and MFA link is ready. The following steps are necessary for those who want to authenticate via a mobile app or let users access several multifactor authentication configurations through the user portal.

Installing the SDK, mobile app web services, and user portal

The connection to these components is made via HTTPS. Therefore, you must install an SSL certificate on the server where they are deployed.

The user portal and web-service mobile app use the SDK to communicate with the MFA server.

SDK installation

The SDK is installed on the MFA server and requires IIS, ASP.NET, and Basic Authentication, which must be installed beforehand using the Server Manager.

To install the SDK, go to “Web Service SDK” in “Multi-Factor Authentication Server” and follow the instructions of the installation wizard.

SDK installation

Mobile app web-service installation

The following service is necessary for the mobile app to interact with the MFA server. For the service to function properly, the computer it is installed on must have Internet access and an open 443 port to connect to the internet.

The service installation file is located in C:\Program Files\Azure Multi-Factor Authentication on the computer with MFA installed. Run the installer and follow the installation wizard. For convenience, you can replace the name of the virtual directory “MultiFactorAuthMobileAppWebService” with a shorter one.

After installation, go to C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService and change the file web.config. In this file, you need to specify the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD parameters that correspond to the “PhoneFactor Admins” security group. This account will be used to connect to the SDK.

Mobile app web service installation

In the same file, indicate the URL where the SDK is available.

Note: The connection to the SDK is made via the SSL Protocol, so you must reference the SDK by the server name (specified in the SSL certificate) rather than an IP address. If a call is made using a local name, you must add a corresponding entry to the hosts file in order to use the SSL certificate.

mobile-app-web-service-installation-01

Add the URL where the mobile app web service is available to the Multi-Factor Authentication Server app in the Mobile App tab. This is necessary to properly generate a QR code in the user portal in order to connect to mobile apps.

You can also check “Enable OATH tokens”. This lets you use the mobile app as a software token to generate time-based one-time passwords.

User Portal Installation

Installation requires IIS, ASP.NET, and the IIS 6 Metabase Compatibility role (for IIS 7 or later).

If the portal is installed on the MFA server, just go to the “User Portal” in the Multi-Factor Authentication Server, press “install,” and follow the installation wizard. If the computer is joined to a domain, a user belonging to the PhoneFactor Admins security group will be created during installation. This user is required for a secure connection to the SDK.

user portal installation azure mfa

When installing on a separate server, copy the installation file from the MFA server (the installation file is located in C:\Program Files\Multi-Factor AuthenticationServer). Perform the installation and edit the web.config file located in C:\inetpub\wwwroot\MultiFactorAuth. Change USE_WEB_SERVICE_SDK from false to true. Specify the credentials for the account in the PhoneFactor Admins group in the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD parameters. Specify the URL of the SDK service, and don’t forget to correct the hosts file, if necessary, to make the SSL protocol work.

In the “User Portal” section, add the URL at which the user portal will be available to the Multi-Factor Authentication Server application.

Demonstration of using Azure MFA to authenticate RDG connections

We will consider what MFA does from the user’s perspective. In our case, the second authentication factor will be a mobile app, since cellular networks have a number of vulnerabilities that allow for easy interception of calls and texts.

First of all, the user must log in to the user portal, provide his or her phone number (if not specified in AD), and sync his or her account to the mobile app. Log in to the portal with your own account and answer the security questions (in case we need to recover access to the account).

MFA user log in

Then, select the authentication method (in our case, mobile app) and press “Generate New Activation Code”. A QR code will appear that must be scanned in the mobile app.

generate-new activation code azure mfa

Because PIN authentication was used when importing users to the MFA server, you will be asked to create a PIN code. Enter the desired PIN code and click “Authenticate”. Confirm the request in the mobile app. After taking these steps, you have an app linked to the account and full access to the portal in order to change personal settings.

change personal settings azure mfa

Note: The list of settings that the user may change through the portal is specified by the administrator in the Multi-Factor Authentication Server app.

Next, we will look at connecting through the RDG.

Create an RDP connection by specifying your RD Gateway and connecting.

RDP connection

RDP connection

Enter the credentials to access the RDG server.

credentials access RDG server

Confirm the request in the mobile app.

RDG server mobile-app

Enter the credentials to sign in on the local PC and wait for a connection.

credentials local PC

credentials local PC

Note: If the phone is equipped with a fingerprint sensor, the Authenticator application will prompt you to associate the PIN code with a fingerprint to subsequently authenticate by simply touching the phone.

Authentication methods offered by Azure MFA:

  • Phone call
    • press #
    • enter the PIN code and press #
  • SMS – you can use OTP or OTP + PIN
    • One-Way – while authorizing, enter the received code into the auxiliary field
    • Two-Way – send the received code back by SMS
  • Mobile app
    • Simple confirmation
    • You must enter the PIN code to confirm
  • OATH token – you will need to enter the code from the token screen into the auxiliary field when authorizing. You can use the mobile app as a software token.

The SMS One-Way and OATH token methods are not universal, since they require an auxiliary field for entering the code during authorization.

In conclusion, we will tell you about an MFA function that lets you track and protect against intruders who attempt to gain access without having the second authentication factor.

In the MFA control panel on the Azure portal, you may enable users to mark an incoming request as fraudulent. It is also possible to automatically block the user when receiving this message and send an email notification to support.

Azure MFA control panel

After enabling this function, users who have blocked the authentication request will receive a message asking them to notify support about an unauthorized login attempt.

MFA control panel

MFA control panel

The Azure MFA control panel has a report that shows fraud notifications:

Azure MFA control panel

If you need to find out the IP address from which an RDP session was initialized, look at the RDG server logs in the Event Viewer. If the second authentication factor was not passed, the event will have an “Error” status, and the description will indicate the IP address from which the RDP connection was established.

RDG server logs Event Viewer

References:
Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
User Portal
Mobile App Web Service

Best regards,
The Servilon Team

More articles about two-factor authentication

safe internet connection

Safe and Easy Internet Access: The Hassle-Free Way to Protect your Network from Internet Threats

While I was listening to a recent interview with the respected Eugene Kaspersky, where he expressed the idea that most of the company’s employees will not have Internet access soon, I was reminded that many companies completely separate their internal networks from the Internet, providing Internet access only from separate machines, and I decided to express my thoughts about this aspect of information security.

The practice of completely isolating a corporate network from the Internet is good enough. According to many IT professionals, it is the best way to protect corporate data. However, in addition to its high cost of implementation, this method has another very significant drawback, namely increased hassle when using the Internet. A lack of easy access to the Internet entails not only direct losses due to reduced employee productivity but also indirect costs, such as reduced employee loyalty and diminished prestige in the work. The result is increased company expenses.

Such a network typically looks like this:

typically network

This scheme completely separates workstations from the Internet. And even if a Trojan is installed on an employee’s computer, it will not be able to transfer the stolen information to the Internet. Such a network also prevents employees from distributing the company’s confidential information without authorization.

However, with all its security this scheme has a significant drawback – inflexibility and inconvenience, because there are only two options: an employee has no Internet access, or he or she is on a separate machine.

There is an interesting Microsoft solution in form of application virtualization called App-V can solve these problems and allow employees to work effectively.

Microsoft Application Virtualization (App-V) technology makes programs available on users’ computers without having to install the programs directly on those computers. Application virtualization allows each application to run in its own stand-alone virtual environment on the client computer. Virtualized applications are isolated from each other. This avoids conflicts between applications, but still allows them to interact with the client computer.

This could be implemented as follows: set up a terminal server on the DMZ to permit incoming Internet traffic, set up an Internet browser as a virtual application, and prohibit the use of the buffer and local resources through RDP. Also, set up a Remote Desktop Gateway on the DMZ and allow access to it via HTTPS from the company network.

The approximate scheme:

As a result, we have internal network users isolated from the Internet, who use an internal RDG service web page available in the Internet browser, or run an RDP file.

If a user possesses sufficient rights after authenticating, he or she launches the browser, which runs just as if it were being executed on user’s local machine. In reality, the browser is run on a Terminal Server: it only displays information on the monitor, and receive commands from the keyboard and mouse. It has no access to other resources on the user’s computer or the local network. Thus, we have achieved easy Internet access while completely isolating the computer.

Links:

Application Virtualization

Remote Desktop Gateway

Sincerely, the Servilon Team