Home

Microsoft Terminal Services Reference Design

Posted May 26th, 2008 by roddyr

 

Microsoft Terminal Services Reference Design
 
Author:
Roddy Rodstein, CISSP, MCSE, LPI, CEH, CCA
 
Limits of Liability and Disclaimer of Warranty
 
This publication contains information protected by copyright. This book may not be duplicated in any way without the express written consent of the publisher, except in the form of brief excerpts or quotations for the purpose of review. The information contained herein is for the personal use of the reader and may not be incorporated in any commercial programs, other books, databases, or any kind of software without the written consent of the publisher. Making copies of this book or any portion for any purpose other than your own is a violation of United States copyright laws.
 
 
Warning and Disclaimer
 
Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.
 
The information found in this document was gathered from many different sources in the computing world. It is provided for informational purposes only. Use common sense in applying these concepts and tips. Screen shots may vary from environment to environment.  Please verify correctness and applicability in a test environment first and then deploy to your production environment(s).
 
© 2008 Roddy Rodstein
http://seoutsourcing.com
All rights reserved.
 
 
Trademarks
 
Trademarked names appear throughout this book. Rather than listing the names and entities that own the trademarks or include a trademark symbol with each mention of the trademark name, the publisher states that he is using the name for editorial purposes only and to the benefit of the trademark owner, with no intention of infringing upon that trademark.
 
 
About the Author 
 
Roddy Rodstein (CISSP, MCSE, LPI, CEH, CCA) has over 10 years of professional experience in the IT industry. In his current role at Oracle, he is a member of the Unbreakable Linux and Oracle VM team. Before joining Oracle, Roddy spent six years at Citrix supporting the company's core product, XenApp. During his tenure with Citrix, he wrote and published an “in the Box” series of e-Books, including Nfuse Elite in a Box, MetaFrame Secure Access Manager in a Box, MetaFrame Presentation Server for UNIX in a Box, and Citrix SmartAccess in a Box. Earlier in his career, Roddy successfully established, owned, and operated an IT consulting business that specialized in server based computing and remote access solutions. His professional achievements also extend to writing and self-publishing industry reference guides currently available on Amazon, Securing Microsoft Terminal Services (ISBN: 061514330X) and Citrix CCA MetaFrame 1.8 for Windows Exam Cram (ISBN: 1576109453).
 
 
 
Table of Contents:
 
 
 
 
The Terminal Server Reference Design is a high level baseline that represents a secure, flexible, and scaleable framework. It contains software, hardware, and storage components that enable an organization to centralize the deployment and management of its Windows desktop and Windows applications infrastructure using Microsoft Terminal Server.
 
Figure 1.1 shows an architectural overview of the Terminal Server Reference Design. Please note that each security domain (i.e. uncontrolled, controlled, restricted, and intranet) is a separate network segment. A firewall and/or a router are used to filter network traffic between security domains.
 
Figure 1.1
 
 
As shown in Figure 1.1, there are multiple components within the Terminal Server Reference Design. These components include, but are not limited to, the following:
1.      The Terminal Server Farm.
2.      Required Terminal Server Infrastructure Services.
3.      Required Microsoft Infrastructure Services.
4.      Back-end Application and Data Storage Servers.
5.      Required Network Infrastructure.
6.      Operational Support Systems (OSS) includes help desk, system and SLA monitoring, and capacity planning as well as application, service pack, and hotfix provisioning.
 
