Terminal Services Gateway


Another new feature of Windows Server 2008 is Terminal Services Gateway (or TS Gateway), which is designed to provide authorized users with secure, encrypted access over the Internet to terminal servers on your internal corpnet. In other words, a salesperson arriving at a hotel in Hong Kong could open his Windows Vista laptop to bring it out of sleep mode, connect to the Internet using a hot spot in the lobby, and launch a RemoteApp program on his machine that actually runs far away on a Terminal Server hidden behind your company’s perimeter firewall at headquarters in New York. Or, depending on how your administrator has defined its resource authorization policies, the user might be able to access the remote desktop of his own desktop computer in New York, provided Remote Desktop has been enabled on it. And if the remote user is an administrator, he could access the remote desktop of any servers within his internal corpnet (provided Remote Desktop is enabled on them) and securely manage those servers and do whatever tasks he needs to perform on them. All I can say concerning this TS Gateway feature is what Edward Norton said in one of my favorite movies, Rounders: “Wow. Wow. A lot of action. A lot of action.”

And you can do all this without having to use a virtual private network (VPN) connection. Plus this will work regardless of the type of perimeter firewall your company has set up, or even if your business is using Network Address Translation (NAT). As Figure 8-4 illustrates, all it takes to make all this work is that your perimeter firewall has to allow TCP port 443 so that HTTP SSL traffic can pass through from the outside.

image from book
Figure 8-4: How TS Gateway works

As this figure illustrates, TS Gateway works by enabling tunneling of RDP traffic over HTTPS (HTTP with SSL encryption). The client computer at the left is attempting to connect to the terminal servers at the right that are hidden behind a pair of firewalls with a perimeter network subnet in between them. The TS Gateway is sitting between the firewalls on the screened subnet, and when the incoming RDP over HTTP traffic reaches the external firewall, the firewall strips off the HTTP part and passes the RDP packets to the TS Gateway. The TS Gateway can then use the Network Policy Server to verify whether the user is allowed to connect to the terminal server, and will use Active Directory to authenticate the remote user. Once the user is authenticated, she can access the internal terminal servers and run RemoteApp programs on them as described previously in this chapter.

TS Gateway will support NAP so that when a remote client computer tries to connect to a terminal server on your internal corpnet, the remote client first has to undergo the required health check to make sure it has the latest security updates installed, has an up-to-date antivirus signature, has its host firewall enabled, and so on. After all, you don’t want unhealthy (read: infected with worms and other malware) remote computers to be able to connect to your internal terminal servers and infect your whole network! One thing to note, however, is that NAP will not be able to perform remediation for unhealthy clients connecting through TS Gateway-it simply blocks them from accessing your internal terminal servers. In addition, device redirection is blocked for remote clients connecting via TS Gateway (though best practice is actually to block such redirection on your terminal servers and not on your TS Gateway).

An alternative to placing your TS Gateway on the perimeter network is to put it on your corpnet-that is, behind your internal firewall. Then place an SSL terminator in your perimeter network to forward incoming RDP traffic securely to your TS Gateway. Either way you implement this, however, one advantage of this new feature is that you don’t need to worry about using an SSL VPN any longer and all the headaches associated with getting this working properly.

This integration with Network Access Protection (NAP) is an important aspect of TS Gateway because many mid- and large-sized organizations that will deploy Windows Server 2008 will probably do so because of NAP (and also, of course, because of the many enhancements in Terminal Services on the new platform). (We’ll be covering NAP in Chapter 10, “Implementing Network Access Protection.”)

Before we go any further, let’s hear from one more of our experts:

image from book
From the Experts: Better Together: TS Gateway, ISA Server, and NAP

Terminal Services–based remote access has long been used as a simpler, lower-risk alternative to classical layer 2 VPN technologies. Whereas the layer 2 VPN has often provided “all ports, all protocols” access to an organization’s internal network, the Terminal Services approach restricts connectivity to a single well-defined port and protocol. However, as more and more capability has ascended the stack into RDP (such as copy/paste and drive redirection), the potential attack vectors have risen as well. For example, a remote drive made available over RDP can present the same kinds of security risks as one mapped over native CIFS/SMB transports.

With the advent of TS Gateway, allowing workers to be productive from anywhere has never been easier. TS Gateway also includes several powerful security capabilities to make this access secure. In addition to its default encryption and authentication capabilities, TS Gateway can be combined with ISA Server and Network Access Protection to provide a secure, manageable access method all the way from the client, through the perimeter network, to the endpoint terminal server. Combining these technologies allows an organization to reap the benefits of rich RDP-based remote access, while mitigating the potential exposure this access can bring.

