¶ Overview
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:
- RDSH server
- RD Gateway
- RD Web Portal server
- RD Session Broker
- AD FS server
- Web Application Proxy (WAP)
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.
¶ RDSH server
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.
¶ RD Gateway and RD Web
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 -enable or -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.
¶ How WAP routes the requests
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:
- The user requests the RD Web Portal, for example https://contoso.com/RdWeb
- WAP understands that the user is yet unauthenticated and redirects them to the configured AD FS portal
- On the AD FS portal, the user enters their SystoLOCK credentials and is then redirected back to WAP.
- Having received that redirection, WAP, now in possession of enough authentication data, requests a Kerberos ticket from a domain controller on behalf of the authenticating user.
- Having received the ticket, WAP now proxies all user requests to the RD Web portal, attaching the Kerberos ticket obtained in the previous step.
For this scenario to work, the following configuration steps are needed:
- Creating a claim-unaware trust in AD FS as described in Create a Non-Claims-Aware Relying Party Trust. The relaying party is your RD Web Portal.
- Configuring constrained delegation to allow WAP to request tickets on behalf of the user.
- Configuring WAP to process the requests.
¶ Configuring WAP
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.