In addition to the components listed above, there are at least four distinct network subnets along with additional isolated subnets within the restricted security domain. These network subnets include the
1.      Uncontrolled
2.      Controlled
3.      Restricted
4.      Intranet
 
 
Multiple Terminal Servers that are load-balanced are commonly referred to as a Terminal Server farm. A Terminal Server farm consists of a network load-balancing solution, two or more Terminal Servers, and optionally a Session Directory server. A load-balanced farm is accessed by end users with a single virtual IP address; therefore, each Terminal Server in a farm should be identically provisioned and configured to ensure consistency.
A Terminal Server farm allows organizations to scale out their Terminal Server environment by adding machines to the farm to increase capacity by providing robust, centralized application delivery and management capability. It is scalable, reliable, manageable, and secure. And it offers predictability in terms of performance, user experience and cost.
 
 
A Terminal Server farm consists of a network load-balancing solution, two or more Terminal Servers, and an optional Session Directory server and a licensing server.
 
 
A Terminal Server farm can be load-balanced with Microsoft’s integrated load-balancing service or a third-party hardware load balancer. Load Balancers allows a group of servers to be configured as a load-balanced cluster with a single Virtual IP address (VIP). Users access the cluster with the DNS name associated with the Virtual IP address.
 
 
The Session Directory service is an optional feature that provides a single point of entry into a load-balanced Terminal Server farm. The Session Directory service is used together with a load-balancing solution. Session Directory acts as a RDP session load-balancer, connecting users to the least busy server while maintaining a database of active sessions within the Terminal Server farm. This feature enables disconnected users to reconnect to their active, disconnected session on the same server.
 
 
Terminal services licensing consists of the Microsoft Clearinghouse, one or more Windows Server 2008 terminal services licensing servers (any edition of Windows Server 2008), and Terminal Servers.
 
From a security perspective, it is important to consider high availability when designing a Terminal Server farm, fault tolerance, and high availability for Terminal Server licensing; Session Directory and Load-Balancing must be considered in order to ensure the availability of the system while meeting regulatory mandates.
 
Required Microsoft Network Infrastructure Services
o                        The Microsoft Network Infrastructure Services required to support a Terminal Server farm includes Active Directory, DNS and File Services.
 
Back-End Application and Data Storage Servers
o                        Many applications require a back-end application and/or data storage. An example of this is an N-tier web application. The front end resides on a web server, and the data resides on a SQL Server database.
 Required Network Infrastructure Services
o                        The required network infrastructure services required to support a Terminal Server farm include firewalls, VPNs, switches, routers and load balancers.
 Operational Support Systems (OSS)
o                        Operational Support Systems (OSS) encompasses technologies, services, and solutions that help an organization efficiently manage their environment and provide support to their users.
Users access the system from either the Internet or within the LAN environment. From the Internet, users are routed to one of the Terminal Server farm servers via a VPN. From the LAN, users are routed to one of the Terminal Server farm servers via a router. Depending on the type of application and data request, a connection to a back-end application server and a back-end data store may also have to be made to deliver an application or data.
 
 
This section highlights the pros and cons of two network topologies. The first example shows a segmented network connected to the Internet with a firewall. The second example differs from the first by using additional segmentation within the controlled and restricted security domains. These examples show how infrastructure design concepts with Terminal Server allow organizations to meet information security and regulatory requirements.
 
The network topology examples in this chapter do not include all possible situations. There are organizations that extensively segment their networks to meet business objectives and regulatory requirements. However, the design concepts discussed here can be translated to include other architectures and environments.
 
Example 1 shows a segmented network with three security domains connected to the Internet with a firewall. A firewall separates a controlled (DMZ) security domain from a restricted (production) security domain, and a router separates a controlled (intranet) security domain from the restricted security domain. Each security domain is a separate network segment. A firewall and router are used to filter network traffic between security domains.
Figure 1.2 shows Example 1.
Figure 1.2
 
In Example 1, a router is placed between the intranet and production security domain to filter traffic between domains. From a design perspective, there are many considerations with regard to traffic filtering between the intranet and production security domains. We will review two different approaches, one wherethe router allows a wide variety of traffic between security domains and the other using Terminal Server to limit traffic between security domains to a single port. The latter example illustrates how Terminal Server can be leveraged to reduce the number of open ports between security zones.
 
In Example 1, users access resources in the production security domain from domain member PCs. This approach requires a wide variety of ports to be open between security domains, allowing PCs to communicate with and receive resources from servers in the production security domain. In the example, services and resources, such as domain authentication, file, print, web, email and Terminal Server, are the services that require communication and open ports between security domains.
 
Table 1.1 shows the ports and services used in the first example.
 
Table 1.1 

