Securing a remote terminal server or two-factor authentication of RDG clients with Azure MFA
The realities of the countries where the majority of Khabrovsk residents live are such that keeping servers with important information outside the country of business has become a good form, allowing you to save your nerves and data.
The first question that arises when moving to the cloud after data encryption, or maybe before it, is the guarantee that access to data with a user account is carried out by the user, and not by someone else. And if a good way to encrypt data hosted in a private cloud is discussed in an article by my colleague , then authentication is more complicated.
About users and protection methods
The nature of the typical user is such that the attitude to the security of passwords from accounts is rather frivolous and it is impossible to fix it. Our experience shows that even if the company uses strict policies, user training, etc., you can still find an unencrypted device that has left the office, and looking at the list of products of one well-known company, you understand that extracting passwords from an unencrypted device is only a matter of time.
Some companies establish tunnels between the cloud and the office to control access to data in the cloud, prohibit remote access https://habrahabr.ru/company/pc-administrator/blog/320016/. In our opinion, this is not an optimal solution, firstly, some of the advantages of the cloud solution are lost, and secondly, there are performance problems noted in the article.
The solution using the terminal server and Remote Desktop Gateway (RDG) is more flexible, you can configure a high level of security, as my colleague described https://habrahabr.ru/post/134860/ (2011 article, but the principle itself is still relevant) . This method allows you to prevent data transfer from the cloud, but imposes restrictions on the user’s work and does not completely solve the authentication problem, rather it is a DLP solution.
Perhaps the best way to ensure that an attacker is not running under a user account is totwo-factor authentication . In the articles of my colleaguehttps://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ describes how to configure MFA from Microsoft and Google for a client VPN. The method is good, but, firstly, it requires CISCO ASA, which is not always easy to implement, especially in low-cost clouds, and secondly, working through a VPN is inconvenient. Working with a terminal session through RDG is much more comfortable, and the SSL encryption protocol looks more universal and reliable than a VPN from CISCO.
There are many solutions with two-factor authentication on the terminal server itself, here is an example of setting up a free solution - http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/ . This solution, unfortunately, does not work through RDG.
Some companies establish tunnels between the cloud and the office to control access to data in the cloud, prohibit remote access https://habrahabr.ru/company/pc-administrator/blog/320016/. In our opinion, this is not an optimal solution, firstly, some of the advantages of the cloud solution are lost, and secondly, there are performance problems noted in the article.
The solution using the terminal server and Remote Desktop Gateway (RDG) is more flexible, you can configure a high level of security, as my colleague described https://habrahabr.ru/post/134860/ (2011 article, but the principle itself is still relevant) . This method allows you to prevent data transfer from the cloud, but imposes restrictions on the user’s work and does not completely solve the authentication problem, rather it is a DLP solution.
Perhaps the best way to ensure that an attacker is not running under a user account is totwo-factor authentication . In the articles of my colleaguehttps://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ describes how to configure MFA from Microsoft and Google for a client VPN. The method is good, but, firstly, it requires CISCO ASA, which is not always easy to implement, especially in low-cost clouds, and secondly, working through a VPN is inconvenient. Working with a terminal session through RDG is much more comfortable, and the SSL encryption protocol looks more universal and reliable than a VPN from CISCO.
There are many solutions with two-factor authentication on the terminal server itself, here is an example of setting up a free solution - http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/ . This solution, unfortunately, does not work through RDG.
The advantages of Microsoft Azure Multi-Factor Authentication Server (MFAS) are described in the above article, so I won’t give them again, but we will start right away with the settings.
In order not to increase the volume of this article, we omit the initial installation and configuration of the RDG server, which authorizes users by login and password.
For clarity, we provide an authentication scheme for an RDG request using Azure MFA. The Network Policy Server (NPS) role has been launched on the RDG server, which allows redirecting Radius requests. The MFA server will be deployed in a separate virtual machine in the internal structure of the enterprise.
The RDG server requests authorization confirmation from the MFA server. MFA, depending on the selected authentication method, calls, sends SMS or sends a request to the mobile application. The user accepts or denies the request for access. MFA returns the result of the second authentication factor to the RDG server.
Install and configure Azure Multi-Factor Authentication Server
Create an authentication provider in the Microsoft Azure portal
We go in Microsoft Azure (the account must have a subscription or the trial version is installed) and we find Multi-Factor Authentication (MFA).
Currently, MFA management has not been added to the new version of the Azure portal, so the old version of the portal will open.
To create a new multi-factor authentication provider, click CREATE → Application Services → Active directory → Multi-Factor Authentication Provider → Quick Create. Indicate name and usage model.
How the payment will be charged depends on the usage model, either by the number of users or by the number of authentications.
Once created, the MFA will appear in the list. Next, go to control by clicking the appropriate button.
Go to the downloads and download the MFA server
Deploy MFA Server
It is necessary to install the MFA server on a virtual machine other than the RDG server. OSs older than Windows Server 2008 or Windows 7 are supported. Microsoft .NET Framework 4.0 is required to work.
Addresses on port 443 should be available:
We install the MFA server, during the installation we refuse the settings wizard.
At the first start, it is necessary to enter data from the account, which must be generated on the server download page.
Next, add users. To do this, go to the Users section and click on Import from Active Directory, select the users to import.
If necessary, you can configure the automatic addition of new users from the AD:
“Directory Integration → Synchronization → Add”, including add a directory that will be automatically synchronized at the specified time interval.
We will conduct a test of the MFA server. Go to the Users section. For your account, specify the phone number (if not already set) and select the authentication method "Phone call". Click the Test button and enter the login, password. The phone should receive a call. We answer it and press #.
Configuring the MFA server to work with Radius requests
Go to the Radius Authentication section and check the box “Enable RADIUS Authentication”.
Add a new client by specifying the IP address of the NPS server and the shared secret key. If authentication should be performed for all users, check the box (in this case, all users must be added to the MFA server).
It is also necessary to make sure that the ports indicated for the connection correspond to the ports indicated on the NPS server and that the firewall does not block them.
Go to the Target tab and add the Radius server.
Note: If the network does not have a central NPS server, the IP addresses of the Radius client and server will be the same.
Configuring RDG and NPS server to work with MFA
The Remote Desktop Gateway must be configured to send Radius requests to the MFA server. To do this, open the gateway properties and go to the “RDG CAP Store” tab, select “NPS works on a central server” and specify the address of the MFA server and the shared secret key.
Next, we configure the NPS server. Expand the section "Radius Clients and Servers → Remote Radius Server Groups". Open the properties of the TS gateway server group group (the group is created when RDG is configured) and add our MFA server.
When adding, on the “Load Balancing” tab we increase the server timeout limits. We set “The number of seconds without response, after which the request is considered discarded” and “The number of seconds between requests, after which the server is considered unavailable” in the range of 30-60 seconds.
On the “Authentication / Accounting” tab, check the correctness of the specified ports and set the shared secret key.
Now we’ll go to the section “Radius Clients and Servers → Radius Clients” and add the MFA server, indicating “Friendly name”, address and shared secret.
Go to the section “Policies → Connection Request Policies”. This section should have a policy created when configuring RDG. This policy routes Radius requests to the MFA server.
We duplicate the policy and go into its properties. Add a condition matching “Client Friendly Name” with “Friendly name” specified in the previous step.
On the Settings tab, we change the authentication service provider to the local server.
This policy will ensure that when Radius receives a request from the MFA server, the request will be processed locally, which eliminates the need for looping requests.
We verify that this policy is placed above the original one.
At this stage, the bundle of RDG and MFA is operational. The following steps are necessary for those who need to be able to use authentication using a mobile application or provide users with access to some multifactor authorization settings through a user portal.
Install SDK, mobile app web service and user portal
Connection to these components is carried out via the HTTPS protocol. Therefore, on the server where they will be deployed, you must install an SSL certificate.
The user portal and mobile app web service use the SDK to communicate with the MFA server.
SDK installation
The SDK is installed on the MFA server and requires IIS, ASP.NET, Basic Authentication, which must be pre-installed using Server Manager.
To install the SDK, go to the Web Service SDK section in the Multi-Factor Authentication Server and click the install button, follow the installation wizard.
Install the web service of the mobile application
This service is required for the mobile application to interact with the MFA server. For the service to work correctly, the computer on which it will be installed must have an Internet connection and a 443 port is open for connecting from the Internet.
The service installation file is located in the C: \ Program Files \ Azure Multi-Factor Authentication folder on the computer with MFA installed. We launch the installer and follow the installation wizard. For the convenience of users, you can replace the name of the virtual directory "MultiFactorAuthMobileAppWebService" with a shorter one.
After installation, go to the folder C: \ inetpub \ wwwroot \ MultiFactorAuthMobileAppWebService and change the file web.config . The keys must be specified in this file.WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD , which are responsible for the account included in the PhoneFactor Admins security group. This account will be used to connect to the SDK.
In the same file, you must specify the URL at which the SDK is available.
Note: The connection to the SDK is via SSL, so you need to refer to the SDK by the server name (specified in the SSL certificate), and not by IP address. If the call is made by the local name, you need to add the corresponding entry in the hosts file in order to use the SSL certificate.
Add the URL at which the mobile application web service is available to the Multi-Factor Authentication Server application in the Mobile App section. This is necessary for the correct generation of the QR code in the user portal for connecting mobile applications.
Also in this section you can check the box “Enable OATH tokens”, which allows you to use a mobile application as a Software token to generate one-time passwords based on time.
Custom Portal Installation
Installation requires IIS, ASP.NET, and the IIS 6 meta-database compatibility role (for IIS 7 or later).
If the portal is installed on the MFA server, just go to the User Portal section in the Multi-Factor Authentication Server, click the install button and follow the installation wizard. If the computer is joined to a domain, then during installation, a user will be created that is a member of the PhoneFactor Admins security group. This user is required for a secure connection to the SDK.
When installing on a separate server, you must copy the installation file from the MFA server (the installation file is located in the C: \ Program Files \ Multi-Factor Authentication Server folder ). Install and edit the web.config file to the location C: \ inetpub \ wwwroot \ MultiFactorAuth . In this file, you need to change the key USE_WEB_SERVICE_SDK from false to true. Specify the details of the account included in the PhoneFactor Admins group in the keys WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD . And specify the URL address of the SDK service, not forgetting to correct the hosts file if necessary so that the SSL protocol works.
Add the URL where the user portal is accessible to the Multi-Factor Authentication Server application in the User Portal section.
Azure MFA Demonstration for RDG Connection Authentication
We will consider the operation of the MFA by the user. In our case, the second authentication factor will be a mobile application, since the cellular network has a number of vulnerabilities that, with proper preparation, can intercept calls and SMS.
First of all, the user will need to go to the user portal and indicate his phone number (if not specified in AD) and attach a mobile application to his account. We go to the portal under our account and enter answers to secret questions (we will need them in case of restoration of access to the account).
Next, select the authentication method, in our case, a mobile application and click the "Create Activation Code" button. A QR code will be generated, which must be scanned in the mobile application.
Since authentication was set using the PIN code when importing users to the MFA server, we will be asked to create it. Enter the desired PIN code and click "Verify my authenticity." In the mobile application, you must confirm the request that appears. After these actions, we have an application tied to the account and full access to the portal to change personal settings.
Note: The list of settings that the user can change through the portal is set by the administrator in the Multi-Factor Authentication Server application.
Next, consider connecting via RDG.
We create an RDP connection, specify our gateway and connect.
Enter the account information for authorization on the RDG server.
We confirm the request in the mobile application
Enter the account information for authorization on the connected machine and wait for the connection.
Note: If your phone is equipped with a fingerprint sensor, Authenticator will offer to associate a PIN code with a fingerprint, in order to subsequently confirm authentication with a simple touch on the phone.
Authentication methods offered by Azure MFA:
Phone ringing:
- pressing #
- entering PIN code and pressing #
SMS - you can use OTP or OTP + PIN:
- One-Way - the received code must be entered in an additional field during authorization
- Two-Way - the received code must be sent back by SMS
Mobile app:
- Simple confirmation
- To confirm, enter the PIN code
OATH token - during authorization, you will need to enter the code from the token screen into the additional field. You can use a mobile application as a token.
SMS One-Way and OATH token methods are not universal, as they require an additional field for entering the code during authorization.
In conclusion, we’ll talk about the MFA function that allows you to monitor and protect against intruders trying to gain access without having a second authentication factor.
On the Azure portal, in the MFA control panel, you can enable the feature that allows users to mark a received authentication request as fraudulent. It is also possible to automatically block the user upon receipt of this message and send an email notification to the support service.
After enabling this function, users who have denied an authentication request will be shown a message asking them to notify the support service about an illegitimate login attempt. There is a report in the Azure MFA control panel showing fraud notifications:
If you need to find out the IP address from which the RDP session was initialized, you can see the RDG server logs in the Event Viewer. If the second authentication factor has not been passed, the event will have the Error status, and the IP address from which the RDP connection was established will be indicated in the description.
Article links:
→ Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
→ User Portal
→ Mobile App Web Service