Compartilhar via

  • Artigo

ISA Server

Enhance TS Gateway Security with ISA Server 2006

Dr. Thomas W. Shinder and Yuri Diogenes

 

At a Glance:

  • Two scenarios that use TS Gateway with ISA Server
  • ISA Server 2006 configuration
  • Testing and monitoring

Contents

Beyond the Perimeter
The First Scenario
Configuring ISA Server 2006
Testing and Monitoring Client Access
Monitoring from ISA Server
The Second Scenario
What about the Client?
Conclusion

Following on the success of Outlook Anywhere in Exchange Server 2007, Windows Server 2008 in turn delivers the capability to access your desktop from anywhere in a secure and controlled manner.

The new Terminal Server Gateway service (TS Gateway) in Windows Server® 2008 offers the flexibility of Windows® Terminal Server Services plus the ability to connect to a Terminal Server from anywhere over an HTTP connection. This service uses Remote Desktop Protocol (RDP) over HTTPS (SSL) to increase security while providing a single client interface for accessing Terminal Services resources.

This new TS Gateway service offers significant benefits to those who need to access their computers remotely:

  • No need to establish a Virtual Private Network (VPN) session prior to connecting to internal resources using RDP.
  • Enhanced security using Network Access Protection (NAP) and Windows Security Health Checks to control RDP connections.
  • No need to open TCP port 3389 inbound to enable more secure Web publishing through firewalls.

You can use Microsoft® Internet Security and Acceleration (ISA) Server 2006 to enhance the security of TS Gateway service while allowing external access to internal resources. You can set up an SSL-to-SSL bridging scenario in which ISA Server 2006 receives requests and passes them to the internal TS Gateway service, also using HTTPS. While bridging the request, the ISA firewall decrypts the SSL communications and performs application-layer inspection.

If the HTTP protocol stream passes inspection, then the communication is re-encrypted and forwarded to the Terminal Services proxy. If the protocol stream fails inspection, the connection is dropped.

Beyond the Perimeter

Microsoft has invested quite a bit of effort in security, and Windows Server 2008 is the most secure and robust version of Windows yet. But the company is also concerned with how users will implement its products and that users follow best practices to keep their environments secure. Best practices require a defense-in-depth approach that provides protection at multiple points of access, or layers. The layers relevant to our discussion here are Policies, Procedures and Awareness; Perimeter; Internal Network; and Host.

When you allow external users access to an internal resource through ISA Server, you need to understand the boundaries of each product involved. ISA Server 2006 and TS Gateway will provide security at the Perimeter layer, but for internal resources, you need to have policies in place that allow or deny access as necessary. Network Policy and Access Services (NPAS) lets you accomplish this, working at the Policies, Procedures and Awareness layer. Access to internal resources (drive, clipboard, printers, and so forth) is defined by Terminal Service Resource Authorization Policies, addressing the internal network layer.

In this article we will first examine how to publish the Terminal Services Gateway through ISA Server 2006. Then we'll extend our ISA Server 2006 publishing scenario to include client health enforcement using NAP. By using NAP, we can create client health policies that help us control access at the Host Layer.

The First Scenario

Our goal is to show how to publish the TS Gateway through ISA Server 2006. Figure 1 summarizes the computers and data flow during the connection. In this scenario we are implementing the Network Policy Server (NPS) Role on the TS Gateway itself; however, we will change this in the second scenario, where we will use a central NPS server. Follow the sequence below to understand how the communications work among the components of the TS Gateway publishing solution:

fig01.gif

Figure 1 Publishing TS Gateway through ISA Server 2006 (Click the image for a larger view)

  1. The external RDP user initiates the connection. The first thing the client must do is resolve the external name of the TS Gateway (in this case, tsg.contoso.com). The external DNS resolves this name, which points to the external IP address of the ISA Server.
  2. An SSL tunnel is established between the RDP client and the external interface of the ISA Server. The ISA Server has a Web publishing rule on port TCP 443 that uses a certificate issued to tsg.contoso.com.
  3. After evaluating the rule and checking that the traffic is allowed, ISA Server will send a DNS query to the internal DNS server (located on the domain controller) to resolve the name of the server specified on the Web publishing rule.
  4. ISA Server then opens an SSL tunnel to the TS Gateway and passes the authentication request to it.
  5. The TS Gateway server validates the user's credentials and verifies that the user is authorized to establish the connection.
  6. After establishing that the user is authorized to establish the connection, the TS Gateway service receives the requests on TCP port 443 and forwards the RDP packets via TCP port 3389 (by default) to the internal Terminal Server where the application (such as a CRM application) resides.