Protocol
Service
Port
Description
TCP
RPC
135
Microsoft's RPC implementation runs over TCP port 135. RPC is used by a number of higher level protocols for their transport layer, such as by DCOM.
UDP 
Domain        
53
Domain Name Server (DNS). DNS servers offer different services on TCP and UDP. TCP is used for "zone transfers" of full name record databases, while UDP is used for individual lookups. Zone Transfers will provide an entire network map.
TCP
Domain
53
UDP               
Kerberos
88
Kerberos traffic uses UDP/TCP protocol source and destination port 88. It’s a default authentication protocol.
TCP
Kerberos
88
UDP 
netbios-ns   
137
NetBIOS Name Service (NBNS) is also known as Windows Internet Name Service (WINS).
TCP 
netbios-ssn  
139
NetBIOS Session Service. The Session Service is used to handle NBT sessions.
TCP 
microsoft-ds 
445
SMB Direct. Since Windows 2000 Microsoft added the ability to run SMB directly over TCP/IP, without the extra layer of NBT.
TCP 
LDAP
389
Lightweight Directory Access Protocol (LDAP), used by Active Directory, Active Directory Connector, and the Microsoft Exchange Server directory.
UDP
LDAP
389
TCP 
LDAP to Global Catalog   
3268
LDAP to Global Catalog search communication.  
TCP
POP3
110
POP (Post Office Protocol) is used by mail clients to retrieve email.
TCP
HTTP
80
World Wide Web HTTP. Port 80 is the primary port used by the world wide web (www) system.
TCP
HTTPS
443
HTTP protocol over TLS/SSL. This port is used for secure web browser communication.
TCP
RDP
3389
Microsoft Remote Display Protocol. This port is used by Microsoft Terminal Services.

This first example is a common topology in a Windows domain environment in which PCs are domain members, centrally managed by Active Directory and have locally installed client-server applications. This scenario adds risk because of the amount of open ports between the production and intranet security domains, which could be used by viruses, worms or an intruder to compromise systems in either security domain. With this topology, most organizations run similar PC operating systems as their servers. A monolithic operating system approach, together with a wide range of open ports between network segments, introduces the risk that a PC virus or worm that isintroduced in one security domain could spread to similar operating systems in other security domains.
 
The second example as shown in Figure 5.4 uses Terminal Server as the primary application and data access solution. In this scenario, a router is used to filter network traffic between security domains and Terminal Server, which is used to filter and monitor all application and data access. This configuration reduces the amount of open ports between the intranet and production security domains to port “3389” for RDP traffic. Limiting the open ports to 3389 between the intranet and production security domains is an ideal solution in a thin client or unmanaged PC environment because the thin clients or PCs communicate directly with the Terminal Servers on port 3389. All access to applications and data can be rigorously audited from router and Terminal Server logs. Leveraging this configuration with Terminal Server reduces the number of open ports between security domains which reduces the attack surface between security domains. This model is commonly referred to as a data center enclave through which the production security domain classification is secured, not restricted. This model considers the intranet security domain as uncontrolled and treats all user access as remote access, similar to an Application Service Provider (ASP) or Software as a Service (SAAS) model.
 
Typically, organizations use a configuration somewhere in the middle of these the two examples. They support managed domain member PCs in the intranet security domain with the minimum number open ports between security domains to meet business requirements. Organizations that adopt a thin client model are able to limit traffic between the intranet and production domain to 3389 effectively, creating a data center enclave.
 
Let’s shift focus from the router configurations between the intranet and production security domains and look at the overall design with regard to defense in depth, compartmentalization of information and network segmentation. The first example shows a segmented network with three security domains connected to the Internet with a firewall. From an infrastructure design perspective, the defense in depth strategy is implemented by using network segmentation. Network segmentation provides multiple layers of defense from a networking perspective, such as traffic filtering between security domains. With the addition of administrative and technical security controls, such as encryption, virus prevention and operating system hardening, defense in depth is demonstrated with multiple layers of security.
 
In terms of compartmentalization of information, the first example highlights design deficiencies to effectively compartmentalize users, applications, data, and information based on their sensitivity, criticality, and value within a security domain. A design deficiency exists when a necessary control is missing or an existing control is not properly designed. A security breach or virus outbreak on any system in the intranet or production security domains will be challenging to isolate from other systems on the same network segment. For example, if a server in the production security domains is compromised, it could be used as a hacking vector to other machines on the same network.
 
