Napkin Sketch of Secure Anywhere Access with RDS

Author: Dana Epp - Microsoft MVP, Enterprise and Developer Security

Recently, I had a discussion with the IT administrator of a midsize business about the value of working remotely. He was looking to migrate away from his current Terminal Services on an aged Windows Server 2003 infrastructure that supports a mobile workforce of more than 100 users. During our conversation, it was clear to me that he wasn’t fully aware of the latest advancements to Terminal Services.

Terminal Services has undergone a name change, and, as a core technology in the Windows Server 2008 R2 operating system, it’s now called Remote Desktop Services. Along with the new name have come a number of new features that expand functionality.  To clear things up about RDS, I quickly drew a simple diagram for him on the back of a napkin (see Figure 1).

Figure 1.

RDS has five main components—Remote Desktop Web Access, Remote Desktop Gateway, Remote Desktop Session Host, Remote Desktop Virtualization Host, and Remote Desktop Connection Broker (abbreviated in the napkin sketch as RDWA, RDG, RDSH, RDVH, and RDCB, respectively)—each of which provides different functionality. 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.

Let’s explore these core components, and how each one can help deliver secure anywhere access in a Windows world.

From a user’s perspective, the easiest way to access resources is through a webpage. 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.

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). Because 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 2). 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.

Figure 2.

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, and to digitally sign applications with a certificate to provide trusted delivery to users.

 A new feature in the Windows Server 2008 R2 RD Session Host is 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.

With Hyper-V virtualization technology in Windows Server 2008 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).

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 onsite 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 can use smartcards or third-party strong authentication solutions such as those provided with AuthAnvil from Scorpion Software or RSA SecurID.

Back to the napkin sketch: the IT administrator for whom I drew the architectural diagram was surprised by just how much RDS has progressed. The ability for staff to work securely and remotely while using Windows is here now. It’s built right into Windows Server 2008 R2. It is something the IT administrator is now checking out with the 120-day evaluation built in to Windows Server 2008 R2 for the RDS Licensing Server. You should check it out, too.

żródło: Napkin Sketch of Secure Anywhere Access with RDS