Remote Desktop Services (RDS) evolved from the old Terminal Services that were in Server 2003, and is a core technology starting in the Windows Server 2008 R2 operating system. Along with the new name have come a number of new features that expand functionality. 

To keep things simple about RDS, refer to the diagram below.

RDS has five main components:

• Remote Desktop Web Access (RDWA)
• Remote Desktop Gateway (RDG)
• Remote Desktop Session Host (RDSH)
• Remote Desktop Virtualization Host (RDVH)
• Remote Desktop Connection Broker (RDCB)

Together with additional RDS features, these core components create a framework that allows for secure anywhere access to applications, remote desktops, and even virtual desktops.

Remote Desktop Web Access

From a user’s perspective, the easiest way to access resources is through a web page. The user can reach a published URL on Internet Information Services (IIS) provided by Remote Desktop Web Access (RD Web Access) in a secure manner via Secure Sockets Layer (SSL).

This interface provides a rich web portal experience that makes published applications visible using the RemoteApp and Desktop Connection features. Normally, to reach this web portal  you simply point your browser to https://your.domain.com/rdweb. Once authenticated through domain credentials, users have links to the applications and desktops that they are authorized to access. This is all managed through an access control list (ACL), which limits what users are authorized to see and use. To protect this type of connection with MFA, refer to the documentation located here. When a user browses to the RD Web Portal, they are confronted with their typical domain credentials along with a request for their next AuthAnvil passcode. (see figure 2.)

Remote Desktop Gateway

The browser isn’t the only way that a user can connect. Using the Remote Desktop Gateway (RD Gateway) provides direct RDS connections, filtering requests based on policy decisions enforced by the Network Policy Server (NPS). Since the RD Gateway is on the edge of the network, the NPS uses two policies to control access:

• Remote Desktop Connection Authorization Policy (RD CAP) helps control who is authorized to connect through the RD Gateway server.
• Remote Desktop Resource Authorization Policy (RD RAP) helps control which resources a CAP-approved user is allowed to access through the RD Gateway server.

To connect to a RD Gateway server, all a user has to do is adjust the advanced settings in the Remote Desktop client to point to it (see Figure 3). And this can be done over SSL, which means it has a higher chance of success in limited environments in which standard Remote Desktop Protocol (RDP) or virtual private network (VPN) may not be allowed.

To protect this type of connection with MFA, you would install the Passly Windows Login Agent on the client machines. Once installed, any users connecting through Remote Desktop, will encounter a secondary prompt for their 2FA passcode to log into the server. (see Figure 4.)

Remote Desktop Session Host

Once users have connected, applications are hosted through the Remote Desktop Session Host (RD Session Host). This is the basis of how RDS works, loading applications and processing everything within the user’s session. It is even possible to load balance the architecture with multiple RD Session Host servers to address scalability. This is also known as a RDS Farm, where there are multiple servers running the RD Session Host role that serve the same purpose, so either publish the same desktop or publish the same applications and share the same initial connection.

The RD Session Host has the ability to use ACLs to manage which published applications a user is authorized to access. This capability allows you to refine least-privilege parameters to help provide secure remote access to line-of-business applications through Active Directory security groups or individual user names applied to the ACL.

Remote Desktop Virtualization Host

With Hyper-V virtualization technology in Windows Server 2008 R2 and 2012 R2, you can setup a Remote Desktop Virtualization Host (RD Virtualization Host) to serve requests from desktops running on virtual machines (VMs). When a request comes in from a RD Session Host, the RD Virtualization Host spins up a target desktop if the VM is not already running. The pairing of the RD Session Host and the RD Virtualization Host is managed by Remote Desktop Connection Broker (RD Connection Broker).

Remote Desktop Connection Broker

RD Connection Broker is the management center access to virtual machines. It provides a unified experience for setting up access to applications and virtual desktops through the Remote Desktop Connection Manager (RD Connection Manager) console.  With the RD Connection Manager console, you can define which virtual desktops are dedicated to specific users, and which are in a pool of dynamically allocated VMs. RD Connection Manager allows you to further define RD Session Host servers, terminal servers, and RD Virtualization Host servers so you can deliver a consistent URL via RD Web Access for RemoteApp and virtual desktops.

Ultimately, when a user connects to RD Web Access and clicks on an application or virtual desktop, the Remote Desktop Connection (RDC) client gets connection information streamed to it. If the user is working remotely, the client connects through the RD Gateway. If the user is on-site within the local LAN the client connects to the appropriate RD Session Host or RD Virtualization Host as determined by the RD Connection Broker. In both cases, the RD Connection Broker ensures that a client gets connected to the right resource in a secure manner.

With the use of a certificate, you can even digitally sign and provide single-sign on (SSO) so the user’s experience is streamlined while still delivering a higher level of security. If you need further identity assurance when accessing RD Web Access, you would then use a strong authentication solution such as the one outlined in the RD Web Access Area above.

Introduction to RDS Farms

There are several reasons for needing an RDS farm. One of the reasons is obvious, your organization's user base has grown to an amount that simply does not “fit” on one RD Session Host server. Even though hardware grows extremely fast especially with Server Virtualization, there is a point where it simply no longer performs to certain standards. Another big reason is High Availability. Especially if you host a complete desktop on your RD Session Host for your users, downtime means those users can no longer perform their daily tasks. Therefore, your RD Session Host servers must be Always Available, meaning running multiple servers with the RD Session Host role to serve high SLA standards related to uptime and availability.

Now that we have multiple RD Session Host servers, how does the workload get evenly spread over those servers in order to optimally use the available resources? Can it be assured that in case of a (network) failure between the client and the server, I will return to the session I left open? Yes, it can. This is where the term load balancing and an additional Windows Server role called the RD Connection Broker steps in.

Load Balancing

The main reasons for implementing load balancing are to ensure that the workload is spread evenly and optimally as possible, creating a high availability. There are a few options on how to attain load balancing (RR DNS, NLB, Hardware based or 3rd Party software) however we will focus on using the RD Connection Broker.

The RD Connection Broker, like the RD Session Host, is a server role that is included with Windows Server 2008 R2 and above. The functionality is the same as Network Load Balancer (NLB) where as new sessions are sent to the server with the least load based on the number of connections the RD Connection Broker has notion of. RD Connection Broker uses the Dedicated redirector, which is nothing more than a server running the RD Session Host role, that does not run any actual connections. IT is in fact a server that has RD Session Host in Drain mode. Users will connect to the farm by using a preconfigured RDP file and use a hostname or FQDN pointing towards the dedicated redirector. Since the RD Session Host does not allow new connections (drain mode) the RD Connection broker is contacted which performs the load balancing and determines which server has the least amount of load, and connects the user there.

The Dedicated Redirector will always be the initial server to connect to, unless the Dedicated Redirector is itself load balanced.

Securing a RDS Farm with 2FA

Whether you are working with a single RD Session Host server ,or Multiple, the easiest way to secure the connections to the clients is to protect the clients themselves.

There are pros and cons as to how the connections are made to the clients, and depending on which you choose (RD Web Access, or RD Gateway) there is going to be some configuration required at the Client.

Consult the documentation outlined within those sections to learn more.