In terms of infrastructure designs, the first example requires additional segmentation within the intranet and production security domains in order to provide compartmentalization of information. The lack of segmentation within the intranet and production security domains can be of particular concern for organizations with must comply with regulatory mandates like Sarbanes-Oxley, Health Insurance Portability and Accountability and Gramm-Leach-Bliley.
 
Example 2 differs from the first by using additional segmentation within the intranet and production security domains. This strategy allows compartmentalization of users, applications and data based on their sensitivity, criticality and value within a security domain. Each segment is on a separate isolated network and governed by its own policies that describe the security requirements of the isolated network. If a security breach or virus outbreaks on a system in one segment occurs, it could be isolated within its security domain. Network segmentation is accomplished by using a firewall, router or VLAN to partition, control and monitor traffic between security domains.
 
Figure 1.3 shows Example 2. Each security domain is a separate network segment. A firewall and router are used to filter network traffic between security domains.
Figure 1.3
 
Figure 1.3 shows the intranet security domain with three isolated segments. One segment is dedicated for the general office productivity population, the second for developers, and a third for the finance department. This strategy supports compartmentalization of information. For example, if a security incident such as a virus occurs in the general office productivity population, it would be easier to isolate within its security domain.
 
The production security domain has five isolated segments, and each segment is a separate isolated network. It contains a dedicated segment for the Terminal Servers, email, mainframe, directory services, and one for web, database and file server. Segmentation allows for compartmentalization of resources along with the configuration of granular traffic and filtering rules between segmentsand security domains. The design strategy shown in Figure 1.3 allows the implementation of the appropriate security control such asencryption or logging to segmentsand security domains based on their sensitivity, criticality and value.
 
 
Standards are used to provide the uniform use of technologies to drive consistency and reproducibility, lower operational costs, and enable faster deployments of technologies and functions. Standards allow organizations to meet strategic and tactical Information Technology objectives better while maximizing the business value of information technology.
 
From a security perspective, Windows Terminal Server Standards provide uniformity and predictability, which improves the security posture of an environment. The example Terminal Server Standards policy will reference other linked policies.
 
The following example is a Windows Terminal Services Standards policy.
 
Multiple load-balanced Terminal Servers are referred to as a Terminal Server farm which consists of a network load-balancing solution, two or more Terminal Servers and optionally a Session Directory server. A Terminal Server farm allows an organization to scale out its Terminal Server environment by adding servers to the server farm to increase capacity and to scale horizontally.
 
From a network design perspective, Terminal Servers will be placed within close physical proximity to the data to ensure that as little data as possible traverses over a network, thereby promoting efficiencies in bandwidth management and bandwidth usage.
  • A centralized server farm will be established and collocated with application and user data.
  • If the data or application cannot be hosted in the centralized data center, a separate Terminal Server or Terminal Server farm will be established within close physical proximity to the data or application.
  • When more than two Terminal Servers are deployed, a server farm will be established with a Session Directory and the Microsoft load-balancing service.

Session Directory

  • A Session Directory will be installed on a dedicated and highly available server.

Load-Balancing

  • The Microsoft load-balancing service will be used.
  • All load-balanced farm servers will be on the same subnet.

Terminal Server Licensing Server

  • Terminal Server licensing shall be installed on two domain controllers in Enterprise license server mode.

Licensing

  • One “server license” for each Terminal Server is required.
  • One Terminal Server Client Access License (TSCAL) is required for each user or device that connects to the Terminal Server farm.
  • Terminal Server will be configured in per user licensing mode.

Hardware

  • x86-64 bit virtualization platform will be used.

CPU

  • 1 virtual processor.

Memory

  • 2 GB memory.

Virtual Hard Disk

  • The operating system files and paging files will be placed on the same partition.
 
Operating System Installation and Configuration
 

Operating System

  • Windows Server 2008 Standard x86 Edition shall be used for single server environment.
  • Windows Server 2008 Enterprise x86 Edition shall be used for each member server in a server farm.

