Windows Server 2008 R2 Unleashed (181 page)

In contrast, the goal with a virtual desktop pool is to have the same user experience across

all virtual desktops regardless of the virtual desktop that a user is connected to. To achieve

this type of experience, all virtual machines in a virtual desktop pool must be configured

identically (in addition to not already being assigned as a personal virtual desktop).

Additionally, virtual desktop pools can be configured to roll back changes to a previous

state when a user logs off of the virtual machine.

To redirect users to the correct virtual machine, the RD Virtualization Host uses the

Remote Desktop Connection Broker (RD Connection Broker). When a user is assigned to a

personal virtual desktop, the RD Connection Broker redirects a user’s session request to the

appropriate virtual machine. For cases when the virtual machine is not powered on, the

RD Virtualization Host will power on the virtual machine before completing the session

request. When a user attempts to open up a connection to a shared virtual desktop pool,

the RD Connection Broker does either of the following:

1. If the user already has a disconnected session to a virtual machine, the RD

25

Connection Broker simply redirects the connection request to that virtual desktop.

2. If the user doesn’t already have a disconnected session, the RD Connection Broker

ptg

dynamically assigns a virtual machine from the pool.

NOTE

Using the RD Virtualization Host role service requires that Hyper-V also be installed.

RD Gateway

The Remote Desktop Gateway (RD Gateway) role service allows users to access network

resources (like RD Session Host servers, RD Session Host servers running RemoteApp

programs, RD Virtualization Host–based virtual machines, or computers with Remote

Desktop enabled) that are located behind firewalls in a private network from any Internet-

based client (or internally based clients if TCP 3389 is an internally restricted port). To do

this, the RD Gateway employs something that is called an SSL relay (also known as an SSL

VPN). In short, an SSL relay allows clients to connect to internal resources over a secure,

encrypted HTTPS connection. In this case, the traffic that is being passed through the SSL

relay is just RDP (TCP 3389).

NOTE

RD Gateway must be installed on Windows Server 2008 R2 servers, but it can perform

SSL relay for both Windows Server 2008 R2 RD Session Host servers and Windows

Server 2008/2003 Terminal Servers.

RD Gateway was first introduced in Windows Server 2008 as the TS Gateway. The reason

Microsoft has included this feature in Windows Server 2008 was because security measures

932

CHAPTER 25

Remote Desktop Services

were typically put into place to block traffic such as RDP (TCP 3389). In other words, IT

security departments typically blocked RDP or were reluctant to open ports on their fire-

walls for it. Microsoft took a card from networking companies and built an SSL VPN solu-

tion into their Remote Desktop Services offerings. The result of this effort is the RD

Gateway, which allows users to gain access to the services that are provided by Remote

Desktop Services, regardless of their location.

As hinted previously, the RD Gateway uses an HTTP Secure Sockets Layer/Transport Layer

Security (SSL/TLS) tunnel to transmit RDP traffic. Because the RD Gateway server is using

HTTPS, a server authentication certificate needs to be installed. Furthermore, the certifi-

cate that is installed needs to be issued by a certificate authority (CA) that is trusted on

clients accessing the RD Gateway. In other words, the certificate of the CA that signed the

RD Gateway server certificate must be located in the client’s Trusted Root Certification

Authority store. A trusted certificate can either be obtained from a publicly trusted CA or

an internal CA to your organization that is already trusted by clients.

The following are some additional requirements that should be taken into account when

using the RD Gateway:

. The Remote Procedure Call (RPC) over HTTP Proxy service must be installed (this is

installed when you install the RD Gateway role service).

ptg

. Internet Information Services 7.5 must be installed and running for the RPC over

HTTP Proxy service to function.

. The Network Policy Server (NPS) service must be installed or an existing NPS server

must be present that can be used by the RD Gateway.

. RD Gateway servers and Remote Desktop Services clients can be configured to use

Network Access Protection (NAP).

. Active Directory Domain Services is required if the RD Gateway authorization policy

is defined such that clients must be a member of a domain-based group.

NOTE

The RD Gateway feature is only supported on clients running Windows Server 2008

(R2), Windows 7, Windows Vista, Windows XP with Service Pack 2 or higher, or

Windows Server 2003 with Service Pack 1 or higher that have the Remote Desktop

Connection (RDC) client installed.

The new features that have been introduced in Windows Server 2008 R2 for the RD

Gateway role service are discussed in the following sections.

Configurable Idle and Session Timeouts

In Windows Server 2008 R2, an administrator can now configure idle and session timeouts

for an RD Gateway server. An idle timeout is used to reclaim unused resources. If a user’s

session is idle longer than the specified time, that user’s RD Gateway session is discon-

Understanding Remote Desktop Services

933

nected. When this occurs, a user will still be able to reestablish the session, if they choose

to. A session timeout allows for the ability to periodically enforce new policies on active

user connections. Policy refreshes mean that Remote Desktop connection authorization

policy (RD CAP) changes or Remote Desktop resource authorization policy (RD RAP)

changes can be enforced on existing sessions.

Background Session Authentication and Authorization

If a timeout is reached, a session can either be disconnected or silently reauthenticated

and reauthorized. When enabled for background authentication and authorization, the

authentication and authorization requests for the session are automatically done in the

background with no interaction.

System and Logon Messages

Now when a user starts a new RD Gateway session, an administrator can define system

and logon messages. System messages can be used to inform users about system status

changes, upcoming server maintenance, and so on, whereas a logon message can be used

