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).
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:
- 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
- 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:
- Establish connection: The external user connects to the RD Gateway.
- Authenticate: The RD Gateway authenticates the user and ensures permissions to access internal network resources.
- Pass traffic: After verification, the RD Gateway passes to the user to the destination host.
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.
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 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
- 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)
- 21.10 (Impish Indri)
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:
- 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.
- 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.
- Download the latest version of RD WebServices for Windows from here.
- Open the installation package.
- RD WebServices Setup will now open. Continue with "Next".
- Select the "Install" Checkbox and click on "Next".
- Read and accept the End-user License Agreement and proceed with "Next".
- Select the destination folder for RD WebServices and click on "Next".
- Click "Finish" to complete your installation.
- You have now successfully installed RD WebServices. It can be found in your start menu or under the destination folder you specified.
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:
Download the latest version of RD WebServices from here.
Open the exe with 7zip and extract the included msi installer.
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.
- 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:
127.0.1.1 rdwebservices.testing.thincast.com rdwebservices
Note: If setting the FQDN is not possible when install rdwebservices you can still replace the certificate later.
- Install required packages
apt install curl
- Add the Thincast stable repository. Note: If you want to do a pre-flight check have a look at
curl https://packages.thincast.com/deb/install.sh | sudo bash
- 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.
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.
All installed RD WebServices packages are automatically updated if you update your distribution. For example with:
apt update apt full-upgrade
- To uninstall RD WebServices, open your Settings and navigate to Apps & features. Select RD WebServices and click on "Uninstall".
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
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.
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.
- Type in the port number.
- Click on "Save" and confirm the service restart.
You can change the port of the service by changing the PORT setting the file
For example if you want to listen the service on port 8443 you would change PORT to:
After modifying the file make sure you restart the systemd service:
systemctl restart rdwebservices
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.
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.
- 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.
- Click on "Select Certificate" and navigate to the folder containing your certificate file, select it and click on "Next".
Depending on the file format of your certificate either select your private key file or enter the required password for the 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".
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.
- 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.
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.
For testing purposes you can also use the internal hostname or the IP address (NetBIOS, FQDN or IP address).
- Click "Create self-signed certificate".
- Enter the "Hostname" that the RDP client uses to connect to the RD WebServices server.
- Click "OK".
- 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
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
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:
- Click on "Download certificate".
- Select the path where RD WebServices should save the client certificate. The certificate will be saved in .crt format.
- 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:
- Open the "Domain" tab and click "Edit/Setup Domain"
- Set the NetBIOS and DNS domain name and click "OK".
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
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
Administrators. Users that are in the
Administrators group are entitled to manage RD
Users group is used for default policies and access. Newly created users are automatically added to the
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
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
To set the password for the
- In the
Userspane, go to the Users tab
- Right click on the root user and choose
- Once you have entered the same password twice, click 'OK'
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.
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.
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:
- Tick the checkbox "Custom WebApp".
- Specify where the folder is on your system (e.g. C:\temp\webapp-external).
- Click on "Save".
- Restart the service.
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.
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|
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.
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 log format
The logfile uses the comma-separated values (csv) format.
The following values are logged:
- time : The time of the event.
- event type: The event type, like 'ERROR' or 'OK'.
- module: The module which created this log entry.
- clientIP: The client IP address.
- username: The authenticated username, if available.
- status: The statuscode, which led to the result of the rquest.
- url:The request URL.
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,-
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
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 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:
- 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.
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.
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 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.
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:
- User Groups
- Computer Groups
- Allowed Ports
Once configuration for the policy is complete, click "OK" to enable the new policy.
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.
To specify a user-group to which you want this server policy to apply, click "Add Group".
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
By default, remote desktop clients connect to network resources remotely through TCP port 3389. Specify whether to use the default or a different port.
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:
- User Name
- Client IP Address
- Connected On
- 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.
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
Create a message, such as a legal notice, to display to users each time they log on to a remote computer:
- Enter log on message.
- Click "Save".
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.
- Enable system messaging.
- Enter system message.
- Specify start time / end time for this message.
- 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.
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.
To enable the distribution of signed RDP files through RD WebAccess please tick the checkbox "Sign all generated RDP Files" and click on "Save".
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.
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.
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 ("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.
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.
|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|
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.
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.
- 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)
Select if the connection bar should be displayed in the remote session when using full screen.
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.
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.
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.
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:
- Smart Cards
- 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.
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.
- 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.
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:
Specify the name of your RD Gateway server. This will be displayed when you assign a resource to a specific RD Gateway server.
- Server name
- Logon method
- Allow me to select later
- Ask for password
- Smart card
- Bypass RD Gateway server for local address
- 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.
- Thincast Workstation
- Port (Default port is 33333)
- 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.
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.
The other way is through a Web browser by signing in to the website that is provided by RD WebAccess.
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.
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:
- Apache with mod_proxy has no support, the connection will be rejected.
- HAProxy has built in-support for RD Gateway connections.
Other reverse proxies may also work, but have not been tested yet.
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 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 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 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 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