Installation

  • An automated server build process will be established to maintain consistency and stability and to enable rapid deployment and recovery.

Anti-virus Prevention

  •  All Terminal Servers will have <Product Name> anti-virus software installed and automated to run at regular intervals.
  • Anti-virus software and virus pattern files must be kept up to date.
  • Guidelines from the Desktop Application Security Technical Implementation Guide v 3, release 0, Appendix B. Anti-virus Product Specific Guidance will be used to configure and support <Product Name> anti-virus software.

Patch management

  • Patch management will be automated using Windows Server Update Services.

Server Security

Terminal Server Installation

Terminal Server Management

  • Terminal Servers will be managed in a separate Organizational Unit (OU) by Group Policy.

Securing Terminal Server Sessions

Applications

Application Access Rights

  • All applications that access classified, financial or human resources data will require access restrictions.

Client Devices

RDC Clients

  • The Remote Desktop Connection (RDC) client and Remote Desktop Web Connection clients will be supported.           

Printing

  • Server printers and client printers will be supported.

User Profiles

  • Terminal Server roaming user profiles will be implemented.
  • User profiles will be managed via Group Policy.
  • User profiles will be kept as small as possible.
  •  Profile size will be limited per Group Policy.
  • Creation of new profiles will be fully automated.
  • User profiles will be backed up as part of the daily data backup process.

Monitoring and Reporting

  • System Center Operations Manager (SCOM) is the standard monitoring and reporting solution.

Security Policy Auditing

Incident Response

Change Management

Backups

  • <Company Name> employs automated server builds, application packaging, and deployment for Terminal Servers with remote storage of all Terminal Server user and application data.
  • Terminal Servers will not be backed up.
  • Terminal Server roaming profiles will be backed up as part of the daily data backup process.
 
Terminal Server Security Baselines tend to be large documents that cover server role configurations, Terminal Server security configurations and Terminal Server Desktop security. The next three sections will highlight each portion of an example Terminal Server Security Baselines. First, we will review the Server Role configurations and Terminal Server security configurations.
 
 
This section of the example baselines runs through the procedure to create a Terminal Server security role using the Microsoft Security Configuration Wizard. There are many third party solutions to develop security policies, but we selected the Microsoft Security Configuration Wizard because of its availability, acceptance and cost. The Security Configuration Wizard is bundled with Windows Server 2003 with Service Pack 1 and is well documented and widely adopted.
 
Microsoft calls the Security Configuration Wizard “an attack-surface reduction tool for Windows Server 2003 with Service Pack 1 family of products.” The Security Configuration Wizard supports a GUI and command line interface for the development of server security policies. It leverages Windows 2003 roles-based infrastructure to determine which ports and services need to be enabled for a given server role.
 
While developing a security policy, the server role’s minimum requirements are defined by disabling functionality that is not required. The security policy disables unneeded services, blocks unused ports, reduces protocol exposure and defines a high signal-to-noise audit ratio. The Security Configuration Wizard generates security policies as an XML file and the command-line utility can be used to convert an XML file into a Group Policy Object. Once the Group Policy Object is created, it must be linked to the target Organizational Unit. Security policies can be applied locally in XML format or centrally via Group Policy Objects.
 
Developing a security policy is broken down into four sections. These sections are organized and referenced in the Security Configuration Wizard user interface, using a security configuration database structure. Once the security configuration database is processed, it can be viewed or printed using the Security Configuration Wizard Viewer. The Wizard walks through the Server Role, Network Security, Registry Settings, Audit Policy and Internet Information Services (if installed) sections related to the server’s roles and functions.
 
The Security Configuration Wizard walks through the following sections and sub-sections:
 
Server Roles
  • Client Features
  •  Administration and Other Options
  • Additional Services
  • Handling Unspecified Services
Network Security
  • Open Ports and Approved Applications
Registry Settings
  • Require SMB Security Signatures
  •  Outbound Authentication Methods
  • Inbound Authentication Methods
Audit Policy
  • Do Not Audit
  • Audit Successful Activities
  • Audit Successful and Unsuccessful Activities
Internet Information Services
  • Web Service Extensions for Dynamic Content
  • Virtual Directories to Retain
  • Prevent Anonymous Users from Accessing Content Files
 
