Managing Terminal Service Users with Group Policy

Managing Terminal Service Users with Group Policy

Windows Server 2003 now provides specific Terminal Services policies to assist you in managing your terminal servers. These are but a handful of the group policies available and will need to be used in conjunction with the other non “TS-specific policies.

Within Server 2003 there are both computer-specific and user -specific terminal server group policies. These policies should be used to maximize the security and performance of your terminal servers. Computer-specific policies will affect the terminal server as a whole no matter who logs into the system. As such care must be taken when applying these particular GPOs.

A simple way to manage the GPOs for your terminal servers is to create an OU for your terminal servers and place the servers into that OU and then apply GPOs to it. One GPO that is very important to apply is the Computer Configuration, Administrative Templates, System, Group Policy, User Group Policy loop back processing mode (see Figure 20.2).

Figure 20.2. Enabling loopback processing mode.

Enabling this GPO is very important if you have created a separate OU for your terminal servers as mentioned previously and have defined the GPOs there. Otherwise the user context GPO settings will not take effect. This means that there are going to be settings that you want to take effect only when a user logs into the terminal server. To accomplish this you create your special set of GPO policies for the OU the terminal servers are in and apply the loopback processing to either merge or replace.

If you select Merge, then existing domain GPOs are merged with the special set created for the terminal servers. If Replace is selected then all the inherited GPO settings are ignored and only the set of GPOs defined for the terminal servers are applied. Some of the configuration options that are available for the GPO are as follows :

• Keep Alive Connections. This GPO is particularly useful when the clients are connecting via a WAN link or via the Internet. By enabling this GPO the terminal server will check the session state between it and the client instead of the default behavior, which more or less assumes the session state. The benefit realized by enabling keepalive connections is that if there is a network hiccup that causes a break in the network connection between the client and the server the session will be placed into a disconnected state. Should the client attempt to reconnect to the Terminal Server it will connect back to the existing session instead of being forced into a new session. This prevents the client's current work from sitting idle in a session it can no longer reconnect to without administrative intervention.

• Automatic Reconnection. Assuming the RDP client is version 5.2 or later this setting can be used with or in lieu of the keepalive connection setting. If automatic reconnection is enabled the client will attempt to reconnect to a broken session every five seconds for 20 attempts.

  GPO

  The shortest interval that can be configured is one minute. Realistically if the environment lends itself to needing configuration, some end user training will be needed. The server will inform the end user to wait one minute, or to default to the keepalive setting before attempting to reconnect. Otherwise this setting is effectively useless.

  
  

  BEST PRACTICE: Test This Setting in Each Particular Environment

  It will be wise to test this setting in each particular environment to verify the desired behavior is what occurs. Assuming the session will just pick back up where it was left off five seconds prior is not a good assumption. The connection speed, how the connection was broken, and so on, will affect whether the session is thrown into a disconnected state or remains active. If the session remains active a reconnect after five seconds really does no good because it results in a new connection instead of the user reconnecting back to their existing session and resuming their work.

  
  

• Restrict Terminal Services users to a single remote session. By enabling this GPO you can accomplish two major things. First is maximizing the performance of the terminal server. By not allowing the user to have multiple separate sessions running at any given time resources are preserved. Zombie sessions , those that are running in an active state with no user actually connected, or sitting idle in a disconnected state forever, are a waste of system resources and will have a direct effect on performance and scalability. By limiting the user to a single session, the zombie sessions can be avoided. Secondly by limiting the users to a single session end user confusion is greatly reduced. If the users have the potential to have multiple sessions they then have the potential over time to leave behind dozens of disconnected or active sessions, which in turn can leave applications running in those sessions that might end up causing all sorts of confusion or even data loss.

• Client/Server data redirection section. For granularity these type settings are normally configured client-side but in an environment that is particular about security it might be wise to look at these GPOs. Within this section, things like clipboard, drive redirection, printer redirection, com port redirection, and LTP redirection can all be disabled to prevent the user from being able to upload, download, or print information from the terminal server application.

• Encryption and Security section. Enables you to force an encryption level. This is useful not only for security but also for performance. If all the terminal server users are on the local LAN encryption might not be a huge concern for you and as such you can force the encryption level to low and save CPU cycles on the server. This helps with performance and the number of users per server. You can also force a prompt for the password during a connection. This is especially useful in a more secure environment where a user might have checked the Save Password option on her client, which means that any person that walks up to the machine and clicks the icon will now be able to successfully connect to the terminal server as this user and access that data. Instead now even if the Save Password option was checked, the terminal server will always ask for the password thus helping prevent unauthorized use.

• Licensing section. By default the terminal server licensing server will hand out licenses to any computer that requests one. Now (as of this printing) that a TS CAL is required for any type of computer accessing the terminal server, managing your licenses becomes more critical than ever. Not doing so might create headaches for you as the help desk gets flooded with calls from end users who cannot connect to the terminal server due to running out of licenses. By using the License Server Security Group policy, you can define a group of computers that the licensing server is allowed to issue licenses to, preventing rogue systems on the network, in perhaps a QA or development environment, from taking away CAL's need for end user access.

• Sessions section. This section is particularly useful for performance and even licensing reasons. You would use these settings to automatically log off disconnected sessions after a particular time frame. Disconnect active but idle connections for security reasons. There is also an option to log off the disconnected sessions or even active but idle sessions. This is particularly useful if the application being run is one with a limited number of licenses and a larger pool of users. By logging off idle sessions, instead of a license being used by a user who is off at lunch , that idle session is logged off and the license is made available to a new user.

User-specific settings are those settings applied to the users and not to the machine. As such by controlling via permissions what users or groups the GPO can be applied to you can control the behavior much more granularly than with the computer settings. Creative thinking here can go a long way in maximizing resources, performance, and security.

It Helps Avoid Confusion

You might find is a lot easier to define a particular application to run rather than publishing an entire desktop. It helps avoid confusion and makes it easier to secure the terminal server.

For example you could create two separate GPOs that modify the User Configuration settings differently. In this example the GPOs are called Finance and QA. For the Finance GPO you could define Start a Program on Connection and configure the financial package as that executable.

For security reasons you could also set the Remote Control of Terminal Server User Sessions to No Remote Control Allowed because this company has a policy that no one other than those in finance should be able to view finance information. Set the disconnected session to time out after 30 minutes and only allow reconnection from the original client to secure who is gaining access to the financial application and its data.

Conversely, the QA manager might want the administrator to define an application like a bug tracking package and would want to be able to view the QA engineer's session at any time without asking for permission in order to monitor his work. Perhaps also have the session automatically log off after 10 minutes of idle time because the department has a 20 concurrent user license for this particular application but has 40 engineers who might need to use it. By using Terminal Services and managing the sessions via the GPO it is now very possible to need only 20 licenses for 40 users and still allow all 40 users to work effectively.