Remote Desktop Web Portal and Gateway

How To Configure MS Remote Desktop Services and RDWeb portal with OpenOTP

OpenOTP plugin for Remote Desktop Web Portal (RDWeb) works on Windows Server 2012, 2016, 2019, and 2022.

Prerequisites

Remote Desktop Services Infrastructure

In this post, we will assume an existing Remote Desktop Services infrastructure is 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 configure Microsoft documentation.

WebADM/OpenOTP/Radius Bridge

For this recipe, you will need to have WebADM/OpenOTP installed and configured. If you want to enforce OpenOTP login at the RDGateway level, you must have Push mechanisms configured with your WebADM infrastructure, and the Radius Bridge needs to be configured with MS Network Policy Server.

How to Secure RDWeb Access with OpenOTP

RDWeb Authentication Workflow (Challenge Mode)

User accesses the RDWeb login page and provides Username/Password. Credentials are sent to Kerberos.
Credentials are validated between RDWeb and Kerberos services.
If credentials are correct, a Kerberos ticket is provided to RDWeb for this user.
Once the first validation with Kerberos is successful, an OpenOTP login request is sent from the OpenOTP RDWeb Plugin installed on the RDWeb server to the OpenOTP server.
If LDAP credentials are validated by the OpenOTP server, a challenge request is sent by OpenOTP to RDWeb, prompting the user to provide the OTP.
The user is prompted to enter their 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 the OpenOTP server, authentication is successful.
The user has logged into the RDWeb interface and is able to download RDP files.

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 communicates with NPS to check user 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 sent back to NPS.
NPS acts as a RADIUS proxy as well. Once NPS has received the Kerberos validation, a RADIUS Access-Request is sent to the Radius Bridge by NPS.
The RADIUS Access-Request is translated into a SOAP Login request by the Radius Bridge product to be managed by the OpenOTP server. OpenOTP will validate LDAP credentials and send a push login request to the user’s mobile.
If LDAP credentials are validated by the OpenOTP server, a push login request is sent to RCDevs Push servers.
RCDevs Push Servers communicate with Google/Apple Push services.
Google/Apple services send the push notification to the user's mobile via OpenOTP.
The user receives the push login request on their phone and must Accept or Reject the login attempt.
The response from the mobile is sent to the WAProxy server, which forwards the mobile response to the OpenOTP server.
OpenOTP processes the response and accepts or rejects the login attempt according to the mobile response.
OpenOTP sends a SOAP access accept request to the Radius Bridge.
The 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 Session Hosts according to policies configured on NPS for this user and the resources allowed.

OpenOTP Plugin for RDWeb Installation

OpenOTP plugin for Microsoft RDS must be installed on every RDWeb server you have. You can download the plugin from the RCDevs website at the following link: OpenOTP Plugin for RDWeb Gateway.

Administrative/elevated permissions are necessary on any workstation to correctly set up and/or change the OpenOTP Plugin for RDWeb’s configuration. Please run Windows PowerShell as Administrator. Right-click on Windows PowerShell and select "Run as Administrator".

Extract the files from the archive on your RDS server(s), run the MSI file in 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 need to configure one of your WebADM server URLs. If you are running a WebADM cluster, both OpenOTP URLs should be automatically retrieved in Auto mode. If your OpenOTP URLs cannot be automatically retrieved, configure the URLs manually as shown below:

On the next page, the WebADM CA certificate is automatically retrieved and configured if you have chosen Auto mode to retrieve OpenOTP URL(s). All other settings are optional. If you'd like to use a client certificate for enhanced security, use this screen to provide the details. Clicking on the question marks (?) will provide additional help during the installation procedure.

Click Next, and the following page allows you to configure failover with OpenOTP, SOAP request timeout, and UPN Mode. Keep the default configuration if you are unsure of what you need. Click Next.

On the next page, you can configure a custom message for users who need assistance.

Click on Next. On that page, you can configure the reverse-proxy address(es) if you are accessing the RDWeb portal through a reverse-proxy. This is useful for WebADM to know the real end-user IP in WebADM logs instead of the reverse-proxy IP(s). It is also useful 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.

Repeat this procedure on every RDWeb server!

You are now able to log in to your RDWeb server with OpenOTP. Go to your RDWeb page and enter your credentials:

Here, WebADM is configured with the authentication policy LDAP + OTP, but LDAP credentials are not checked by WebADM/OpenOTP; they are checked by Windows. In any case, OpenOTP will only verify the OTP password.

Enter your OTP password on the next screen and click Submit.

And you are logged in:

It's done for the RDWeb.

Enable MFA for the RDWeb Apps.

If you have remote applications accessible through the RDWeb portal and want to secure access to these applications with OpenOTP, you need to install the OpenOTP Plugin for Windows Login.

To enable Multi-Factor Authentication (MFA) for every connection, even if you close the published app, follow these steps:

To ensure MFA is required for every connection, activate the Set time limit for logoff of RemoteApp sessions option. This can be done on the host machine (Windows server).

Configuration Steps:

Enter gpedit.msc and press Enter to open the Local Group Policy Editor.

Navigate to: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Host -> Session Time Limits.

Select Set Time Limit for Logoff of RemoteApp Sessions, right-click, and choose Edit.

Select Enabled, choose a time for the End a disconnected session option, and then click OK to apply the configuration.

Now you can use the gpupdate /force command in PowerShell to forcibly update Group Policy.

How to configure RDGateway with NPS and OpenOTP over RADIUS