Server Roles Configuration
This section allows the configuration of installed and available services based on the server’s role. The Wizard does not install components or set up a server like the Configure Your Server Wizard does. Instead, it will enable services and open ports based on a list of server roles and client features.
 
Network security
This section is designed to configure inbound ports using the Windows Firewall. The configuration is based on the roles and administration options selected in the Server Role section. It ispossible to restrict access to ports and configure port traffic to be signed or encrypted using IPSec. This section will be skipped in the example because the Windows Firewall is not installed.
 
Registry settings
This section addresses the configuration of the protocols used to communicate with other computers on the network. This section allows a server to be configured in order to reduce protocol exposure when communicating with legacy Windows operating systems. Communication with legacy Windows operating systems uses protocols that are vulnerable to password cracking and man-in-the-middle attacks.
 
Audit policy
This section allows the configuration of system auditing based on organizational auditing requirements. The audit policy can be configured not to audit any events, to audit only successful events, or to audit both successful and unsuccessful events. The audit policy not only configures the Object Access events but also the entire audit policy list of events.
 
Internet Information Services (IIS)
This section is displayed only if IIS is installed. This section allows the configuration of the security aspects of Internet Information Services (IIS). This section will be skipped in the example because IIS is not installed.
 
Terminal Server Security Configurations
 
This section will review the procedure to implement the security controls from Appendix B of the Windows 2003/XP/2000 Addendum Version 5, Release 1 STIG and the recommended restrictive settings from Microsoft “Locking Down Windows Server 2003 Terminal Server Sessions” white paper. All of the STIGs configurations and the Microsoft recommendations will be implemented using Group Policy.
 
The Security Technical Implementation Guides (STIGS) and the NSA Guides are the configuration standards for the U. S. Department of Defense (DoD) Information Assurance (IA) and Information Assurance-enabled devices and systems. Appendix B of the Windows 2003/XP/2000 Addendum Version 5, Release 1 STIG addressed the Department of Defense’s minimum security requirements for Terminal Server. Appendix B is broken into nine sections.
 
List 1.1 shows the sections inAppendix B.
  • B.1 Terminal Services 
  • B.2 Windows Installer
  • B.3 Windows Messenger
  • B.4 LogonB.5 Group Policy
  • B.6 Windows Time Service
  • B.7 Network Connections
  • B.8 Installation of Printers Using Kernel-mode Drivers
  • B.9 Media Player – Automatic Downloads
Note: B.6 will not be included in the example Baseline.

In addition to the STIG, an extensive list of recommended restrictive settings can be found in a Microsoft white paper named “Locking Down Windows Server 2003 Terminal Server Sessions.” Not all of the setting from the STIG and Microsoft’s white paper are necessary; therefore organizations should evaluate and test all of the settings to determine if they are too restrictive for their environment. Enabling all of the settings will create a restrictive environment that may make the environment challenging to manage and hinder user productivity.

In addition to the setting in Appendix B of the Windows 2003/XP/2000 Addendum Version 5, Release 1 STIG and the recommended restrictive settings from Microsoft “Locking Down Windows Server 2003 Terminal Server Sessions” white paper, there are additional Group Policy configurations that should be considered. For example, virtual channel restrictions and encryption levels should be evaluated to determine which settings meet an organization’s specific requirements.
 
Table 1.2 lists security related virtual channel Group Policy settings. The settings can be configured with the Terminal Services Configuration utility (tscc.msc) or centrally via Active Directory from:
Computer Configurations > Administrative Templates > Windows Components > Terminal Services > Client/Server data redirection
 
Table 1.2