From this point, any packets the RDP client sends to TS Gateway service through ISA Server are forwarded to the internal Terminal Server, and vice versa.

It is important to mention that the RDP over HTTPS behind the scenes is nothing more than a RDP/RPC/HTTPS. The RDP client encapsulates the RDP communications in an RPC header, which is subsequently encapsulated with an HTTP header that is secured using SSL (or Transport Level Security, TLS). All the components that you need for an RPC over HTTPS solution need to be present. This is why, when you install the TS Gateway Role service, it automatically installs the RPC over HTTP Proxy. To understand more about how this protocol works, we recommend that you read "Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing," which you can find on the ISA Server Team Blog (available at blogs.technet.com/isablog).

This implementation requires Windows Server 2008 with Terminal Service Gateway installed, and this feature depends on RPC over the HTTP Proxy. For the RDP over RPC over HTTP Proxy feature to function, Internet Information Services (IIS) 7.0 must be installed and running. You also need Network Policy and Access Services, but, if you prefer, you can configure TS Gateway to use the NPS server, formerly known as Internet Authentication Services (IAS), to centralize storage, management, and validation of Terminal Services Connection Authorization Policies (TS CAPs). Finally, you must obtain an SSL certificate for the TS Gateway server if you do not already have one. It is important to emphasize that the ISA Server 2006 must trust the certificate authority (CA) that issues the certificate. Therefore, make sure to import the certificate to the Trusted Root Certificate Authorities Store.

Active Directory® Domain Services is only required if you configure a TS Gateway authorization policy that requires users to be members of an Active Directory security group to connect to the TS Gateway server. For this particular setup, we will use Active Directory on a computer running Windows Server 2003 SP2.

When we finished installing the Terminal Services Gateway service, the screen in Figure 2 appeared, showing the components that were installed. To connect the TS Gateway, clients must be running one of the following: Windows Vista®; Windows XP with SP2 and RDP 6.0 or later; Windows Server 2008; Windows Server 2003 with SP1 or later and RDP 6.0 or later. For more information on TS Gateway configuration, see Windows Server 2008 TS Gateway Server Step-By-Step Setup Guide available at go.microsoft.com/fwlink/?LinkId=122251. Now let's look at how to configure ISA Server 2006.

fig02.gif

Figure 2 TS Gateway installation summary (Click the image for a larger view)

Configuring ISA Server 2006

The first step is to create a Web Listener that will handle the requests from the external RDP client. Our Web Listener has the following parameters:

  • Authentication: Basic
  • Authentication Validation: Windows (Active Directory)
  • Connections: Enable SSL (HTTPS) connections on port 443
  • Certificates: certificate issued to tsg.contoso.com
  • Networks: External

Next, you create the Web publishing rule. From the ISA Server 2006 perspective, the RDP client will use the same protocol that Outlook® Anywhere uses, so choose the Exchange Server 2007 Wizard. Simply follow these steps:

  1. Right-click on the Firewall Policy, select New, and then click Exchange Web Client Access publishing rule.
  2. On the Welcome to the Create a New Web publishing rule page, type the name of the rule and click Next.
  3. On the Select Rule Action page, select the option Allow and click Next.
  4. On the New Exchange publishing rule page, select the Exchange version, in our case Exchange Server 2007. Select Outlook Anywhere (RPC/HTTP(s)) and click Next. (Note: do not select the Publish additional folders on the Exchange Server for Outlook 2007 client option.)
  5. On the Publishing Type page, select the option to Publish a single Web Site or load balancer and click Next.
  6. On the Server Connection Security page, select Use SSL to connect to the published Web server or server farm and then click Next.
  7. On the Internal Publishing Details page, in the Internal site name box, type the name of the TS Gateway server. Select the Use a computer name or IP address to connect to the published server checkbox and then, in the Computer name or IP address box, type the server name. If you do not know the name of the TS Gateway server, click Browse to navigate to its location. Note that the name you use on this page must match the common or subject name on the Web site certificate bound to the TS Gateway Web site.
  8. On the Public Name Details page, from the Accept requests for dropdown list, select This domain name (type below) and then, in the Public name box, type the public name that matches the name of the certificate that was issued for this URL—in our case, the name was tsg.contoso.com. Then click Next.
  9. On the Select Web Listener page, click on the dropdown list and select the Web Listener that was previously created, and then click Next.

