-->
Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016
To connect to a remote computer from a Mac, install the Microsoft Remote Desktop app from the Mac App Store. Launch the app and grant the necessary permissions. Click the button to Add PC, then. The RD Session Host server then requests an RDS CAL from the Remote Desktop license server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client is able to connect to the RD Session Host server and from there to the desktop or apps they're trying to use.
Each user and device that connects to a Remote Desktop Session host needs a client access license (CAL). You use RD Licensing to install, issue, and track RDS CALs.
When a user or a device connects to an RD Session Host server, the RD Session Host server determines if an RDS CAL is needed. The RD Session Host server then requests an RDS CAL from the Remote Desktop license server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client is able to connect to the RD Session Host server and from there to the desktop or apps they're trying to use.
Get technical support for on-premise Microsoft products and services. Microsoft Store Support Get help with choosing a Microsoft product, or ask about a previous purchase from the online or physical store. Apr 02, 2020 As an alternative to the built-in Remote Desktop Connection tool, you can use the Microsoft Remote Desktop app in Windows 10. Install the app from the Microsoft Store and launch it. The RD Session Host server then requests an RDS CAL from the Remote Desktop license server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client is able to connect to the RD Session Host server and from there to the desktop or apps they're trying to use.
There is a licensing grace period of 120 Days during which no license server is required. Once the grace period ends, clients must have a valid RDS CAL issued by a license server before they can log on to an RD Session Host server.
Use the following information to learn about how client access licensing works in Remote Desktop Services and to deploy and manage your licenses:
- License your RDS deployment with client access licenses (CALs)
Understanding the RDS CAL model
There are two types of RDS CALs:
- RDS Per Device CALs
- RDS Per User CALs
The following table outlines the differences between the two types of CALs:
| Per Device | Per User |
|---|---|
| RDS CALs are physically assigned to each device. | RDS CALs are assigned to a user in Active Directory. |
| RDS CALs are tracked by the license server. | RDS CALs are tracked by the license server. |
| RDS CALs can be tracked regardless of Active Directory membership. | RDS CALs cannot be tracked within a workgroup. |
| You can revoke up to 20% of RDS CALs. | You cannot revoke any RDS CALs. |
| Temporary RDS CALs are valid for 52–89 days. | Temporary RDS CALs are not available. |
| RDS CALs cannot be overallocated. | RDS CALs can be overallocated (in breach of the Remote Desktop licensing agreement). |
When you use the Per Device model, a temporary license is issued the first time a device connects to the RD Session Host. The second time that device connects, as long as the license server is activated and there are available RDS CALs, the license server issues a permanent RDS Per Device CAL.
When you use the Per User model, licensing is not enforced and each user is granted a license to connect to an RD Session Host from any number of devices. The license server issues licenses from the available RDS CAL pool or the Over-Used RDS CAL pool. It's your responsibility to ensure that all of your users have a valid license and zero Over-Used CALs—otherwise, you're in violation of the Remote Desktop Services license terms.
An example of where one would use the Per Device model would be in an environment where there are two or more shifts using the same computers to access the RD Session Host(s). The Per User model would be best for environments where users have their own dedicated Windows device to access the RD Session Host(s).
To ensure you are in compliance with the Remote Desktop Services license terms, track the number of RDS Per User CALs used in your organization and be sure to have enough RDS Per User CALs installed on the license server for all of your users.
You can use the Remote Desktop Licensing Manager to track and generate reports on RDS Per User CALs.
RDS CAL version compatibility
The RDS CAL for your users or devices must be compatible with the version of Windows Server that the user or device is connecting to. You can't use RDS CALs for earlier versions to access later versions of Windows Server, but you can use later versions of RDS CALs to access earlier versions of Windows Server. For example, an RDS 2016 CAL or higher is required to connect to a Windows Server 2016 RD Session Host, while an RDS 2012 CAL or higher is required to connect to a Windows Server 2012 R2 RD Session Host.
The following table shows which RDS CAL and RD Session Host versions are compatible with each other.
| RDS 2008 R2 and earlier CAL | RDS 2012 CAL | RDS 2016 CAL | RDS 2019 CAL | |
|---|---|---|---|---|
| 2008, 2008 R2 session host | Yes | Yes | Yes | Yes |
| 2012 session host | No | Yes | Yes | Yes |
| 2012 R2 session host | No | Yes | Yes | Yes |
| 2016 session host | No | No | Yes | Yes |
| 2019 session host | No | No | No | Yes |
You must install your RDS CAL on a compatible RD license server. Any RDS license server can host licenses from all previous versions of Remote Desktop Services and the current version of Remote Desktop Services. For example, a Windows Server 2016 RDS license server can host licenses from all previous versions of RDS, while a Windows Server 2012 R2 RDS license server can only host licenses up to Windows Server 2012 R2.
The following table shows which RDS CAL and license server versions are compatible with each other.
| RDS 2008 R2 and earlier CAL | RDS 2012 CAL | RDS 2016 CAL | RDS 2019 CAL | |
|---|---|---|---|---|
| 2008, 2008 R2 license server | Yes | No | No | No |
| 2012 license server | Yes | Yes | No | No |
| 2012 R2 license server | Yes | Yes | No | No |
| 2016 license server | Yes | Yes | Yes | No |
| 2019 license server | Yes | Yes | Yes | Yes |
Note
OpenOTP plugin for Remote Desktop Services works for Windows Server 2012 & 2016.
If you have an older version, you have to update your RDS infrastructure.
1.1 Remote Desktop Services Infrastructure
In this post, we will assume an existing Remote Desktop Services infrastructure installed and available. This post will not cover how to set up RDS. Please refer to the Microsoft documentation and/or the TechNet blog for details about how to install and configured Microsoft documentation.
1.2 WebADM/OpenOTP/Radius Bridge
For this recipe, you will need to have WebADM/OpenOTP installed and configured. If you would like to have Push Login Mode then Radius Bridge needs to be configured. Please, refer to WebADM Installation Guide, WebADM Manual and Radius Bridge to do it.
2.1 RDWeb Authentication Workflow (Challenge Mode)
- User Access to RDWeb login page, provide Username/Password. Credentials are sent to Kerberos.
- Credentials are validated between RDWeb and Kerberos services.
- If credentials are correct then a Kerberos ticket is provided to RDWeb for this user.
- Once the first validation with Kerberos is ok, an OpenOTP login request is sent from the OpenOTP RDWeb Plugin installed on RDWeb server to OpenOTP server.
- If LDAP Credentials are validated by OpenOTP server, then a challenge request is sent by OpenOTP to the RDWeb and will allow the user to provide the OTP.
- The user is prompted to enter his OTP. The OTP is sent back to the OpenOTP server through the OpenOTP RDWeb plugin.
- OpenOTP validates the OTP provided by the User.
- If the OTP is validated by OpenOTP server then the authentication is a success.
- The user has logged on the RDWeb interface and is able to download RDP files.
2.2 RDWeb Authentication Workflow (Push Login Mode)
The user initiates an RDP session with an RDP file previously downloaded from the RDWeb server.
The RDP connection start through the RDP client. The RDP client contacts the RDGateway. The RDGateway communicate with NPS to check users policies and resources allowed for this user.
At this step, the first validation with Kerberos is in progress.
A Kerberos ticket is created for this user and send back to NPS.
NPS act as a PROXY RADIUS too. Once NPS has received the Kerberos validation, a RADIUS « Access-Request » is sent to Radius Bridge by NPS.
The Radius « Access-Request » is translated into a SOAP « Login request » by Radius Bridge product to be managed by OpenOTP server. OpenOTP will validate LDAP credentials and send a push login request to the user’ mobile.
If LDAP Credentials are validated by OpenOTP server, then a push login request is sent RCDevs Push servers.
RCDevs Push Servers communicate with Google/Apple Push services.
Google/Apple services. send the push notification on the user’ mobile OpenOTP.
The user receives the push login request on his phone and has to Accept or Reject the login attempt.
The response from the mobile is sent to WAProxy server and WAProxy forward the mobile response to OpenOTP server.
OpenOTP manages the response and accept or reject the login attempt according to the mobile response.
OpenOTP sends a « SOAP access accept » request to Radius Bridge.
Radius Bridge translates the SOAP request into a RADIUS request. The response is sent to NPS. NPS receives the authorization from the RADIUS server to allow the connection for this user. The user is successfully authenticated in 2FA.
RDGateway allows the user to access to Session Hosts according to policies configured on NPS for this user and resources allowed.
OpenOTP plugin for Microsoft RDS has to be installed on every RDWeb servers you have. You have to download the plugin on RCDevs Website at the following links OpenOTP Plugin for RDWeb Gateway.
Note
Administrative/elevated permissions are necessary on any workstation to correctly set up and/or change the OpenOTP Plugin for RDWeb’s configuration. Please, run the Windows PowerShell as Administrator. Right click on the Windows PowerShell then select Run as Administrator.
Extract files from the archive on your RDS server(s), run the MSI file in the Windows PowerShell as Administrator and click on Next.
Accept the End-User License Agreement and click on Next.
On the next page, choose your default folder location and click on Next.
On this page, you have to configure one of your WebADM servers URL. If you are running a WebADM cluster, then both OpenOTP URLs should be automatically retrieve in the Auto mode. If your OpenOTP URL(s) can not be automatically retrieve, then configure URL(s) manually like below :
On the next page, the WebADM CA certificate is automatically retrieved and configured if you have choose the Auto mode to return OpenOTP URL(s). Every other settings are optional. If you’d like to use a client certificate for enhanced security, please use this next screen to provide the detail.Clicking on the question marks (?) will provide additional help during the installation procedure.
Click Next and the next page allows you to configure failover with OpenOTP, SOAP request timeout and UPN Mode. Keep the default configuration if you are not sure of what you need. Click on Next.
UPN Mode
Explicit : This is the value of the user object’s userPrincipalName attribute.
Implicit : This is constructed by concatenating the value of the user object’s samAccountName attribute with the value of the domain’s FQDN.
On the next page, you can configure a custom message when users need assistance.
Click on Next. On that page, you can configure the reverse-proxy address(es) of your reverse-proxy if you are accessing RDWeb portal through a reverse-proxy. This is usefull for WebADM in order to know the real end-user IP in WebADM logs instead of the reverse-proxy IP(s). It is also usefull for WebADM if you want to use the Per-Network Extra Policies feature in your RDWeb client policy.
Click on Next and Install.
Installation is complete. Click on Finish.
Plugin Installation
Repeat this procedure on every RDWeb servers!
You are now able to login on your RDWeb server with OpenOTP. Go to your RDWeb page and please enter your credentials:
WebADM Authentication Policy
Here, WebADM is configured with the authentication policy LDAP + OTP but, LDAP credentials are not checked by WebADM/OpenOTP but by Windows. In any case, OpenOTP will only check the OTP password.
Enter your OTP password on the next screen and click on Submit.
And you are logged on:
It’s done for the RDWeb.
RDP Application & OpenOTP
If you have remote applications accessible through RDP and you want to secure these applications access with OpenOTP, you have to install OpenOTP Plugin for Windows Login.
Push Login is mandatory in that scenario
The RDS scenario with NPS, OpenOTP and Radius Bridge can only work with the push login infrastructure. NPS didn’t manage the RADIUS challenge, that’s why it’s mandatory to use the Push login.
4.1 Workflow
The user initiates an RDP session with an RDP file previously downloaded from the RDWeb server.
The RDP connection starts through the RDP client. The RDP client contacts the RDGateway. The RDGateway communicate with NPS to check users policies and resources allowed for this user.
At this step, the first validation with Kerberos is in progress.
A Kerberos ticket is created for this user and send back to NPS.
NPS act as a PROXY RADIUS too. Once NPS has received the Kerberos validation, a RADIUS « Access-Request » is sent to Radius Bridge by NPS.
The Radius « Access-Request » is translated into a SOAP « Access request » by Radius Bridge product to be managed by OpenOTP server. OpenOTP will validate LDAP credentials and send a push login request to the user’ mobile.
If LDAP Credentials are validated by OpenOTP server, then a push login request is sent RCDevs Push servers.
RCDevs Push Servers communicate with Google/Apple Push services.
The user receives the push login request on his phone and has to Accept or Reject the login attempt.
The response from the mobile is sent to WAProxy server and WAProxy forward the mobile response to OpenOTP server.
OpenOTP manages the response and accept or reject the login attempt according to the mobile response.
OpenOTP sends a « SOAP access accept » request to Radius Bridge.
Radius Bridge translates the SOAP request into a RADIUS request. The response is sent to NPS. NPS receives the authorization from the RADIUS server to allow the connection for this user. The user is successfully authenticated in 2FA.
RDGateway allows the user to access to Session Hosts according to policies configured on NPS for this user and resources allowed.
4.2 RDGateway Configuration
We will start by configuring the RDGateway component. Open the RD Gateway manager console.
Right click on Connection Authorization Policies > Create New Policy > Wizard.
You will be prompted to the following screen:
Select Create an RD CAP and an RD RAP option and click Next.
Provide a name for your RD CAP.
Select your user group and a computer group membership.
The configuration wizard is now finished.
Now click right on your server name under RD Gateway Manager console and select Properties.
Under the SSL Certificate tab, select your Certificate signed by your CA or select a self-signed certificate. On my side, I select a certificate issued by my internal CA.
Microsoft Remote Desktop Online Training
My certificate will now be used to trust the Gateway.
Now, go to RD CAP Store and choose the location of your NPS server. On my side, NPS is installed on the same server.
Under the Server Farm tab, add your current RD Gateway server(s).
The configuration of RD Gateway is now finished!
4.3 NPS Configuration
4.3.1 Remote RADIUS Server Groups
We will now configure the NPS component. NPS manages which user is able to log in on which resource, the authentication method…
First, we will configure a Remote RADIUS Server Group and edit the default group TS GATEWAY SERVER GROUP.
Microsoft Remote Desktop online, free
Right click > Properties on the TS Gateway Server Group. Under the General tab, click Add button to add a RADIUS Server. 192.168.3.54 is my Radius Bridge server installed on my OpenOTP/WebADM server.
On the Authentication/Accounting tab, configure your Radius secret.
Under the Load Balancing tab, configure your timeout value and the priority if you configure more than 1 server.
Once the configuration is done, click Save and Ok.
At this step, you can also configure the Radius Client and his secret on Radius Bridge Server to allow NPS to communicate with Radius Bridge.
At the end of this file you should have your NPS Server configured like below:
Your Radius Server is now configured at the NPS level.
4.3.2 Connection Request Policies
We will now create a new Connection Request Policy.
Name your policy and select Remote Desktop Gateway as Type of network access server.
Click Next.
You have now to specify conditions of this policy.
Select NAS port Type and then Virtual (VPN) as value.
Click Next and on the next page, select your Radius Server group previously configured.
Click on Finish button.
My connection request policy is now created and activated.
Microsoft Remote Desktop Web Portal
4.3.3 Network Policies
We will now configure a Network Policy through the NPS console. Right click on Network Policies > New.
Name your Network Policy, select Remote Desktop Gateway as Type of network access server and then click Next.
On the following screen, you have to specify conditions.
You should have 3 following conditions configured in your Network Policy. For the Calling Station ID condition, put UserAuthType:(PW|CA) value.
Once you have the 3 previous conditions configured, click Next.
I configured this policy to allow the access so here I select Access Granted:
I keep these settings by default.
I keep these settings by default.
Here is a summary of my Network Policy.
The NPS configuration is done. I should be able now to log in on a Session Host through my RD Gateway and NPS over RADIUS protocol.
4.4. Login Test with MFA Push Login
Microsoft Remote Desktop App
I start the default RDP client tool from Microsoft. In the advanced configuration, I configure my RD Gateway server address.
I will now try to login remotely on my AD server, so I configured my AD server address:
In the meantime, I’ve started my Radius Bridge component in debug mode with the following command to see in live the radius request sent by NPS:
I perform the login now through my RDP client. I’m prompted to enter my Credentials:
I press OK after providing my credentials and then I see the RADIUS request coming on my Radius Bridge debug console:
I now received the push login request on my phone:
Microsoft Remote Desktop Offline Download
001b001b
I approve the login request and I am logged on my remote server:
Another scenario is also possible which consists to protect each session hosts with the OpenOTP Credential Provider for Windows login. The 2FA login will be performed by each session hosts instead of a centralized component.
This manual was prepared with great care. However, RCDevs S.A. and the author cannot assume any legal or other liability for possible errors and their consequences. No responsibility is taken for the details contained in this manual. Subject to alternation without notice. RCDevs S.A. does not enter into any responsibility in this respect. The hardware and software described in this manual is provided on the basis of a license agreement. This manual is protected by copyright law. RCDevs S.A. reserves all rights, especially for translation into foreign languages. No part of this manual may be reproduced in any way (photocopies, microfilm or other methods) or transformed into machine-readable language without the prior written permission of RCDevs S.A. The latter especially applies for data processing systems. RCDevs S.A. also reserves all communication rights (lectures, radio and television). The hardware and software names mentioned in this manual are most often the registered trademarks of the respective manufacturers and as such are subject to the statutory regulations. Product and brand names are the property of RCDevs S.A. © 2021 RCDevs SA, All Rights Reserved