Client/Server data redirection Setting
Explanation
Do not allow clipboard redirection
Determines if sharing of clipboard (cut and paste) contents between Terminal Server applications and local applications during a Terminal Server session should be disabled.
Allow audio redirection
By default Terminal Server on Windows Server 2003 disables audio redirection. 
Do not allow COM port redirection
Determines if the mapping of client COM ports during a Terminal Server session should be disabled.
Do not allow client printer redirection
Determines if mapping of client printers during a Terminal Server session should be disabled.
Do not allow LPT port redirection
Determines if the redirection of data to client LPT ports during a Terminal Server session should be disabled.
Do not allow driver redirection
Determines if the mapping of client hard drives during a Terminal Server session should be disabled.

 
All of the RDP client encryption levels can be configured locally on a Terminal Server using the Terminal Services Configuration utility (tscc.msc) or centrally via Active Directory. Using Active Directory administrators can select between three setting: Client Compatible, High or Low. The Group Policies can be configured in Active Directory by editing the desired Group Policy Object in the following location:
Computer Configurations > Administrative Templates > Windows Components > Terminal Services > Encryption and Security.
 
Table 1.3 shows the client encryption settings.
Table 1.3

Setting
Explanation
FIPS
All data sent from client to server and the data sent from server to client is encrypted using the Federal Information Processing Standard (FIPS) encryption algorithms with Microsoft cryptographic modules.
Note: FIPS encryption must be configured locally on each Terminal Server using the Terminal Services Configuration utility (tscc.msc).
Client compatible
All data that traverses between the client and the server is encrypted based on the maximum key strength supported by the client.
High
All data that traverses between the client and the server is encrypted based on the server’s maximum key strength. Clients who do not support this level of encryption cannot connect.
Low
All data that traverses between the client and the server is protected by encryption based on the maximum key strength supported by the client.
Disabled or Not Configured
If the setting is Disabled or Not Configured, the encryption level is not enforced via Group Policy. Note: Administrators can configure the encryption level on the server with the Terminal Services Configuration tool.

 
 
 
Purpose
The purpose of this baseline is to define a security baseline for all Terminal Servers. Before any servers are placed on the production network, standard processes will be executed to ensure that all servers are installed and maintained in a manner that prevents unauthorized access, unauthorized use and disruptions in service.
 
Scope
This baseline is for all Windows Terminal Servers on the internal network and will be reviewed in conjunction with the other IT infrastructure policies. This baseline is divided into two sections: Server Role Configurations and Terminal Server Security Configurations.
 
Terminal Server Security Baseline
1.0 Server Role Configurations
The following procedure will create a XML template for a Windows Server 2003 Terminal Server, using the Security Configuration Wizard. Export it as a GPO and then link it to the Terminal Server Organizational Unit.
 
The template will be created, tested and validated in a lab or pilot environment on a test server. The test server will be provisioned identically as production Terminal Servers. All of the template settings will be validated against each production application with test users. While testing templates, the revision number will be appended to the end of the file name, such as WTS_DEV01, WTS_DEV02, and so forth. Once a template is validated, it will be named WTS_Prod_month/day/year and placed in production. Template modifications will be made using the Security Configuration Wizard option of “Edit an existing security policy.”
 
1.      Log on to the target Terminal Server as administrator.
2.      Click Start > Run, type “scw.exe” in the text area, and then click OK to access the Security Configuration Wizard.
3.      From the Welcome window, click Next to proceed.
4.      From the Configuration Action window, select the “Create a new security policy” radio button. Click Next to proceed.
5.      From the Select Server window, enter the “FQDN” of the local host. Click Next to proceed.
6.      From the Processing Security Configuration Database window, wait until the database has processed. Click Next to proceed.
7.      From the Role-Based Service Configuration window, click Next to proceed.
8.      From the Select Server Roles window, select only “Terminal Server.” Click Next to proceed.
9.      From the Select Client Features window, select the following:
  • Automatic update client
  • DNS client
  • DNS registration client
  • Domain member
  • Microsoft networking client
  • WINS client
Click Next to proceed.
10. From the Select Administrator and Other Options window, select the following:
  • Application Experience Lookup Service
  • Application installation from Group Policy
  • Terminal Server Printer Redirection
Click Next to proceed.
11. From the Select Additional Services window, select the desired anti-virus services. Click Next to proceed.
12. From the Handle Unspecified Services window, set the policy to “Do not change startup mode of the service.” Click Next to proceed.
13. From the Confirm Services Changes window, click Next to proceed.
14. From the Network Security window, select the “Skip this section” check box. Click Next to proceed.
15. From the Registry&n