User manual

This user manual is for the Thincast Remote Desktop WebServices (RD WebServices) which consists of the two individual products Remote Desktop Gateway (RD Gateway) and Remote Desktop WebAccess (RD WebAccess).

Version 1.1

Last update on 16/03/2022

The latest version of this documentation can be found here.

Quick-Start

In case you have already installed RD WebServices, you might want jump directly to the following topics:

• Installation (Windows)
• Installation (Linux)
• Management interface
• Network and Firewall
• Change default port
• License activation
• Configuration of RD Gateway
• Authorization policies
• Access log
• Configuration of RD WebAccess
• Publish resources
• Access published resources
• Two-Factor Authentication
• Custom WebApp
• Silent install

Remote Desktop Gateway (RD Gateway)

Remote Desktop Gateway (RD Gateway) enables authorized remote users to connect to resources on an internal corporate or private network, from any internet-connected device that can run a Remote Desktop client. RD Gateway acts as a secure proxy for external users to connect to internal network resources. It is also a convenient way to resume the work you started on your office PC.

Access is controlled by configuring authorization policies (Client and Server policies). A Client policy specifies who is authorized to make a connection, and a Server policy specifies to which network resources authorized users may connect.

Technically, RD Gateway encapsulates the standard Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted connection between remote users on the internet and the internal network resources on which their productivity applications run. This also increases compatibility with firewalls in public locations such as hotels.

The three primary purposes of RD Gateway, in the order of the connection sequence, are:

1. Establish connection: The external user connects to the RD Gateway.
2. Authenticate: The RD Gateway authenticates the user and ensures permissions to access internal network resources.
3. Pass traffic: After verification, the RD Gateway passes from the user to the destination host.

Configuration and Deployment of RD Gateway

Remote Desktop WebAccess (RD WebAccess)

Remote Desktop WebAccess (RD WebAccess) is an easy-to-use solution to allow authorized users remote access to their Windows applications and desktops on their device of choice through the internet. It provides each user with a customized view of all permissible resources.

There are two ways that users receive published resources. One way is through a webfeed, which presents the published applications in a software-parsable XML document. This feed can be used by the "RemoteApp and Desktop Connections" applet in the Windows Control Panel or by the Remote Desktop Client for iOS, macOS or Android. After the user subscribes to the webfeed, all permissible resources will be made available.