to display a legal-logon notice to users before they gain access to any protected resources.

25

Device Redirection Enforcement

RD Gateway now has the option to only allow Remote Desktop clients to connect to RD

ptg

Session Host and RD Virtualization Host servers that enforce secure device redirection.

This change was put in place to prevent non-Microsoft Remote Desktop clients from over-

riding the gateway device redirection controls. However, this new feature is only

supported on RDC 7.0 or later clients.

Network Access Protection (NAP) Remediation

When using a Windows Server 2008 R2 RD Gateway server, clients that are found out-of-

compliance with a health policy can now be brought into compliance via software

updates. By using this feature, an administrator can use a CAP policy to ensure that

remote clients that connect to internal resources through an RD Gateway are always kept

current with the latest software updates.

Pluggable Authentication and Authorization

The pluggable authentication and authorization feature exposes a set of APIs that allow

organizations custom or third-party authentication and authorization plug-ins that inte-

grate with RD Gateway. By using this feature, RD Gateway authentication and authoriza-

tion can be tailored to fit a wide range of security requirements.

Windows Server 2008 R2 Feature Requirements

For an administrator to utilize the new RD Gateway features introduced in Windows

Server 2008 R2, the following requirements must be met:

. RD Session Host servers must be Windows Server 2008 R2.

. RD Gateway servers must be Windows Server 2008 R2.

. Users must use the Remote Desktop Connection (RDC) 7.0.

934

CHAPTER 25

Remote Desktop Services

RD Web Access

The Remote Desktop Web Access role service is designed to allow users (internally and

remotely) to access RemoteApp programs, session-based remote desktops, or virtual desk-

tops from within a website. Using RD Web Access, a user accessing a website (hosting the

RD Web Access web part) would be presented with a single consolidated list of published

RemoteApps. This list consists of the application icons for each RemoteApp that has been

published either from a single RD Session Host server or RD Session Host server farms. By

clicking on one of these icons, a session would then be launched on the remote RD

Session Host or RD Virtualization Host that is hosting the published resource. RD Web

Access is especially useful to administrators who want to deploy Remote Desktop

Services–based programs from a central location, from a customized web page, or from a

Windows SharePoint Services site.

To use RD Web Access, clients must meet the following requirements:

. Internet Explorer 6.0

. Remote Desktop Connection (RDC) that supports at least Remote Desktop Protocol

(RDP) 6.1

The version of the RDC client on Windows 7 and Windows Server 2008 R2 supports RDP

ptg

7.0. The RDC client that is being used determines which RD Web Access features will be

available to users. Additionally, the Remote Desktop Services ActiveX Client control must

be enabled.

The new features that have been introduced in Windows Server 2008 R2 for the RD

Session Host role service are discussed in the following sections.

Forms-Based Authentication

Forms-based authentication (FBA) is an ASP.NET authentication service that enables appli-

cations to provide their own logon page and do their own credential verification.

Additionally, this service authenticates users, redirects unauthenticated users to the logon

page, and performs all the necessary cookie management. Like Outlook Web Access

(OWA), by supporting FBA, RD Web Access users will now have an improved logon experi-

ence. For example, administrators can customize the RD Web Access logon page to include

such things as branding stylization and other important look-and-feel items.

Single Sign-On Between RD Session Host and RD Web Access

An important feature that was missing from the Windows Server 2008 Terminal Services

version of Web Access was support for Single Sign-On. In that version, when a user

connected to a RemoteApp program using Web Access, they were prompted for their

credentials twice. Needless to say, the double credential prompting led to a poor user expe-

rience. However, with the Windows Server 2008 R2 version of Web Access (RD Web

Access), support for Single Sign-On has been added. When used correctly, users will only

have to provide their credential information once when connecting to a RemoteApp

program using RD Web Access.

Understanding Remote Desktop Services

935

NOTE

To use RD Web Access Single Sign-On, several dependencies must be met. First, the

certificate used to sign the RemoteApp programs must be trusted. Second, Single Sign-

On is only supported from clients running Remote Desktop Connection (RDC) 7.0.

Public and Private Computer Option

Like OWA, the RD Web Access Web page can now be accessed via either a public or private

mode. If the public computer option is used, cookies storing the username are available

for about 20 minutes. If the cookie is left to expire, the user’s information is technically

purged from the system being used. When the private computer option is used, cookies

storing the username are available for about 4 hours.

NOTE

A user’s password is never cached on a system when either the public or private RD

Web Access options are used.

25

ptg

RD Connection Broker

In Windows Server 2003, the feature named Session Directory was introduced to maintain

user connection states across load-balanced Terminal Servers. This feature kept a list of

sessions indexed by username. Then, when a user became disconnected from that session

and attempted to reconnect, the Session Directory redirected the user back to the same

Terminal Server that held their disconnected session.

In Windows Server 2008, the Session Directory was renamed to the Terminal Services

Session Broker (TS Session Broker). The renamed TS Session Broker also contains a new

feature called TS Session Broker load balancing. Microsoft introduced the load-balancing

feature to allow administrators to distribute session loads between Terminal Servers

without having to use Windows Network Load Balancing (NLB). A typical deployment for

the TS Session Broker load-balancing feature is for Terminal Server farms that consist of 2

to 10 servers.

For Windows Server 2008 R2, TS Session Broker was again renamed, this time to RD

Connection Broker. Like before, the RD Connection Broker role service still performs load