ISA Server adds two primary security capabilities to the TS Gateway solution. First, because it can act as an SSL terminator, it allows for more secure placement of TS Gateway servers. Because ISA can be the Internet-facing endpoint for SSL traffic, the TS Gateway itself does not need to be placed within the perimeter network. Instead, the TS Gateway can be kept on the internal network and the ISA Server can forward traffic to it. However, if ISA were simply performing traffic forwarding, it would be of little real security benefit. Thus, the second main security value ISA brings to the solution is pre-authentication capabilities. Rather than simply terminating SSL traffic and forwarding frames on to the TS Gateway, ISA authenticates users before they ever contact the TS Gateway, ensuring that only valid users are able to communicate with it. Using ISA as the SSL endpoint and traffic inspection device allows for better placement of TS Gateway resources and ensures that they receive only inspected, clean traffic from the Internet.

Although ISA Server provides important network protection abilities to a TS Gateway solution, it does not address client-side threats. For example, users connecting to a TS Gateway session might have malicious software running on their machines or be non-compliant with the organization’s security policy. To mitigate against these threats, TS Gateway can be integrated with Network Access Protection to provide enforcement of security and healthy policies on these remote machines.

NAP is included in Windows Server 2008 and can be run on the same machine as TS Gateway, or TS Gateway can be configured to use an existing NAP infrastructure running elsewhere. When combined with TS Gateway, NAP provides the same policy-based approach to client health and enforcement as it does on normal (not RDP-based) network connections. Specifically, NAP can control access to a TS Gateway based on a client’s security update, antivirus, and firewall status. For example, if you choose to enable redirected drives on your terminal servers, you might require that clients have antivirus software running and up to date. NAP allows organizations to ensure that computers connecting to a TS Gateway are healthy and compliant with its security policies.

–John Morello

Senior Program Manager, Windows Server Division

image from book

One other thing about ISA is that it does inspect the underlying HTTP stream when being accessed over port 80, and although this is not RDP/HTTP inspection, it does afford additional protection from anything that might try to piggyback on the HTTP connection itself.

Implementing TS Gateway

Implementing TS Gateway on a server running Windows Server 2008 requires that you add the TS Gateway role service for the Terminal Services role. When you do this using Server Manager, you are prompted to add the following roles and features as well (if they are not already installed):

  • Network Policy and Access Server role (specifically, the Network Policy Server role services)

  • Web Server (IIS) role (plus various role services and components)

  • RPC Over HTTP Proxy feature

Note that for smaller environments, it’s all right to install TS Gateway and the Network Policy Server (NPS) on the same Windows Server 2008 machine. Larger enterprises, however, will probably want to separate these two different role services for greater isolation and manageability.

Adding the TS Gateway role service also requires that you specify a server certificate for your server so that it can use SSL to encrypt network traffic with Terminal Services clients. A valid digital certificate is required for TS Gateway to work, and you have the choice during installation of this role to import a certificate (for example, a certificate from VeriSign if you want clients to be able to access terminal servers running on your corpnet from anywhere in the world via the Internet), create a self-signed certificate (good for testing purposes), or delay installing a certificate until later:

image from book

After importing a certificate for your server, you’re given the option of creating authorization policies now or doing so later using the TS Gateway Management console. There are two kinds of authorization policies you need to create:

  • Connection authorization policies These are policies that enable remote users to access your network based on conditions you have specified.

  • Resource authorization policies These are policies that grant access to your terminal servers only to users whom you have specified.

Finally, the Add Role Services Wizard indicates which additional roles and role services will be installed for the Network Policy and Access Server and Web Server (IIS) roles (if these roles and role services are not installed already). And finally you’re done.

Once your TS Gateway is set up, you can configure it by creating additional connections and resource authorization policies. For example, you could create a resource authorization policy (RAP) to specify a group of terminal servers on your internal corpnet that you want the TS Gateway to allow access to by authorized remote clients:

image from book

When you create and configure connection authorization policies, you specify which security groups of users they apply to and, optionally, which groups of computers as well. You also specify whether authorization will use smart cards, passwords, or both. When you create and configure resource groups, you define a collection of resources (for example, terminal servers) that remote users will be allowed to access. You can specify these resources either by selecting a security group that contains the computer accounts of these computers, by specifying individual computers using their names (hostname or FQDN) or IP addresses, or by allowing remote users to access any computer (client or server) on your internal network that has Remote Desktop enabled on it. You need to create both connection and resource authorization policies for TS Gateway to do its job.

Finally, the Monitoring node in the TS Gateway Management console lets you monitor connections happening through your TS Gateway and disconnect them if needed.

Benefits of TS Gateway

Why is TS Gateway a great feature? It gives your users remote access to fully firewalled terminal servers on your corpnet, and it does so without any of the headache of having to configure a VPN connection to those servers. That’s not to say that VPNs aren’t still useful, but if users don’t need a local copy of data, network bandwidth is limited, or the amount of application data that needs to be transferred is large, you’ll likely get better performance out of using TS Gateway than trying to let your users VPN into your corpnet to access your terminal servers.

Best practices for deploying this feature? Use a dedicated TS Gateway (it can coexist with Outlook RPC/HTTP), and consider placing it behind Microsoft Internet and Acceleration Server (ISA) rather than using a simple port-based firewall.




Microsoft Windows Server Team - Introducing Windows Server 2008
Introducing Windows Server 2008
ISBN: 0735624216
EAN: 2147483647
Year: 2007
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net