The other way is through a web browser by signing in to the web portal that is provided by RD WebAccess (https:// SERVERNAME/webaccess).

Here is an example of how your RD WebAccess URLs might look:

• Webapp: https://*SERVERNAME*/webaccess
• Webfeed: https://*SERVERNAME*/RDWeb/Feed/WebFeed.aspx

Where SERVERNAME is the fully qualified domain name of the server where you have installed RD WebServices.

Configuration and Deployment of RD WebAccess

RD WebServices Manager

RD WebServices Manager is the platform independent management interface for RD WebAccess and RD Gateway. You can simply configure your Linux installations with the client installed on Windows and the other way around.

Note: The Windows installer already contains the RD WebServices Manager application. To install RD WebServices Manager under windows separately, download the RD WebServices Manager installer from here. On Linux it needs to be installed separately if required (see installation section below).

Network resources

Network resources can be any remote desktop-enabled hosts running on Windows or Linux, such as:

Windows:

• Hosts with Remote Desktop enabled
• Microsoft Remote Desktop Session Host (RDSH/Terminal server)
• Microsoft Remote Desktop Virtualization Host (RDVH)
• Thinstuff XP/VS Server

Linux/Open Source:

• ogon project: A collection of services and tools to turn any modern Linux system into a full-featured RDP server.
• freeRDP: A free implementation of the Remote Desktop Protocol (RDP), including Client(s) and server.

Requirements and supported operating systems

Thincast RD WebServices suite is available for Windows and Linux.

Basically both versions for Linux and Windows offer the same functionality, except that on Linux Active Directory access is not supported and the local user database is used. Also, there are some minor differences regarding configuration of server certificates and listen port.

Windows

RD WebServices supports 64 bit (x64) environments on all major Windows operating systems:

• Windows 7 / 8 / 8.1 / 10 / 11
• Windows Server 2008 R2 / 2012 / 2012 R2 / 2016 / 2019 / 2022

Linux

RD WebServices are currently supported on the following versions of Debian and Ubuntu:

• Debian (amd64)
  • 10 (buster)
  • 11 (bullseye)
• Ubuntu (amd64)
  • 20.04 LTS (Focal Foss)
  • 22.04 (Jammy Jellyfish)
  • 22.10 (Kinetic Kudu)

Important Note: RD WebServices can be utilized with different virtualization technologies (QEMU/KVM, VMWare, Hyper-V or cloud based solutions) but container technologies, like docker, lxc, lxd, OpenVZ or similar are currently not supported.

Note: We are constantly working on expanding our support for Linux. Let us know if there is any Linux distribution you want to see supported.

Memory and Storage

The minimum memory required on the host system is 64 MB, but 128 MB and above is recommended. For RD Gateway you can roughly calculate of 1 MB additional memory per client.

RD WebService needs at least 128 MB of available disk space for the application. If you have enabled access login, this amount can increase depending on the number of connections. Icons are cached for each RD WebAccess resource.

Network and Firewall

RD WebServices requires a properly configured network.

All the data between the clients and RD WebServices is transferred by using the secure HTTPS protocol. By default, the HTTPS standard port 443 is used. Please make sure that this port is open in your external firewall. On Windows RD WebServices automatically configures your firewall during installation.

There are two different network designs for integrating RD WebServices in your environment:

1. RD WebServices inside your LAN

Use the RD WebServices server inside the LAN and allow port 443 in the firewall between the internet and the RD WebServices server.

2. RD WebServices in DMZ

By putting the RD WebServices in a DMZ, you can isolate the RD WebServices from your LAN. You must open port 443 between the internet and the RD WebServices server and, for example, port 3389 between the RD WebServices server and the LAN. This setup requires advanced experience with firewalls and network configuration.

Installation

Windows

1. Download the latest version of RD WebServices for Windows from here.
2. Open the installation package.
3. RD WebServices Setup will now open. Continue with "Next".

4. Select the "Install" Checkbox and click on "Next".

5. Read and accept the End-user License Agreement and proceed with "Next".

6. Select the destination folder for RD WebServices and click on "Next".

7. Click "Finish" to complete your installation.

8. You have now successfully installed RD WebServices. It can be found in your start menu or under the destination folder you specified.

Silent install

A "silent install" is the installation of a software program that requires no user interaction.

In order to perform a "silent install" of RD WebServices just follow these tasks:

1. Download the latest version of RD WebServices from here.

2. Open the exe with 7zip and extract the included msi installer.

3. Run the msi installer silently on the target server like this:

   msiexec /quiet /norestart /i Thincast-RDWebServices-x64-1.0.550.0-stable.msi

   or if you want to wait until msiexec completes:

   start /w msiexec /quiet /norestart /i Thincast-RDWebServices-x64-1.0.550.0-stable.msi

   The RD WebServices service should now be running on its default port 443.

4. In order to manage it from another machine you need to install the standalone version of the RD WebServices Manager GUI as described here.

Linux

For Linux the RDWebServices installation relies on the distribution package management. Regardless of the distribution there are two available packages:

• rdwebservices - contains the core services
• rdwebservices-manager - contains the management interface

Before you install RDWebServices on Linux please ensure that your machine has set a fully qualified domain name (FQDN). Clients that connect with the RDP gateway protocol require a certificate that matches the full hostname of the machine. For Debian/Ubuntu you should simply add the FQDN at first in /etc/hosts. For example:

127.0.0.1 rdwebservices.testing.thincast.com rdwebservices

Note: If setting the FQDN is not possible when install rdwebservices you can still replace the certificate later.

Installation

1. Install required packages

apt install curl

2. Add the Thincast stable repository. Note: If you want to do a pre-flight check have a look at install.sh here.

curl https://packages.thincast.com/deb/install.sh | sudo bash

3. Install RD WebServices

apt install rdwebservices

After running the commands from above RD WebServices is installed and started with a default configuration.

If you want RD WebServices Manager installed as well run:

apt install rdwebservices-manager

Note: As RD WebServices Manager requires a full X11 and Qt environment we do not recommend to install it on the same machine as the WebServices in production.

Update

Windows

RD WebServices has a built-in check for updates. Every time an RD WebServices Admin GUI connects to an RD WebServices service, a check for a new version for that service is performed. If a new version is available, an info bar is shown in the RD WebServices Admin GUI and can be downloaded in the 'Server' section under the 'Settings' tab.

Check for updates

To check for updates, go to Help -> Check for updates in the menu bar of RD WebServices Manager.

If a new version is available, a notification window will be displayed.

Linux

All installed RD WebServices packages are automatically updated if you update your distribution. For example with:

apt update
apt full-upgrade

Uninstallation

Windows

1. To uninstall RD WebServices, open your Settings and navigate to Apps & features. Select RD WebServices and click on " Uninstall".

Linux

Simply remove the package using apt:

apt remove rdwebservices

Configuration and Deployment

This chapter describes how to configure RD WebServices and its components for use.

Open the RD WebServices Manager and connect to the machine where RD WebServices are running.

• Windows: You can use any user account that is a member of the local Administrator group.
• Linux: For initial configuration you can use the user Administrator with the password found in /etc/rdwebservices/RDWSUsers.administrator.overwrite.cfg (Note: Once you have set a password for the Administrator user the file is removed automatically)

To simply get the password:

grep . /etc/rdwebservices/RDWSUsers.administrator.overwrite.cfg

Overview

In the overview pane you can see the overall status of RD Gateway and RD WebAccess, if they are running, and if the licensing is valid. For quick access, the WebFeed URL and the link to the web frontend of RD WebAccess are displayed.

Server settings

In the server settings pane, you can configure the overall settings for RD WebAccess such as changing the default server port, enabling or disabling services, importing a certificate or installing a license.

Change default port

The default server port is 443. Sometimes it is necessary to change this, such as when you are already running another service on this port.

Windows

1. Type in the port number.
2. Click on "Save" and confirm the service restart.

Linux

You can change the port of the service by changing the PORT setting the file /etc/default/rdwebservices:

For example if you want the service to listen on port 8443, you would change PORT to:

PORT="-p 8443"

After modifying the file make sure you restart the systemd service:

systemctl restart rdwebservices

Disable/Enable services

If you wish to disable RD WebAccess or RD Gateway manually and prevent it from starting, check the box and click "Save". Currently opened RD Gateway connections or opened webapp connections will continue to work until the client or browser closes the connection.

Certificate

To establish a secure connection between RD WebAccess and the end user, a private and a public key are required to encrypt the connection. These keys are included in the certificates.

You can obtain a certificate in several ways:

• Upload an existing certificate.
• Create a self-signed certificate.
• Purchase a certificate from a certification authority (CA).

For testing and evaluation purposes, we recommend to use a self-signed certificate.

To view the details of the currently used certificate just click on "Details" next to the certificate.

Upload an existing certificate (Windows only)

This chapter describes how to upload an existing certificate in the .pem/.pfx format using the built-in Certificate Wizard.

1. To upload/import an existing certificate please click on "Upload certificate" in order to open the built-in Certificate Wizard, then select the file format of your certificate. The certificate has to be in either .pem or .pfx format.

2. Click on "Select Certificate" and navigate to the folder containing your certificate file, select it and click "Next".

3. Depending on the file format of your certificate either select your private key file or enter the required password for the certificate.

• .pem certificate:

  Select your private key file by clicking on "Select Private Key" and click on "Next".

  

• .pfx certificate: Enter the password for your certificate and click on "Next".

  

4. In case you have imported a .pem certificate you can also deliver the certificate chain. Select your chain file by clicking on "Select Chain" and click on "Next". This step is optional and does only apply to .pem certificates.

5. To complete the certificate upload click on the checkbox and click on "Finish". The certificate will be uploaded and installed. Please note that RD Web Services will be restarted.

Create a self-signed certificate (only on Windows)

This chapter describes how to create a self-signed certificate.

You need to specify the hostname which the RDP client uses to connect to the RDP WebServices server.

Production environment:

For production usage, you should use the complete domain name of your server, also known as the Fully Qualified Domain Name (FQDN).

The FQDN consists of two parts: the hostname and the domain name. For example, an FQDN for a hypothetical test server might be testserver.mycompany.com. The hostname is testserver, and the host is located within the domain mycompany.com.

Testing environment:

For testing purposes you can also use the internal hostname or the IP address (NetBIOS, FQDN or IP address).

1. Click "Create self-signed certificate".
2. Enter the "Hostname" that the RDP client uses to connect to the RD WebServices server.
3. Click "OK".
4. A new self-signed certificate is now installed.

Certificate configuration on Linux

On Ubuntu and Debian the snakeoil certificate provided by the ssl-cert package is used. To change the certificate, modify the KEY and CERT variables in the file /etc/default/rdwebservices.

For example, this is the configuration to use the my-corp certificate (assuming they are in the standard certificate location):

KEY="-k /etc/ssl/private/my-corp.key"
CERT="-c /etc/ssl/certs/my-corp.pem

After modifying the file, make sure you restart the systemd service:

systemctl restart rdwebservices

Download certificate

To establish the SSL session with the server, the client needs to validate the server certificate. Therefore, the client must have the certificate installed in its "Trusted Root Certificate Store".

You can obtain a certificate for the client computer by doing the following:

1. Click on "Download certificate".
2. Select the certification format. Use DER encoded certificate for Android and IOS devices.
3. Select the path where RD WebServices should save the client certificate. The certificate will be saved in .crt format.
4. Import this certificate into your client's "Trusted Root Certificate Store".

User Management (Linux only)

On Linux, RD WebServices uses an independent local user database for user authentication. All user and group related settings are found in the Users pane on the left in the RD WebServices Manager.

Configure the domain

Before you can get started, a DNS and NetBIOS name needs to be configured. Both names are required for authentication and can be chosen freely:

1. Open the "Domain" tab and click "Edit/Setup Domain"

2. Set the NetBIOS and DNS domain name and click "OK".

When Reset all Users and Groups is checked, all existing users and groups are deleted. This option should be handled with care. It is not necessary if you initially setup the domain but might be useful if you change your domain name and want to start with an empty domain.

Note: For simplicity we recommend to use a similar name for DNS and NetBIOS.

Create and manage users

In the Users tab you can manage your users.

To create a user, simply click the Add button on the right and fill out all required fields in the dialog that is shown.

For existing users, editing or changing the password can be done by right-clicking the user.

Create and manage groups

Groups are used within RD WebServices for different purposes:

• RD Gateway
  • to allow/restrict access
    • for Server/Client policies
• RD WebAccess
  • to allow/restrict access
    • for resource assignment

There are two built-in groups named Users and Administrators. Users that are in the Administrators group are entitled to manage RD WebServices. The Users group is used for default policies and access. Newly created users are automatically added to the Users group.

Groups are managed in the Groups tab of the Users pane.

To add a new group press the Add button on the right. Once created, you can add or remove users to a group by editing it using the Edit button.

Set the password for the management user

Administrator is a built-in management user that cannot be removed. The user is a member of the Administrators and Users groups.

To set the password for the Administrator user:

1. In the Users pane, go to the 'Users' tab
2. Right-click on the root user and choose Set password
3. Once you have entered the same password twice, click 'OK'

Note: Once you have configured another user that is member of the Administrators group, the Administrator user is not needed and can be disabled.

Licensing

When you purchase a product from Thincast via our website, a corresponding license is created and added to My licenses in your account once the order is completed (paid).

Licenses issued by Thincast can only be used on one device at a time. You need to activate your license to be valid. The activation binds a license to a specific computer.

More information can be found in our Licensing documentation.

Advanced Settings

Authentication cookie

A sha256 key is used in cookie generation.

When load balancing is used to access RD WebAccess, the servers should share the same key, so the authentication cookie works for all servers. If a cookie is revoked, causing all users to re-authenticate, the simplest way is to change the key.

Custom WebApp

Thincast RD WebAccess comes with an integrated web application to allow client-less access to the RDP connection files. By providing the web application sources, you can customize the web application and adapt it for your clients.

By default, the integrated web application will be displayed. In case you want to deliver your customized version of the web application do the following:

1. Tick the checkbox "Custom WebApp".
2. Specify where the folder is on your system (e.g. C:\temp\webapp-external).
3. Click on "Save".

You can find the source code here, which is a great foundation to start your customized web app.

Allowed Manager IP Addresses / Ranges

Thincast RD WebServices allows to restrict the access of the RD WebService Manager, to only allow management from known secure IP addresses.

To enable the access restriction, add an IP address or an IP address range, from where the RD WebServices Manager should be allowed to connect from. To allow any IP addresses, remove all configured IP addresses and ranges.

Security Settings

Authentication cookie

A sha256 key is used in cookie generation.

When load balancing is used to access RD WebAccess, the servers should share the same key, so the authentication cookie works for both servers. If a cookie is revoked, causing all users to reauthenticate, the simplest way is to change the key.

SSL Settings - Supported TLS protocol versions

RD WebServices uses Transport Layer Security (TLS), to ensure a secure communication between server and client. TLS has different versions (1.0, 1.1, 1.2 and 1.3), versions 1.0 and 1.1 were deprecated in 2020.

RD WebServices uses the following default settings:

TLS protocol level	enabled
1 (1.0)	no
1.1	yes
1.2	yes
1.3	yes

Per default version 1.0 is disabled and versions 1.1 to 1.3 are enabled.

In some situations - like if there are older RDP clients in the field or a tightened security is required - it might be necessary to overwrite the defaults.

Two-Factor Authentication (2FA)

RD WebServices supports two-factor authentication, using the RD Authenticator App available for Android and iOS.

Enable Two-Factor Authentication

Enable Two-Factor Authentication support.

Auto Registration

The Auto Registration mode allows users to register an authenticator without using a token, only using username and password. The Auto Registration mode allows to register only one device without a token and only if the user was not registered before. Use the Auto Registration Mode with care.

RD Gateway

Enable two-factor authentication support for RD Gateway. If enabled (and a two-factor authentication user was created or 'Force 2FA Authentication' is set) users have to confirm each login to the RD Gateway. If the user denies the confirmation or the confirmation request times out, the RDP connection is disconnected.

RD WebAccess (Website)

Enables two-factor authentication support for the RD WebAccess Website. If enabled (and a two-factor authentication user was created or Force 2FA Authentication is set), users have to confirm each login to the RD WebAccess website.

Force 2FA Authentication

Forces all users to use two-factor authentication. If there is no 2FA-User created, access will be denied. If 2FA is disabled, users without 2FA-User can log in without passing the RD Authenticator.

Authenticator timeout

Defines the period of validity for an authentication request. If the authentication request times out, login will be denied.

QR Registration Code timeout

Defines the period of validity for a created QR Registration Code in the QR Client WebApp and the RD WebServices Manager. If the period of validity is over, the QR code can not be used for registering a new RD Authenticator App anymore.

Number of tokens to generate for each user

Defines the number of registration tokens which will be created for each user if a user is newly created or if a new set of tokens is requested through the RD WebServices Manager.

Authenticator Custom WebApp

Thincast RD WebServices comes with an integrated web application to allow input-less registration of a RD Authenticator App after logging in to the webapp and scanning the generated QR code with your RD Authenticator App. By providing the web application sources, you can customize the web application and adapt it for your clients.

By default, the integrated web application will be displayed. In case you want to deliver your customized version of the web application, do the following:

1. Tick the checkbox "Authenticator Custom WebApp".
2. Specify where the folder is on your system (e.g. C:\temp\webapp-external-qrclient).
3. Click on "Save".

You can find the source code here, which is a great foundation to start your customized web app.

Two-Factor Authentication Users (2FA-Users)

To use two-factor authentication a 2FA-User is required for each user. If no 2FA-User is defined, that user can not login if two-factor authentication is required (Force 2FA Authentication is enabled).

Edit 2FA-User

Display details about the 2FA-User like 'username' (with domain) and if the user is still allowed to use the auto registration feature. Also, all registered RD Authenticator apps are listed. To disable a RD Authenticator, delete the registration for that RD Authenticator.

Click 'Show' to display the currently selected RD Authenticator registration.

Tokens

The 'Tokens' tab displays the currently active token set. Used tokens are removed from the token set automatically and therefore only usable tokens will be displayed.

An RD WebServices Administrator can generate tokens in behalf of the user to register a bunch of RD Authenticators for example if a bunch of new phones are prepared for employees.

Therefore, click Show QR Code and select the token which you want to use for generating the QR image.

If a token set is used up or got out of hand, a new set of tokens can be generated by clicking 'Request new token set'. After that it's important to save the configuration, because the new token set is generated by RD WebServices.

To copy the whole token set into the clipboard, click Copy to Clipboard.

Logging

Network Events logging

To use tools like fail2ban or similar to prevent Brute-Force attacks, RD WebServices writes logs for each access to a resource or each authentication. It's also possible to log only errors or successful access to a resource.

Network Events log format

The logfile uses the comma-separated values (csv) format.

The following values are logged:

1. time : The time of the event.
2. event type: The event type, like 'ERROR' or 'OK'.
3. module: The module which created this log entry.
4. clientIP: The client IP address.
5. username: The authenticated username, if available.
6. status: The status code, which led to the result of the request.
7. url:The request URL.

Example logfile:

time,event type,module,clientIP,username,status,url
2021-Jul-26 11:14:37,OK,http,192.168.50.43,,200 OK,/webaccess/index.html
2021-Jul-26 11:14:38,OK,http,192.168.50.43,,200 OK,/webaccess/webaccess.css
2021-Jul-26 11:17:38,OK,auth-basic-thrift,192.168.50.43,demo1,SUCCESS,-
2021-Jul-26 11:27:41,ERROR,http,::1,-,404 Not Found,/webaccess/index.html.test
2021-Jul-26 11:28:14,ERROR,auth-basic-thrift,::1,notauser,1326,-

Gateway

In this chapter we will walk through a typical RD Gateway configuration.

Using the RD Gateway Manager tool, the RD Gateway can enforce client policies to restrict which users are allowed to connect. You can also enable or disable specific device redirection in the client policies.

Furthermore, Server policies provide restrictions based on group membership. These restrictions allow to manage access to network resources.

Overview

In the RD Gateway overview tab you will see all status information about your RD Gateway server, such as:

• Total number of connections
• Number of connected users to RD Gateway
• Number of resources that these users are connected to
• Number of configured policies

Authorization policies

RD Gateway uses authorization policies to control remote user access and remote connections to internal network resources behind your firewall:

• Client policies
• Server policies

A Client policy specifies who is authorized to make a connection, and a Server policy specifies to which network resources authorized users may connect.

RD Gateway will evaluate the configured policies in ascending order. If the first criteria is not met, RD Gateway will evaluate the second policy, etc. until one policy fits. If none of these settings is met, the remote access is denied.

If you want to delete or edit any of the existing policies (Client or Server), right-click in the context menu and select 'Delete' or 'Edit'.

Client policies

Client policies allow the administrator to specify connection criteria that have to be met to connect to the RD Gateway server:

• Define the user- and computer-groups who are allowed to establish connections to the RD Gateway.
• Disable/restrict device redirection for specific client devices.

By default, one policy is preconfigured to allow all users (i.e., user-group) to access the internal network. It is likely that you will want to narrow the scope of access for production environments.

Create a Client policy:

In the "Client Policies" tab you will find the Create New Policy button at the bottom right.

A Client policy is divided into 3 sections:

• General
• Requirements
• Device redirection

Once the policy configuration is done, click "OK" to enable the new policy.

General

Specify the name of the new policy – in our example, "Home Office Users".

You can also enable/disable the policy and find a summary of the Client policy here.

Requirements

• User-group membership (required)

  Add the users or user-groups that are allowed to use internal resources. To specify a user-group (i.e., which members can connect to the RD Gateway), click "Add Group".

• Client computer IP addresses

  Specify the client’s computer IP address/range to allow or restrict access to RD Gateway for specific IP addresses.

Device redirection

Enable or disable client device redirection for computers that connect to the RD Gateway.

You can choose between the following settings:

• Enable device redirection for all client devices.
• Disable device redirection for all client devices except for smart card.
• Disable device redirection for specific client device types (select separately between Drives, Clipboard, Printers, Serial Ports and Supported Plug and Play devices).

Server Policies

Server policies allow to specify the internal network resources (remote desktop hosts, computers, etc.) that remote users can connect to through the RD Gateway:

• Define which user-groups can establish connections to specific RDP-enabled hosts in your private network.
• Restrict access to specific ports (e.g. 3389).

By default, one policy is already preconfigured to allow all users to access the internal network on all ports. It is likely that you will want to narrow the scope of access for production environments.

An example for a Server policy would be:

You might specify that external employees (members of group "External") may only connect to terminal server 1, while internal employees (group "Internal") might access terminal server 2.

Create a Server policy:

In the "Server Policies" tab you will find 'Create New Policy' on the bottom right.

A Server policy is divided into 4 sections:

• General
• User / Groups
• Address / Range
• Allowed Ports

Once configuration for the policy is completed, click "OK" to enable the new policy.

General

Specify the name of the new policy and add a description.

You can also enable/disable the policy and find a summary of the Server policy here.

User / Groups

A Server Policy is applied to user-groups. To add a user-group, click 'Add Group'.

Address / Range

Specify the server computer IP address(es)/range to which this Server policy should apply. Click "Add Address" and enter either a single host (as IP address with a host range, NETBIOS name or DNS name) or a range of IP addresses (as IP address with a range).

Example: Suffix "32" specifies one specific host

Allowed Ports

By default, remote desktop clients connect to network resources remotely through TCP port 3389. Specify whether to use the default RDP port or a different one.

Monitoring

Live monitoring

To observe all active connections using the live monitoring of RD Gateway, switch to the tab called "Monitoring".

The following connection details can be observed:

• ID
• User Name
• Client IP Address
• Connected On
• Duration
• Idle Time

Disconnect a session/user

To disconnect a session/user, select the session, right-click and choose from the context menu:

• Disconnect this session
• Disconnect this user

Settings

Only allow connections from clients that support Remote Desktop messaging

Enabling these settings will check if Remote Desktop Messaging is supported by the Remote Desktop Client in use, otherwise the connection will be rejected by the RD Gateway.

To enable this setting tick the checkbox "Only allow connections from Remote Desktop clients that support Remote Desktop messaging" and click on "Save".

Limit the number of concurrent connections

RD Gateway accepts the number of connections limited by the installed License. But, you can also limit the maximum number of concurrent connections here.

Access log

To enable the access log, tick the checkbox and click "Save".

By default, the log file is located under:

• Windows: C:\ProgramData\Thincast\RDWebServices\log\RDGatewayAccess.log
• Linux: /var/log/rdwebservices/RDGatewayAccess.log

Logon banner message

Logon message

Create a message, such as a legal notice, to display to users each time they log on to a remote computer:

1. Enter log on message.
2. Click "Save".

System Message

Create a message to display to users who are logged in to a remote computer, such as system maintenance notification. Note: Not all Remote Desktop clients support such messages.

1. Enable system messaging.
2. Enter system message.
3. Specify start time / end time for this message.
4. Click "Save".

Webaccess

Remote Desktop WebAccess (RD WebAccess) allows authorized users to remotely access their Windows apps and desktops on their device of choice through the internet. It provides each user with a customized view of all resources that have been published to that user.

AllowList

When using RD WebAccess with a "Basic" and "Standard" license, the users or groups must be individually pre-selected and given access. Whitelisting is mandatory here!

In the "Pro" version of RD WebAccess this is optional, but you can still specify and whitelist users and groups for access.

RDP Signing

RD WebAccess has built-in support to distribute signed RDP files.

If enabled, the installed certificate is used to sign your distributed remote desktop resources. By signing RDP files with trusted certificates, the client verifies that important settings have not changed since the creation of the RDP file.

This enables clients to recognize your organization as the source of the remote resource, and allows them to make more informed trust decisions about whether to start the connection.

To enable the distribution of signed RDP files through RD WebAccess please tick the checkbox "Sign all generated RDP Files" and click "Save".

In case a client opens a RDP file which has not been signed, a warning message, saying that the publisher of this RDP file is not trusted, will be displayed.

Import certificate (required for self-signed certificates)

In case you have used a self-signed certificate for signing your RDP files, the client needs to validate the server certificate. Therefore, the client must have the used certificate installed in its "Trusted Root Certificate Store".

WebFeed name and descritpion

Configure the RD WebFeed name and description. The usage of these attributes highly depends on the WebFeed client.

• The Microsoft RD WebFeed client integrates the RDP connections in the Windows start menu and uses the RD WebFeed name as sub menu name and appneds it in brackets behind the actual connection name.
• The Thincast RD WebAccess client uses the RD WebFeed name in the headline of each RD WebFeed connection.

Publish resources

In this chapter you will learn how to publish customized views of remote applications and full desktop experiences for individual users or user-groups and assign them to Remote Desktop servers.

Depending on your users' needs, you can choose between publishing a full desktop experience or a remote application:

Desktop

Provide a fully managed desktop solution to your end users. This allows IT to control everything, from the application installs to the security policies, and even where the data is stored.

RemoteApp

RemoteApp delivers only the specific application to the end user device. The application still "runs" on the Terminal server, but appears as if it is running directly on the user's device.

A typical example for RD WebAccess could be:

All members of the user-group "Sales" will find their sales application in their webfeed which runs on the internal Remote Desktop server ("192.168.0.3")

In this case, we have to add a remote app resource for the sales application. Additionally, we have to add the Remote Desktop server ("192.168.0.3"), where the application is installed.

Remote connections

This section allowes preconfiguring remote connections (downloadable RDP files), adapted to users' needs.

To add a resource click "Add" in the Remote Connection tab.

General Settings

Setting	Description
Icon	Specify the application icon
Type	Specify if RemoteApp or Desktop
Title	Title of resource
Remote Desktop Server	Select the destination host
Folder	Specify a folder
Custom Settings	Add specific custom settings to your resource

Icon

Select the icon to use for this remote connection (RDP file).

Type

From this list, you can choose the type of connection you want to establish. This can be either a full desktop session or a seamlessly integrated remote application.

Title

Title of the resource is shown in all clients as the name of the remote connection (RDP file).

Remote Desktop Server

Select a previously defined Remote Desktop server or create a new one.

Folder

If supported by the RD WebAccess client, the resources are grouped and displayed in folders.

Custom Settings

It is possible to specify custom RDP file settings. These settings are added to the generated RDP file.

Display

The display settings are only available if you have selected Desktop as connection type.

Display Configuration

• The slider lets you choose the resolution of the remote desktop. If you move the slider to the far right side, the remote desktop will use the same resolution as your local desktop and the session will be displayed in full screen mode.
• If you want to use all your monitors for the remote session the application automatically uses full screen mode.
• Select Span if your target session’s desktop should become a huge rectangle that equals the whole area of your physical monitors.

Colors

Colors allow you to configure the color depth. The options are as follows:

• High color (15 bit)

• High color (16 bit)

• True color (24 bit)

• Highest color (32 bit)

Connection bar

Select if the connection bar should be displayed in the remote session when using full screen.

Program

Program path and filename

Specify the path of the application that you want to launch e.g., C:\Windows\notepad.exe.

Use the following command line arguments

Depending on your application you might want to add additional command line arguments e.g., C:\data\test.txt to open a file.

Start in the following folder

Select the folder that the application should use as its working directory.

Local Resources

The Local Resources tab is an important one. It is used to configure whether resources on the client system can be accessed inside the Remote Desktop session. The configuration includes remote audio, keyboard, and local devices and resources. From a security standpoint the local devices and resources option is the most important.

Remote Audio

The remote audio option is used to configure audio playback and recording.

• Remote Audio Playback: Choose if audio should be played on the remote computer, local computer or be muted.
• Remote Audio Recording: Choose if you want to record audio from your local computer.

Keyboard

Lets you specify how keyboard commands like WIN or ALT+TAB will be processed. The default is to send them to the session only when the connection is in full screen mode.

Local devices and resources

You must be careful when allowing local resources to be used within a Remote Desktop session. If you enable local resources, then the server you are connecting to can gain access to resources on your system. If you do not trust the remote system, you should not redirect local resources. You can configure the following items:

• Ports
• Smart cards
• Drives
• Plug and Play devices

One of the key items that can be configured here are disk drives. Enabling disk drives can potentially give harmful code on a remote server access to all the files on your local system. Therefore, you must be especially careful when enabling this option.

Experience

The experience tab allows you to configure options that affect the user experience.

Performance

The list provides a selection of predefined profiles for different connectivity scenarios. If you do not know exactly what you are doing you should always use the default option which allows the client to automatically detect and adjust to your current network characteristics:

• Modem (56 Kbps).
• Low-speed broadband (256 Kbps – 2 Mbps).
• Satellite (2M bps – 16 Mbps with high latency).
• High-speed broadband (2 Mbps – 10 Mbps).
• WAN (10 Mbps or higher with high latency).
• LAN (10 Mbps or higher).

Based on the bandwidth option chosen, the following features will be enabled or disabled by default:

• Desktop background
• Font smoothing
• Desktop composition
• Show window contents while dragging
• Menu and window animation
• Visual styles

The 'Experience' tab also allows you to enable the "Persistent bitmap caching" and "Reconnect if the connection is dropped" options.

Security

Server authentication is used to verify that the server you are connecting to is the server you intended to connect to. Here you can configure the behavior in case the server authentication fails.

• Connect and don’t warn me: This is the least secure option. If the server authentication fails, the connection will still be made. In addition, the user will not be notified of the failure.
• Warn me: This option is more secure, and it gives the user a choice. If the server authentication fails, the user will be notified. The user can choose whether to make the connection or drop it.
• Do not connect: This is the most secure option. If the server authentication fails, the connection will not be made to the remote server.

Remote Desktop Servers

This is where you specify the remote computer to which you would like to connect. You can use a NetBIOS name, a FQDN or an IP address.

Name

Specify the name of your Remote Desktop Server. This will be displayed when you assign a resource to a specific RD Gateway server.

Server

This is where you specify the remote computer to which you would like to connect. You can use a NetBIOS name, a FQDN or an IP address.

RD Gateway server

This section allows you to configure settings for using a Remote Desktop Gateway. An RD Gateway server allows you to secure Remote Desktop connections from outside your organization. The options are as follows:

Name

Specify the name of your RD Gateway server. This will be displayed when you assign a resource to a specific RD Gateway server.

Connection Settings:

• Server name
• Logon method
  • Allow me to select later
  • Ask for password
• Bypass RD Gateway server for local address

Logon Settings:

• Use my RD Gateway credentials for the remote computer

WorkStation Add On

This section allows you to use the Thincast Workstation Add On, in order to create a fine-grained and secure user access management for virtualized machines running on Thincast Workstation. The available virtual machines will show up in the webfeed or web interface of the subscribed user. It is even possible to start, stop or pause the virtual machines remotely.

Enable Add On

To enable a Thincast Workstation instance, you need to enable the Add-On by clicking the checkbox "Enable Thincast Workstation AddOn" Then click "Save".

Add an instance

To add an existing Thincast Workstation instance click "Add" to open the Thincast Workstation Agent. Now specify the connection details of your Thincast Workstation instance.

Settings:

• Enabled
• Thincast Workstation
  • Host
  • Port (Default port is 33333)
• User
  • UserName
  • Password
• RD Gateway server (Default port is none)
• Specify the RD WebAccess users/groups (Default is Users)

In our scenario we would like to add one instance of Thincast Workstation and assign it to all users, which means every user in the user-group "BUILTIN/Users" should have access to the virtualized desktops.

To test the connection, click "Test and Save". The Thincast Workstation Agent will notify you if the connection settings are wrong or the instance is currently not available.

After successfully adding your Thincast Workstation instance, it will appear in the list and in the webfeed of the users after a refresh.

Access published resources

There are two ways users can receive published resources (RDP files):

Desktop or mobile clients

One way is through the webfeed, which is represented by a standardized XML format that the clients can parse.

Subscription to this webfeed is supported by Thincast Client or other clients, like the "RemoteApp and Desktop Connections" applet in the Windows Control Panel or the Remote Desktop Client for iOS, macOS or Android.

After the user has subscribed, the resources will automatically be added and updated in his feed.

Web Application

The second way to display user's resources is through a Web browser by signing in to the website that is provided by RD WebAccess.

• Webapp: https://*SERVERNAME*/webaccess
• Webfeed: https://*SERVERNAME*/RDWeb/Feed/WebFeed.aspx

RD Authenticator App

The RD Authenticator App is used for two-factor authentication. After registering the RD Authenticator for a user (either through the RD QR Client and a QR code or by manually entering the registration information), each login needs to be authorized with the RD Authenticator App.

The RD Authenticator App is available for Android and iOS.

Initial Setup

After the first startup, the initial setup screen is shown.

Before first use, you have to set a pin code. Its important not to lose your pin code. In the case the pin code gets lost and biometric authentication does not work, the only way is to reset the RD Authentication app and register again.

It's also possible, in addition to the pin code, to use biometric authentication, like for example your fingerprint. The biometric authentication has to be enabled and setup on your device.

Settings

Enable biometric support

Enable to use biometric authentication, for example fingerprint instead of the pin code. The biometric authentication has to be enabled and setup on your device first.

Time before new authentication is needed

Specifies the time after a successful authentication (pin code or biometric authentication), no authentication is needed for accepting or denying requests. After the timer has expired, a new authentication is required for accepting or denying requests.

Set new pin code

To change the pin code, first enter the current pin and then two times the new pin to ensure the pin matches.

Main view

The RD Authenticator checks for new authentication requests every ten seconds. To refresh the list of pending authentication requests immediately, press the refresh button found on the top right of the main screen.

Registrations

To add or edit a RD Authenticator registration, click on the menu icon (top left in the main view) and select 'Registrations'.

An overview of registrations is shown. If there are any issues with a registration a red warning sign will be shown along the last error.

Click on a record to show the registration details. It's also possible to delete a registration within the details view.

To delete a registration from the overview, just swipe the registrations to the left.

Registering an RD Authenticator

It's possible to register an RD Authenticator in two ways:

• Scanning a QR Code
• Entering the registration information

QR Code Registration - User

To register a RD Authenticator using a QR code, you need to log into the RD QR Client WebApplication. Open a browser with the following Url: https://:/qrclient/index.html.

Enter username, password and an unused token (including the <number>: prefix) you received from your administrator to show the registration QR code. To use the auto registration mode (if it's enabled and you have never registered an RD Authenticator), do not enter a token and instead click 'Show QR Code'.

In the RD Authenticator APP on your device, press the blue 'Add' Icon on the bottom right to open the QR code scanning view.

Now enter your device description and press 'Register'

If an error occurred, the view changes back to the QR code scanning view and will display the error message.

If the registration of the RD Authenticator was successful, the registrations overview will be displayed.

QR Code Registration - Administrator

If an administrator prepares a bunch of devices for some employees, they can register the devices on behalf of the users.

Open the RD WebServices Admin panel and connect to the RD WebServices server. Navigate to Server / 2FA-Users, select the desired user and click edit. Switch to the Tokens tab and click 'show QR code'. It's possible to change the used token by selecting another valid token from the dropdown.

Now scan the QR code with the user's device and the RD Authenticator APP will be registered on this server.

Entering the registration information

Either do a long press on the add icon in the overview or press 'Manual Registration' in the QR code scanning view.

Enter device description, hostname and port, username and password and one of your registration tokens (or none if auto registration mode is enabled and no registration took place for this user so far). Press 'Register'.

Two-factor authentication requests

If two-factor authentication is required, open the (already registered) RD Authenticator App on your device. After the login, all pending authentication requests are loaded from the server(s) and the most recent request is opened automatically in the detailed view. If there are two or more request they will be displayed in the overview list. It's possible to allow or deny a request in the overview by swiping to the right (allow) or the left (deny). Touching a request displays more detailed information about it.

The current client name, in the case of an RD Gateway login, will be shown besides the username and the location of the client (if it is resolvable). The big progress circle shows the remaining time before the authentication requests becomes invalid.

To accept the request press 'Allow', otherwise hit 'Deny' or the back arrow to do nothing and go back to the overview.

Support

If you have any trouble with RD WebServices, please don't hesitate to contact us by filling out our contact form.

Anything you (dis-)like or miss? Please let us know - we love to hear your feedback.

Changelog

The changelog can be found here.

Appendix

RD Gateway and Reverse Proxy

In the official RD Gateway protocol non RFC conform HTTP headers are used. Therefore, a reverse proxy needs to support this in order to work with any gateway:

• For the RPC over http transport, a content size of 2 - 4 gigabytes is used, which leads to a read timeout, if the proxy tries to read the whole request.
• For the http transport, no content size is sent in headers, this also leads to a read timeout, if the content length is mandatory in the HTTP header for the reverse proxy.

We have tested the following reverse proxies:

1. Apache with mod_proxy has no support, the connection will be rejected.
2. HAProxy has built in-support for RD Gateway connections.

HAProxy - Configuring Remote Desktop Gateway

Other reverse proxies may also work, but have not been tested yet.

HAProxy config

Using HTTP SSL bridging mode

In this mode the ssl connection is decrypted on the frontend and encrypted on the backend using the http layer.

frontend fe_rdp_tsc
  bind :444 name rdp_web ssl crt hacert.pem
  mode http
  capture request header Host len 32
  log global
  option httplog
  timeout client 300s
  maxconn 1000
  default_backend be_rdp_tsc

backend be_rdp_tsc
  balance leastconn
  mode http
  log global
  option httplog
  timeout connect 4s
  timeout server 300s
  option httpchk GET /status
  cookie RDPWEB insert nocache
  default-server inter 3s    rise 2  fall 3
  server srv01 192.168.50.43:443 maxconn 1000 weight 10 ssl check cookie srv01
  server srv02 192.168.50.44:443 maxconn 1000 weight 10 ssl check cookie srv02

Using TCP SSL bridging mode

In this mode the ssl connection is decrypted on the frontend and encrypted on the backend using the tcp layer.

frontend fe_rdp_tsc
  bind :444 name rdp_web ssl crt hacert.pem
  mode tcp
  log global
  option tcplog
  timeout client 300s
  maxconn 1000
  default_backend be_rdp_tsc

backend be_rdp_tsc
  balance source
  mode tcp
  log global
  option tcplog
  timeout connect 4s
  timeout server 300s
  option httpchk GET /status
  default-server inter 3s rise 2 fall 3
  server srv01 192.168.50.43:443 maxconn 1000 weight 10 ssl check check-ssl
  server srv02 192.168.50.44:443 maxconn 1000 weight 10 ssl check check-ssl

Using TCP bridging mode

A TCP connection is established between the client and the backend, therefore no ssl decryption is done by HAProxy.

This methode is not recommended since each backend server needs to use the certificate from the HAProxy, otherwise mstsc will complain because the gateway name does not match the certificate name.

frontend fe_rdp_tsc
  bind :444 name rdp_web
  mode tcp
  log global
  option tcplog
  timeout client 300s
  maxconn 1000
  default_backend be_rdp_tsc

backend be_rdp_tsc
  balance source
  mode tcp
  log global
  option tcplog
  timeout connect 4s
  timeout server 300s
  option httpchk GET /status
  default-server inter 3s rise 2 fall 3
  server srv01 192.168.50.43:443 maxconn 1000 weight 10 check check-ssl
  server srv02 192.168.50.44:443 maxconn 1000 weight 10 check check-ssl