On the Authentication Delegation page, select the option No delegation, but client may authenticate directly, and click Next.

On the User Set page, verify that the default option (All Users) is selected, click Next, and then click Finish, and apply it.

If you double-click in the rule and go to the Path tab, you'll see that the only path we have is /rpc/*. This is due to the fact that we used the Exchange Server 2007 Outlook Anywhere Wizard.

Testing and Monitoring Client Access

As mentioned before, you need the RDP 6.0 or later client to connect to the TS Gateway. To configure the RDP client app, launch it and type the name of the Terminal Server you want to connect to in the Computer field. Click on the Options button, the Advanced Tab, and then Settings, then type the external name of the TS Gateway server, as in Figure 3. In our example, this is the name on the certificate bound to the Web Listener that is used by our Web publishing rule to accept incoming requests. Note that Windows NT® LAN Manager authentication is used in this example. When finished, click OK and then Connect. You'll get an authentication prompt. Type the credentials of a user with access to the Terminal Server and click OK.

fig03.gif

Figure 3 Configuring the RDP client (Click the image for a larger view)

Note that the RDP 6.0 client (for Windows XP and Windows Server 2003) will show the screen in Figure 3. You will be prompted for authentication twice—the first authentication is for the TS Gateway computer and the second one is for the Terminal Server you want to access. This is an important point because while you might think this is due to the ISA Server configuration, in fact the ISA Server is not handling authentication at all since the Web publishing rule applies to "All Users," which allows anonymous connections through the ISA firewall.

The RDP client that comes with Windows Server 2008 has a Use my TS Gateway credentials for the remote computer, as shown in Figure 4. With this option selected, you don't need to type your credentials twice, resulting in a better user experience. This single sign-on option is also available on Windows Vista after you apply SP1.

fig04.gif

Figure 4 The Windows Server 2008 RDP client (Click the image for a larger view)

You can monitor the connection through the TS Gateway Manager, using the Monitoring option. The TS Gateway service also provides details when a non-authorized user tries to connect to the server. In Figure 5, the Event Viewer shows a connection attempt from a user who doesn't have permission to connect through the TS Gateway.

fig05.gif

Figure 5 Event logged into the TS Gateway service (Click the image for a larger view)

For this event, the internal IP address of the ISA Server 2006 is logged because the option Requests appear to come from the ISA Server computer is enabled in the Web publishing rule. If you want to register the original client IP address, you will need to change the ISA Server 2006 Web publishing rule and choose the option Requests appear to come from the original client on the To tab.

Monitoring from ISA Server

Using the new features of the ISA Server 2006 Supportability Pack, it is possible to closely watch and understand each connection to the internal network. Figure 6 shows one connection highlighted and, on the Request: line, the RPC_IN_DATA verb indicating the URL for the RPC over HTTP Proxy.

fig06.gif

Figure 6 ISA Server 2006 logging using the Supportability update (Click the image for a larger view)

If you continue to look at the logging, you should see the other RPC over HTTP verb, RPC_OUT_DATA. It is important to be aware of which HTTP methods are used, which are RPC_IN_DATA and RPC_OUT_DATA for RDP/HTTP, because if you have the HTTP Filtering configured to block these methods, the traffic will be blocked on ISA Server. If you would like to lock down your environment, you can configure the RDP/HTTP Web publishing rule to allow only these two methods. For more information on the HTTP methods typically used for publishing, you should read the article "HTTP Filtering in ISA Server 2004" at technet.microsoft.com/library/cc302627.

The Second Scenario

For this scenario, TS Gateway will use an NPS Central Policy located on another server. We will enforce a NAP policy for the clients connecting remotely through the TS Gateway. The same components that were used in Scenario 1 are used again here, only the NPS server will be added. However, due to NAP enforcement, more components will be used on the client side, as Figure 7 shows.

fig07.gif

Figure 7 Main components of the Scenario 2 topology (Click the image for a larger view)

Here is the explanation of the individual components. On the Windows Vista client, a System Health Agent (SHA) consists of the client-side components responsible for monitoring and reporting the client's heath state. Windows Vista comes with the Windows SHA, but there are other vendors working to create their own SHAs.

The NAP Agent on the client is responsible for establishing communications with the NAP Enforcement Server when the client tries to access the network. The NAP Agent sends the client's Statement of Health (SoH) to that server.

On the TS Gateway, the TS Resource Authorization Policy (TS RAP) is the component that allows you to determine which computers will be available to receive incoming RDP requests. The TS RAP also determines which users are allowed to establish RDP connections to specific servers.

