4. Terminal Services Gateway
Terminal Services
Gateway servers are a new and extremely neat feature available only in
Windows Server 2008; they allow external clients to connect to internal
Terminal Services servers via a gateway that redirects traffic to the
appropriate areas of an infrastructure. Before the days of TS Gateway
servers, users had to connect directly to Terminal Services within the
infrastructure via a virtual private network.
This could get unwieldy,
because you could authenticate only to the Terminal Services server
after the VPN was engaged and authenticated. This was tiring and more
than a little tedious. So, part of the goal of Windows Server 2008 was
to create a secure system of communication that allows for single
sign-ons in one location that authenticate throughout the enterprise. In
the following sections, we'll briefly review some of the technology
concepts used in Terminal Services Gateway servers and then discuss the
role they play in the enterprise in terms of placement.
4.1. Terminal Services Gateway Protocols and Requirements
You can access
Terminal Services Gateway servers in one of two ways. The first is via
Remote Desktop Protocol (RDP), and the second is via RDP over HTTPS.
Each of these has benefits and restrictions, which are outlined in Table 1.
Table 1. TS Gateway Protocols
| Authentication Method | Advantages | Disadvantages |
|---|
| TS Gateway RDP | Easy to set up | Requires port 3389 to be open |
| TS Gateway RDP over HTTPS | Easy NAT, no open ports, more secure | More difficult to set up |
Terminal Services Gateway
requires you to do some initial setup once you decide to install it.
Normally, these requirements will be added automatically, but if you
decide to plan for Terminal Services early on, it's a good idea to keep
the following in mind:
Once these requirements are met
and the gateway itself is installed, a lot of options are at your
disposal. You can give specific users and groups access to the Terminal
Services server through the use of Terminal Services connection
authorization policies (TS CAPs). Additionally, you can use TS CAPs to
set a number of conditions for security purposes (such as smart card
authentication) for an individual device. On top of TS CAPs, you can
install a Terminal Services resource authorization policy (TS RAP).
This, as the name implies, allows you to allocate a specific resource to
which users have access in your infrastructure.
NOTE
TS RAP supports both fully qualified domain names (FQDN) and NetBIOS.
Normally, an administrator will
create a TS RAP and associate a given group of users within Active
Directory. These are the users to which the remote access policy
applies. If users aren't in that group, they are denied access to that
remote source.
When designing your
Terminal Services infrastructure, you must include both a TS CAP and a
TS RAP in your design. This way, you are ensuring that you use the most
secure method in regard to access throughout your Terminal Services
Gateway server.
4.2. Terminal Services Gateway Placement
The exact placement of a
Terminal Services Gateway server is a process that depends on your
particular business needs. Several customizable solutions are available;
specific choices will be made based on your organization's security and
availability requirements.
First, you have the choice
of whether to place your server within the secure network or outside the
secure network in the perimeter. Each has advantages.
If you place your server outside
the secure network and within the DMZ (perimeter), your setup is
relatively easy, and it will not take long to establish. However, it
requires the internal port of 3389 to be opened behind the gateway.
If you place your
Terminal Services Gateway server behind the perimeter and inside the
secure network, you'll need to open port 443. This inherently creates a
security risk, but it's not as bad as, say, port 21, which is under
constant attack because of malicious users desiring access to data files
placed on an FTP server.
Another issue to consider
is whether to place the Terminal Services Gateway server in front of the
firewall. Placing it in front of the firewall lowers the security for
the server, but placing it inside the firewall lowers the overall
security for the network.
4.3. Terminal Services Gateway Security
As we've touched on
earlier, Terminal Services Gateway utilizes a lot of ports and
encryptions when transferring users across the network. The reason for
this is obvious: if a machine has access to the entire network, it will
need to have serious authentication processes. Otherwise, a computer
could access that machine and theoretically be able to hop around the
entire network.
Accordingly, when first
installing and designing your network, you will have to specify a
security certificate for SSL encryption. This process is called mapping. When you first install Terminal Services, you will see an option like the one in Figure 1.
For the gateway, you can either
choose to use an existing certificate or choose to create a new
certificate for use specifically for the gateway. Both are acceptable
practices. The more secure method is to create a custom certificate for
the gateway, but this also entails a bit more work for you as the
administrator. At least one of these methods is required to create a
stable certificate-based gateway.
4.4. Terminal Services Gateway Events
Thankfully, there is only
one really big event you want to pay attention to with TS Gateway
servers: event ID 100. Normally, this error code is caused by either the
TS Gateway service not being started or the NPS server or IIS server
experiencing problems.
The solution to the first
situation—TS Gateway not being started—is fairly simple. Just make sure
the service is started in the Services section.
The second problem, however,
is more complex. If the NPS server or IIS server is experiencing
problems, you will need to start monitoring the events occurring using
Event Log. Given the nature of these sorts of problems, it could be any
number of issues. However, doing this gives you a very good place to
start, because it tells you where the issue is originating.
5. Terminal Services Session Broker
Another one of the new and
exciting features that I mentioned briefly earlier is the Terminal
Services Session Broker. The Terminal Services Session Broker (TS
Session Broker or TS SB) is a Windows Server 2008 feature that allows
network load balancing across sessions within your entire
infrastructure. Therefore, it's important that you understand the
requirements and effect this can have at the enterprise level.
NOTE
Terminal Services Session Broker was formerly called Terminal Services Session Directory.
5.1. Terminal Services Session Broker Requirements
Most important, TS
Session Broker requires that all Terminal Servers and all servers
running TS Session Broker be operating at the Windows Server 2008 level.
(Other Windows Server versions cannot use this functionality.)
Additionally, clients using TS SB load balancing features need to be
running Windows Remote Desktop version 5.2 or newer.
5.2. Terminal Services Session Broker Load-Balancing Process
One of the main
advantages of TS SB is that it reduces the work being done on multiple
servers. In a complex environment, chances are a great many users are
trying to use the same resources at the same time. TS SB alleviates this
by using a two-phase process. Let's examine that process piece by
piece.
In the first phase, TS SB
utilizes a load-balancing feature such as DNS Round Robin to query the
initial authentication for the user's Terminal Services server.
The second phase is when the
real work begins. In this phase, the Terminal Services server that
authenticated the user will query the TS SB and ask, "Where should I
send this user?"
TS SB will then examine
the current load of each individual server running Terminal Services,
find the server with the least load, and then assign that user to it.
Additionally, TS SB will check to see whether the user who is
reauthenticating has a previously existing session. If so, TS SB will
try to reestablish that connection.
5.3. Terminal Services Session Broker Events
Two TS SB events in Windows
Server 2008 are noteworthy. Event ID 1001 occurs when TS SB fails to
start because of a problem with the RPC sequence. Event ID 1005 occurs
when TS SB fails to start because of a problem with registering the TPC
authentication information.
Event ID 1001
When this event occurs, it
will be accompanied by the following message: "The remote procedure call
(RPC) to join TS Session Broker to %1 failed."
The first thing to do if
you receive this message is to confirm network connectivity between the
two servers. Without it, there is no way the computers can communicate,
so the error may keep reproducing. However, if they can communicate, the
resolution for this problem is to first add the computer for the
Terminal Services server to the Session Directory Computers local group
on the TS SB server and then try to join once again. This will usually
resolve the problem.
Event ID 1005
This event usually is
signaled either with an affirmative message on the client side
confirming that the client has established contact with the TS SB or
with the following message: "The Terminal Services Session Broker
service failed to start due to a problem registering RPC authentication
information. The error code was %1."
This event causes a lot more
concern than event ID 1001. However, it can more often than not be fixed
by restarting the TS SB service. Once this is done, you can use
Administrative Tools to confirm that the TS SB service is running and
then manually start it or set it to automatic if, for some reason, it
isn't.
