WS2008: Terminal Services Gateway Overview

WS2008: Terminal Services Gateway Overview

  • Comments 10
  • Likes

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:

TSG Architecture

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

Share this post :
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://www.msitproblog.com/2008/02/25/the-performance-team-countdown/

  • Is it possible to change the SSL port TS Gateway uses? I would rather use port 444 instead of 443.

    Thanks.

  • I have a Windows XP Pro sp2 who had been connecting via VPN and RDC 5.1 to a remote site from inside our corporate network. The remote site has implemented a TS gateway. I upgraded the remote desktop software to v6.0. The user's profile on that machine cannot connect to the remote computer.  The error is "The computer can’t connect to the remote computer because the certificate authority that generated the Terminal Server Gateway server’s certificate is not valid." I get this error after entering the logon credentials for the remote computer and the TSGW.

    I can logon to the user's machine, browse to the RDP file in her profile and connect just fine.

    I can set the user up on another machine that has never used RDC and connect just fine.

    What file or setting could cause this behavior?

  • I have read on other forums that it is not possible to change the TCP port listener for the TS Gateway, but have not found a MS KB or tech article.  Further proof of this may be the RDC client does not seem to offer an obvious option to redirect TS gateway settings to a specific port.

    I am researching this similar question as I would like to run Exchange OLAnywhere and TS Gateway services from a single IP (yes, my lame residential internet circuit).  The only solution I have found unfortunately is to run both services on the same server (additional configurations are necessary to keep Exchange from rewriting the RPC proxy configuration).

  • Hello,

    I am evaluating W2008 Terminal Server. In my case I have stand alone TS server sitting in DMZ zone. My AD domain controller and all other resources sit inside the perimeter. All needed ports, like RDP, LDAP, DNS, Radius are open for TS Gateway machine to internal LAN.

    Now, this setup is not working for me. I have configured single policy with Central Network Policy Server pointing to my existing RADIUS server running on my AD DC server. No other policies exist on TS Gateway. When I attempt to make a remote connec tion using my domain account, I get denied access to TS. System event indicates "Uknown user or bad password". My RADIUS server works well for old VPN connections.

    My question: is it possible to use TS Gateway on stand alone machine and still be able to use AD accounts to connect?

    Thank you

  • Hi

    Could you cover off very simply the DNS / Naming / Cert requirements.

    I'm having trouble understanding what to put where.

    I have a pulblic free dynamic dns address URL and IP.

    Do I need to insert the IP from my router to the Dynamic Hoster?

    What name do I give the certificate - the name of the public URL address or the computer name?

    Could you address these.

    Thanks

    raymond.scott@live.com

  • This seems to be a common question...but can the port be changed?

    I'm running SBS 2008 and would like to publish the TS Gateway Service Server through ISA 2006 so I can use the RDP client directly instead of going through RWW (which I have problems with due to badly written biometric software for my laptop). In addition, the RDP client allows you to "connect" your local CD-ROM/HDD drive as a physically connected drive to the machine you're remoting into, for which RWW does not provide an option. However, as all SBS'ers know, port 443 is the default port for the Exchange/OWA/etc. serivces and are not (easily?) changed.

    I can imagine that this is not only a problem for SBS users (as indicated by others asking for the same thing). If you're going to allow commenting on a blog, I would hope that you would at least answer the question, especially if it pops up more than once.

    Thanks in advance for your consideration of this important administrative question.

  • While the TS Gateway does the job of securing connections between remote users and the TS Gateway, it's not clear what happens between the TS gateway and the internal  target Terminal Server.  Reason: Connections cannot be established if the Windows Firewall on the Terminal Server is activated and  "Allow only secure connections" is checked.

    Any guidance on establshing a "secure" connection between the TS Gateway to the Terminal Server so that the Windows Firewall can be configured as indicated above?

  • Bruce - The connection between the RD Gateway and the target machine is normal RDP traffic on 3389. The windows firewall shouldn't affect it's ability to encrypt the traffic. I've configured this numerous times.

  • In the current releases of TS/RD Gateway - the listening port cannot be changed.

    Unconfimed: This may change with Windows 8 though. microsoftplatform.blogspot.com/.../running-rd-gateway-on-different-port.html