The RDS scenario with NPS, OpenOTP, and Radius Bridge can only work with the push login infrastructure. NPS does not handle the RADIUS challenge, which is why using Push login is mandatory.

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 communicates with NPS to check user 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 sent back to NPS.
NPS acts as a RADIUS proxy as well. 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 the Radius Bridge product to be managed by the OpenOTP server. OpenOTP will validate LDAP credentials and send a push login request to the user’s mobile.
If LDAP credentials are validated by the OpenOTP server, a push login request is sent to RCDevs Push servers.
RCDevs Push Servers communicate with Google/Apple Push services.
The user receives the push login request on their phone and must accept or reject the login attempt.
The response from the mobile is sent to the WAProxy server, which forwards the mobile response to the OpenOTP server.
OpenOTP processes the response and accepts or rejects the login attempt according to the mobile response.
OpenOTP sends a SOAP access accept request to the Radius Bridge.
The 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 Session Hosts according to policies configured on NPS for this user and the resources allowed.

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, right-click on your server name under the RD Gateway Manager console and select Properties.

Under the SSL Certificate tab, select your certificate signed by your CA or choose a self-signed certificate. In my case, I selected a certificate issued by my internal CA.

My certificate will now be used to trust the Gateway.

Next, go to RD CAP Store and choose the location of your NPS server. In my case, 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!

NPS Configuration

Remote RADIUS Server Groups

We will now configure the NPS component. NPS manages which users can log in to which resources and the authentication methods.

First, configure a Remote RADIUS Server Group and edit the default group TS GATEWAY SERVER GROUP.

Right-click on TS Gateway Server Group and select Properties. Under the General tab, click the 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 set the priority if you have more than one server.

Once the configuration is done, click Save and OK.

At this step, you can also configure the RADIUS client and its secret on the Radius Bridge server to allow NPS to communicate with the Radius Bridge.

vi /opt/radiusd/conf/clients.conf

At the end of this file, you should have your NPS Server configured as follows:

client NPS {
        ipaddr = 192.168.3.119
        secret = testing123
}

Your RADIUS server is now configured at the NPS level.

Connection Request Policies

We will now create a new Connection Request Policy.

Name your policy and select Remote Desktop Gateway as the Type of network access server.

Click Next. You now need to specify the conditions for this policy.

Select NAS port Type and then choose Virtual (VPN) as the value.

Click Next, and on the following page, select your RADIUS Server group that you previously configured.

Click the Finish button.

My connection request policy is now created and activated.

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 the Type of network access server, and then click Next.

On the following screen, you need to specify conditions.

You should have the following 3 conditions configured in your Network Policy. For the Calling Station ID condition, set the value to UserAuthType:(PW|CA).

Once you have the 3 conditions configured, click Next.

I configured this policy to allow access, so 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. You should now be able to log in to a Session Host through your RD Gateway and NPS over the RADIUS protocol.

Start the default RDP client tool from Microsoft. In the advanced configuration, set your RD Gateway server address.

I will now try to log in remotely to 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 the RADIUS requests sent by NPS in real time:

/opt/radiusd/bin/radiusd debug

Listening on auth address * port 1812 bound to server default
Listening on auth proto tcp address * port 1812 bound to server default
Listening on auth address * port 1645 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on acct address * port 1646 bound to server default
Listening on status address * port 18120 bound to server default
Listening on command file /opt/radiusd/temp/radiusd.sock
Ready to process requests

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 appearing on my Radius Bridge debug console.

(0) Received Access-Request Id 24 from 192.168.3.119:60706 to 192.168.3.54:1812 length 143
(0)   Service-Type = Voice
(0)   User-Name = "NETBIOSYORCDEVS\\administrateur"
(0)   Called-Station-Id = "UserAuthType:PW"
(0)   MS-Machine-Name = "YO_SQL2.yorcdevs.com"
(0)   MS-Network-Access-Server-Type = Terminal-Server-Gateway
(0)   NAS-Port-Type = Virtual
(0)   Proxy-State = 0xfe80000000000000c9e592a48d7b3d5c0000001b
(0) # Executing section authorize from file /opt/radiusd/lib/radiusd.ini
(0)   authorize {
(0) eap: No EAP-Message, not doing EAP
(0)     [eap] = noop
(0) pap: WARNING: No "known good" password found for the user.  Not setting Auth-Type
(0) pap: WARNING: Authentication will fail unless a "known good" password is available
(0)     [pap] = noop
(0)     [openotp] = ok
(0)   } # authorize = ok
(0) Found Auth-Type = OTP
(0) # Executing group from file /opt/radiusd/lib/radiusd.ini
(0)   Auth-Type OTP {
rlm_openotp: Found NPS Terminal-Server-Gateway request (password not requested)
rlm_openotp: Sending openotpNormalLogin request
rlm_openotp: OpenOTP authentication succeeded
rlm_openotp: Reply message: Authentication success
rlm_openotp: Sending Access-Accept
(0)     [openotp] = ok
(0)   } # Auth-Type OTP = ok
(0) Login OK: [NETBIOSYORCDEVS] (from client any port 0)
(0) Sent Access-Accept Id 24 from 192.168.3.54:1812 to 192.168.3.119:60706 length 0
(0)   Reply-Message := "Authentication success"
(0)   Proxy-State = 0xfe80000000000000c9e592a48d7b3d5c0000001b
(0) Finished request
Waking up in 9.9 seconds.
(0) Cleaning up request packet ID 24 with timestamp +9
Ready to process requests

I have now received the push login request on my phone:

I approve the login request, and I am logged in to my remote server.

Other scenario

Another option is to secure each session host individually with the OpenOTP Credential Provider for Windows login. This approach enables two-factor authentication (2FA) to be performed directly on the session host, rather than through a centralized component (RDGateway). This scenario offers greater flexibility in terms of supported authentication methods during the login process. If push notifications are not a desired scenario, consider protecting session hosts with the OpenOTP Credential Provider instead of securing the RDGateway itself.