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.


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

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 to 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:

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 Mananger under windows separately, download the RD WebServices Mananger 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:


  • 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.


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


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 virtualisation 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.

  1. 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.



  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".

Installation wizard start up

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

Choose bootstraper action

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

End-user license agreement

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

Choose install location

  1. Click "Finish" to complete your installation.


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

Start Menu

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 it's default port 443.

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


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 certifcate that matches the full hostname of the machine. For Debian/Ubuntu you should simple add the FQDN as first in /etc/hosts. For example: rdwebservices

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


  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 here.
    curl | 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.



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.

Update Notifiation

Check for updates

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

Check for Updates

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


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

apt update
apt full-upgrade



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

Uninstall 1


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.

Login window

  • 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


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.

Overview pane

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.

Server pane

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.


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


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

For example if you want to listen the service 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.


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 recommended that you use a self-signed certificate.

If a wildcard certificate is used, it is necessary to set the desired hostname in the "Overwrite hostname" input box, otherwise generated links will use the wildcard hostname.

Certificate pane

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

Certificate pane

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.

Certificate Wizard

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

Certificate Wizard

  1. 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".

    Certificate Wizard

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

    Certificate Wizard

  2. 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.

Certificate Wizard

  1. 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.

Certificate Wizard

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 The hostname is testserver, and the host is located within the domain

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 path where RD WebServices should save the client certificate. The certificate will be saved in .crt format.
  3. 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"

Setup Domain

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

Setup DNS and NetBIOS name

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 up password for the management user

Administrator is a built in management user that can not 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 required anymore and you can safely disable it.


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 complete.

Licenses issued by Thincast can only be used on one device at a time. You need to activate your license for it 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 reauthenticate, the simplest way is to change the key.

Custom WebApp

Thincast RD WebAccess comes with an integrated web application to allow clientless 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".
  4. Restart the service.

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

Custom WebApp

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.

Custom WebApp

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 protocl 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 filed or a tightened security is required - it might be necessary to overwrite the defaults.

Security Settings


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. Its also possible to log only errors or successful access to a resource.

Network Events logging

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 statuscode, which led to the result of the rquest.
  7. url:The request URL.

Example logfile:

time,event type,module,clientIP,username,status,url
2021-Jul-26 11:14:37,OK,http,,,200 OK,/webaccess/index.html
2021-Jul-26 11:14:38,OK,http,,,200 OK,/webaccess/webaccess.css
2021-Jul-26 11:17:38,OK,auth-basic-thrift,,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,-


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 to it. 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 you to manage access to your network resources.


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

Gateway pane

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.


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.

Home Office Users

  • Authentication Method

    First, enable "Password" for Windows Authentication. "Smart Card" authentication is currently not supported.

  • 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.

Caps Requirements

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).

CAPS Device

Server Policies

Server policies allow you 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.

Server Policies

Create a server policy:

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

A server policy is divided into 4 sections:

  • General
  • User Groups
  • Computer Groups
  • Allowed Ports

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

Server Policies


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

To specify a user-group to which you want this server policy to apply, click "Add Group".

User groups

Computer Groups

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

Computer groups

Allowed Ports

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

Allowed Ports


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 a session, right-click and choose from the context menu:

  • Disconnect this session
  • Disconnect this user


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 an unlimited number of connections; however, you may limit the maximum number of concurrent connections here.

Access log

To enable the access log, click on the checkbox and then 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".

Logon Message

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".



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.

RDP Signing

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

The installed certificate is used to sign your distributed remote desktop resources, if enabled. When signing RDP files with trusted certificates, the client verifies that important settings such as which server to connect to 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 or not to start the connection.

RDP File Signed

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

RDP Signing

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

RDP File not Signed

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".


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.

Allow list

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:


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 delivers only the specific application to the end user device. The application still "runs" on the Terminal server, but the user experience is delivered to the end user device. This allows you to deliver consistent application(s) to your devices, while allowing users to maintain the same end user experience their native device provides.

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 ("")

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

Remote connections

A remote connection is the representation of a resource, adapted to the needs of the user.

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

General settings


Select the icon to use for this resource.


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


Title of the resource is shown in all clients as the name of the resource.

Remote Desktop server

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


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.


The display setting is only available if you have selected Desktop as the connection type.

Display settings

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 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 settings

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 or not 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.

Local resoruces settings

Remote Audio

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

Remote audio settings

  • 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.


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 enable local resources. You can configure the following items:

Local devices and resources settings

  • 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.


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

Experience settings


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.


Server authentication is used to verify that the server you are connecting to is the server you intended to connect to. What you configure here is what should be done if the server authentication fails.

Security settings

  • 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 then choose whether or not to make the connection.
  • 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.


Specify the name of your Remote Desktop server. This will be displayed when you assign a resource to a specific RD Gateway 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.

Remote Desktop Servers

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 of your organization. The options are as follows:

Remote Gateway Servers


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
    • Smart card
  • 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".

Enable Add-on

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.


  • 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 were wrong or the instance is currently not available.

Add Workstation

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:

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 subscribes, the resources will automatically be added and updated in his feed.


Web Application

The other way is through a Web browser by signing in to the website that is provided by RD WebAccess.

Webapp Webapp


If you should 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.


The changelog can be found here.


Package repository key rollover

If you get an error message similar to the following, our current signing key isn't used or available on your system:

Err:1 thincast InRelease
  The following signatures couldn't be verified because the public key is not available:
   NO_PUBKEY 72B8A0EB44E76B45

Please refer to our knowledge base article to get more information why this error happens and how you can fix it.

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 maxconn 1000 weight 10 ssl check cookie srv01
  server srv02 maxconn 1000 weight 10 ssl check cookie srv02

Using TCP SSL briding 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 maxconn 1000 weight 10 ssl check check-ssl
  server srv02 maxconn 1000 weight 10 ssl check check-ssl

Using TCP briding 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 need to use the certificate from the HAProxy, otherwise mstsc will complain because the gatewayname 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 maxconn 1000 weight 10 check check-ssl
  server srv02 maxconn 1000 weight 10 check check-ssl
© 2023 by Thincast Technologies GmbH.
All rights reserved.