The Central NPS is responsible for controlling the conditions, constraints, and settings that regulate access to the internal computers. System Health Validators (SHVs) on the Central NPS are responsible for evaluating whether the SoH submitted by the client is compliant with the policy set by the administrator.

Now let's change the TS Gateway to point to a NPS Central Server. Open the TS Gateway Manager Console, right-click on the server's name, and choose the option Properties. On the server's properties window, click on the TS CAP Store tab and select Central NPS server. Next, type the name or IP address of the NPS server and click on the Add button. You'll see a Shared Secret window pop up. Type the secret and click OK, then click OK again to close the window. You must remember this secret because it will be used on the NPS server.

Assuming that the NPS is already installed on another server, here are the steps you will need to follow:

  1. Open the Network Policy Server console and, in the left pane, click on NPS (Local).
  2. In the right pane, click on Configure NAP. The Select Network Connection Method for Use with NAP page will appear.
  3. Under Network Connection Method, select Terminal Services Gateway (TS Gateway) from the dropdown box and click Next.
  4. On the Specify NAP Enforcement Servers Running TS Gateway page, click on the Add button.
  5. In the New TS Gateway window, type the friendly name and the IP address of the TS Gateway server. And then at the bottom of the window, type the shared secret, using the same secret as on the TS Gateway server's configuration. Then click OK.
  6. On the Configure Client Device Redirection and Authentication Methods page, you can specify which devices will be redirected and the allowed authentication method (password or smart card). For the purpose of this example, leave the default options and click Next.
  7. On the Configure User Groups and Machine Groups page, add the user group that is allowed to establish the connection. For this example, click on the Add Users button under User Groups: (Required) and choose Domain Admins. Click OK and then Next.
  8. On the Define NAP Health Policy page, you'll notice that the default SHV is already selected. Notice also that on the bottom part of this page, access is denied for non-compliant computers. Leave the defaults selected and click Next.
  9. On the Completing NAP Enforcement Policy and RADIUS Client Configuration page, review the options that were previously selected. You can also click on the hyperlink Configuration Details and a HTML page will open up with a summary of your selections. When you're finished, click Finish.

This wizard takes care of configuring the settings for a number of important policies (Connection Request Policies, Network Policies, and Health Policies), significantly reducing the work needed to configure NAP for this scenario.

What about the Client?

So now that the server is all set up and configured, what do you have to do regarding the client?

To take advantage of the NAP enforcement policy, the client needs to be either Windows Server 2008 or Windows Vista. For Windows XP, you need to have SP3 installed, which includes the NAP client.

Besides the operating system requirement, there are some relevant services and settings that need to be enabled on the client side. These include the following:

  • Adding the TS Gateway server name to the Trusted Server list on the client.
  • Starting the NAP Agent service and setting the service startup type to Automatic.
  • Enabling the TS Gateway Quarantine Enforcement client.

To simplify the deployment of this solution, Microsoft has created the Terminal Services NAP client configuration command (Tsgqecclientconfig.cmd), which can be downloaded from go.microsoft.com/fwlink/?LinkId=122267. After running the command, the client will be configured as a NAP enforcement client for TS Gateway. Note that the command must be run with elevated privileges.

Throughout this article our principle goal has been not only to describe and explain the new TS Gateway feature that is available on Windows Server 2008 and to show how to publish it securely through ISA Server 2006, but also to provide you with an overall perspective on the security advantages that the combination of both products can provide for your company.

In today's world, to be connected from anywhere is a key requirement for just about any successful business. However, it is also necessary that this connectivity doesn't come at the cost of providing an improved experience for the user. And, even more importantly, it is mandatory that all of this be done in a manner that ensures security.

Dr. Thomas W. Shinder is an MCSE and ISA Server MVP. He has worked as a technology trainer, writer, and consultant since 1996. Dr. Shinder is the author of six books on the ISA Firewall. He is also the thought leader and primary perpetrator of ISAserver.org, the largest community of ISA Firewall admins and devotees on the Internet.

Yuri Diogenes, MCSE+S, MCTS, MCITP, Security+, Network+, and CCNP, is the Security Support Engineer on the Microsoft ISA Server/IAG Team. He writes articles for the Microsoft TechNet Library and the ISA Server Team blog. Yuri has worked with Microsoft technology since 1993. Before joining Microsoft, he worked as a Microsoft trainer, support analyst, and consultant.