WS2008: Terminal Services Gateway Overview

First published on TECHNET on Feb 26, 2008

Welcome to Day Number Twenty-Six.  Tomorrow is Launch Day!  Over the last twenty-five days we've gone over several different aspects of Windows Server 2008.  Just because today is the last day in our Launch Series doesn't mean that we're going to ignore Windows Server 2008 for a while.  Count on seeing more Windows Server 2008 posts in the future - just perhaps not quite so many in such a short space of time!  Anyway, getting on with the business of the day, we're wrapping up our Launch Series with an Overview of Terminal Services Gateway (TS Gateway or TSG).  So without further ado ...

First, what exactly is TS Gateway?  It is a role service that enables authorized remote users to connect to resources on an internal corporate or private network from Internet-connected devices.  The network resources can be either Terminal Servers running RemoteApp programs or systems with Remote Desktop enabled.  If you think about Terminal Services Gateway as Terminal Services Proxy (which was the original name for this feature) or a VPN for Terminal Services, it may help with understanding exactly what it does.  TS Gateway uses RDP over HTTPS to help form a secure, encrypted connection between remote users on the Internet and the internal network resources to which they need to connect.  Sounds like a VPN without the actual VPN doesn't it?

So what benefits are there in running TS Gateway?  Since the TS Gateway connection is encrypted, you do not have to configure a VPN connection.  TS Gateway also provides a comprehensive security model that enables the administrator to control access to specific internal network resources.  TS Gateway provides a point-to-point RDP connection rather than blanket access to the internal network.  Using TS Gateway you can connect to internal resources that are hosted behind firewalls on private networks and across Network Address Translators (NATs).  Prior to Windows Server 2008, remote users were often prevented from connecting to internal network resources across firewalls and NAT's because port 3389 was typically blocked on the firewalls.  Since TS Gateway uses port 443 for an HTTP SSL / TLS tunnel (which most organizations have open for Internet connectivity), remote access connectivity across multiple firewalls is possible.

Within TS Gateway you can also define and configure Connection Authorization Policies that define conditions that must be met for a remote user to connect to an internal resource.  We'll go Connection Authorization Policies in a bit more detail later on in this post.  TS Gateway servers and Terminal Services clients can be configured to use Network Access Protection (NAP).  NAP is a health policy creation, enforcement, and remediation technology.  Using NAP, administrators can enforce system health requirements such as software requirements (for example the client must have an approved and updated Anti-Virus program running), as well as security update requirements, required computer configurations and other settings.  Using TS Gateway in conjunction with Microsoft ISA Server, a TS Gateway server could be hosted in a DMZ network with the ISA server sitting in the perimeter network.

So as you can see, TS Gateway provides several benefits.  Now let's take a look at the architecture of TS Gateway.  The diagram below shows a high level view of the architecture and connection processes:

Let's go over this connection sequence in a bit more detail:

1. The user at home initiates the connection to their network by using a .RDP file or a Remote Programs icon.
2. An SSL tunnel is established between the client and the server using the TS Gateway server SSL certificate.  Before a connection is established however, the server must authenticate and authorize the user according to any Connection Authorization Policies (CAPs) that have been configured
3. If the authentication and authorization succeed, the server signals the client to continue with the connection sequence
4. The client requests a connection from the server to an internal resource - whether that is a RemoteApp program, an RDP connection to their workstation in the office or to a Terminal Server session.  The server verifies the name of that resource against the names of resources included in the Resource Authorization Policies (RAPs) that have been configured
5. If the name of the resource exists in at least one RAP and the name of the user requesting the connection also exists in at least one RAP then the TS Gateway server authorizes the request and establishes the connection to the resource
6. The client and the resource establish a secure tunnel through the TS Gateway server over HTTPS (port 443)
7. From this point, any packets that the client sends to the TS Gateway server are forwarded to the resource, and vice-versa (this is why thinking of TS Gateway as TS Proxy may help with understanding the process)
8. The client will attempt to create a user session on the resource.  The resource performs Windows Authentication to validate the identity of the user requesting the connection as well as the privileges that the user has on the resource.  These are the same steps that would be followed if the client requested a remote connection to the server without the TS Gateway - in other words, a fairly standard logon process
9. The client sends the encrypted RDP packets to the TS Gateway server over port 443.  The server forwards the encrypted RDP packets to the resource over port 3389

Now that we've discussed the basic connection process, let's talk about the Authorization Policies mentioned above - the Connection Authorization Policies (CAPs) and the Resource Authorization Policies (RAPs).  A TS CAP allows administrators to specify connection criteria that must be met in order to connect to a Terminal Services Gateway server.  A very simple TS CAP might require that the user be a member of a specific security group - either domain based, or local to the TS Gateway server.  The following criteria may be defined in a CAP:

• Is the user a member of a specific security group?
• Is the client machine a member of a specific security group?
• Whether a client needs to use smart card authentication or password authentication - or perhaps they could use either method
• What devices are redirected

A Network Policy Server (NPS) can be configured to store, centralize, manage and validate TS Gateway CAPs.  NPS was formerly known as a Remote Authentication Dial-In User Service (RADIUS) server.  If there is already a Network Policy Server deployed for remote access scenarios such as VPN, you can use this server for TS Gateway scenarios also.  If more than one TS CAP is configured, the following policy lookup behavior is used.  Policies are applied in the numerical order shown in the TS Gateway Manager pane and access is granted by the first matching policy.  In other words, if a client does not meet the requirements of the first TS CAP in the list, the TS Gateway will evaluate the second policy and so on, until it locates a TS CAP whose requirements are met.  If a client does not meet the requirements of any of the TS CAPs then TS Gateway denies the access request.

TS Resource Authorization Policies (RAPs) allow administrators to specify the internal network resources that remote users can access through a TS Gateway server.  When a TS RAP is created, the administrator can create a computer group and associate it with the TS RAP.  For example, a TS RAP might specify that members of the "HR Users" group can only connect to computers that are members of the "HR Computers" computer group.  Remote users connecting to an internal network through TS Gateway are granted access if they meet the conditions for at least one TS CAP and one TS RAP.  An important note here - since client users may specify a NetBIOS name or a fully qualified domain name (FQDN) for the internal computer that they are trying to access, you should create a TS RAP for each possible name.

And with that, Day Twenty-Six - the final day of our Launch Series comes to an end.  Tomorrow ... LAUNCH DAY!  We'll have a special Launch Day post for you.  Until next time ...

- CC Hameed