Installing SystoLOCK on an RDS farm is not a straightforward task and requires preparation and planning. SystoLOCK relies on AD FS services to authenticate users, so be sure to make AD FS installation available for this installation type.
RDS farm typically consists of the following components:
Some of these servers/roles can be clustered so the procedures below should typically be repeated on every member of the cluster. Further, some roles can be combined within one server instance, hence some SystoLOCK components might also need to be installed on these servers together. AD FS and WAP cannot be combined with other roles.
You would need to install SystoLOCK components on RDSH servers, RD Web Access server and RD Gateway server.
Although Microsoft describes how to publish RD Gateway through WAP, the resulting setup does not work, because Microsoft depricated WAP to be used with RDS Gateway. Therefore, the working concept is to connect to the gateway directly as shown below. While this has a general security implication, from SystoLOCK's point of view, there is no difference, whether RD Gateway is published via a proxy or directly.
The following diagram illustrates the connections between different participants of the farm environment:
While installing, the authentication scheme on RD Web Portal will be changed from Forms to integrated Windows authentication. Check prior to installing if this is an undesirable effect.
An installation on the terminal server itself does not differ from a client installation, so follow the instructions on Windows Client Installation for that role.
SystoLOCK provides a plug-ins for both RD Gateway (that leverages token-based authentication on the Gateway) and RD Web portal in one package
Systola.SystoLock.Rds.Web. Select appropriate components from the list and click install. Select both if RD Gateway and RD Web Portal are installed or are going to be installed on the same server.
After the installation completes, you will be asked to continue configuring the installed services in PowerShell:
In the PowerShell windows that opens after you click "Finish", you will see 3 scripts that are used to configure the services:
Configure-RDWA.ps1: configures RD Web Access Portal by changing authentication type to Windows integrated and adding additional handlers, automatically installs RD Gateway role if not missing.
Configure-RDGateway.ps1: configures RD Gateway by installing an authentication plug-in and automatically installs RD Web Access role if missing.
Configure-RDGAuth.ps1: configures RD session broker by altering the authentication parameters in the generated RDP files. You only need to run this script once per RDS installation - the script will find all available brokers within current environment.
All three scripts accept either
-disable parameters that perform respective actions. The last script also accepts an optional string parameter
-ConnectionBroker, but if missing will try to detect the brokers via known API calls.
Make sure you possess administrative privileges on all computers hosting these roles - RD Web, RD Gateway and RD Session broker - before you run the scripts.
Web Application Proxy serves as a switch and an impersonator for users accessing RD Web Portal. The following happens when an unauthenticated user tries to access RD Web via WAP:
For this scenario to work, the following configuration steps are needed:
Once all prerequisites are met, configure WAP by publishing the endpoints in question via GIU or PowerShell. For the sake of clarity, let's assume that the web portal is hosted on a computer with name
web.contoso.com (with an SPN
HTTP/web.contoso.com), AD FS Server is running on
adfs.contoso.com, the relaying party trust is called
Contoso RDWeb and WAP is accessible from the internet under the name
rds.contoso.com. Needless to say, you'd need to configure an SSL certificate on WAP. Following PoweShell commands will publish the 3 endpoints in question:
# Get the thumbprint of the SSL certificate $Thumb = ls Cert:\LocalMachine\my\ | ` ? subject -eq 'CN=rds.contoso.com' | ` select -expandproperty thumbprint # Configure RDWeb Add-WebApplicationProxyApplication ` -Name 'RdWeb' ` -ExternalPreAuthentication ADFS ` -ADFSRelyingPartyName 'Contoso RDWeb' ` -BackendServerUrl 'https://web.contoso.com/rdweb/' ` -BackendServerAuthenticationSpn 'HTTP/web.contoso.com' ` -ExternalUrl 'https://rds.contoso.com/rdweb/' ` -InactiveTransactionsTimeoutSec 300 ` -ExternalCertificateThumbprint $Thumb ` # Configure SystoLOCK sessions Add-WebApplicationProxyApplication ` -Name 'SystoLOCK Sessions' ` -ExternalPreAuthentication PassThrough ` -BackendServerUrl 'https://web.contoso.com/rdweb/Pages/SystoLock/Session/' ` -ExternalUrl 'https://rds.contoso.com/rdweb/Pages/SystoLock/Session/' ` -ExternalCertificateThumbprint $Thumb ` -InactiveTransactionsTimeoutSec 300 ` # Configure AD FS Add-WebApplicationProxyApplication ` -Name 'AD FS' ` -ExternalPreAuthentication PassThrough ` -BackendServerUrl 'https://adfs.contoso.com/' ` -ExternalUrl 'https://rds.contoso.com/' ` -ExternalCertificateThumbprint $Thumb ` -InactiveTransactionsTimeoutSec 300 `
You can adjust
-InactiveTransactionsTimeoutSec to your need.