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 users 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 isnt 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 AuthAnvil Windows Credential Provider 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 users 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 users 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.