Windows Vista Credential Delegation policy does not allow a Windows Vista RDP client to send saved credentials to a TS server when the TS server is not authenticated. By default, Windows Vista RDP clients use the Kerberos protocol for server authentication. Alternatively, they can use SSL server certificates, but these are not deployed to servers by default. There are three common scenarios where using the Kerberos protocol to authenticate the server is not possible, but using SSL server certificates is possible. Because SSL server certificates are not deployed by default, using saved credentials does not work when you attempt the following:
Connect from a home computer to a Terminal Services server through a TS Gateway server.
Connect to a stand-alone computer.
Connect to a terminal server farm.
When you connect from home through a TS Gateway server to a terminal server hosted behind a corporate firewall, the TS client has no direct connectivity to a key distribution center hosted on a domain controller behind the corporate firewall. As a result, server authentication using the Kerberos protocol fails. When you connect to a stand-alone server, the Kerberos protocol is not used.
For each of these circumstances, you need to enable server authentication, install SSL certificates issued by a trusted certificate authority (CA), and define the server name in the subject field. Deploy the certificates to all terminal servers that you want to use server authentication. Use the following procedure to add certificates to your terminal servers.
To set the SSL certificate for a connection
Click Start, click Run, and then in the Open box type tsconfig.msc and click OK.
In the Connections box of the Configuration for terminal server pane, double-click RDP-Tcp.
On the General tab, click Select.
Select the certificate you want to assign to the connection, and click OK.
In addition, Kerberos authentication does not work in terminal server farm scenarios because farm names do not have accounts associated with them in Active Directory®. Without these accounts, Kerberos-based server authentication is not possible.
To enable server authentication in a server farm, use SSL certificates that are issued by a trusted CA and that have the farm name in the subject field. Deploy them to all servers in your farm. The SSL certificate will provide server authentication for a terminal server, and the Credential Delegation policy will allow saved credentials to be used for remote connections.
Important A compromised client computer allowed to connect to a TS session could be used to attempt an attack against the Terminal Services server. Microsoft recommends ensuring that all client computers and servers in your organization are adequately protected against malware and are running the latest software updates to help mitigate this risk.
Change the Default RDP Port
If you are concerned about the attack surface exposure of the common RDP port (TCP 3389), you can configure the RDP session to use a different port. However, you must apply the modification to both the terminal server itself and all of the TS clients. It is important to note that changing this port does increase the complexity of both the terminal server deployment and any subsequent audit or troubleshooting steps. For this reason, Microsoft only recommends this step for high risk environments where organizations can justify the overhead required to manage the additional complexity.
For more information about changing the RDP port, see "How to change Terminal Server’s listening port": Microsoft Knowledge Base article 187623.
Use Smart Cards with Terminal Services
Terminal Services RDP client sessions in Windows Server 2008 support the ability to authenticate users who log on using smart cards to remote sessions in a domain that uses Active Directory® Domain Service (AD DS). A smart card is a form of two-factor authentication that requires the user to have a smart card and know the PIN to gain access to network resources. Smart cards provide secure, tamper-resistant storage for private keys and X.509 security certificates. Smart cards also allow you to require strong credentials from users in a manageable way to provide a more secure environment.
This option provides significant protection against an attacker using a valid user's account credentials to access hosts. If the terminal server requires a valid smart card for a user to log on, an attacker would have to not only know the logon and password details of the user, but also possess the user's smart card. For this reason, Microsoft recommends configuring your terminal server to require smart card authentication if your company has a two-factor authentication policy.
To use smart cards with Windows Server 2008 Terminal Services, you must have AD DS deployed in your organization, and your client computers must run a Microsoft client operating system with built-in smart card support, such as Windows Vista or Windows XP, and most devices that run Windows CE .NET. You must also ensure that the computers users can launch terminal server sessions from smart card readers that are locally installed.
Once you have met these requirements, deploying smart cards for use with Windows Server 2008 Terminal Services is the same as deploying smart cards for use with standard Windows client authentication.
Microsoft strongly recommends using the NTFS file system as the only file system on terminal server hard disk drives. The file allocation table (FAT) file system does not offer any user and directory security, whereas with NTFS you can limit subdirectories to certain users or groups of users.
This is important in a multi-user system, such as one that uses Terminal Services. Without the security that NTFS provides, any user has access to every directory and file on the terminal server. There also are additional performance advantages available only by using the NTFS file system, such as disk quotas and file system auditing.
Use TS Easy Print Exclusively
TS Easy Print is a new feature in Windows Server 2008 that enables users to reliably print from a TS RemoteApp program or full desktop session to a local or network printer installed on the client computer. Printers can now be supported without the need to install print drivers on the terminal server. When users want to print from a TS RemoteApp program or desktop session, they will see the full printer properties dialog box (printer user interface) from the local client and have access to all the printer functionality.
You can use Group Policy to limit the number of printers redirected to just the default printer, thereby reducing overhead, and improving reliability and scalability. To do this, apply the Group Policy setting for Redirect only the default client printer.
This Group Policy setting is located in Computer Configuration\ Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.
You can configure this setting by using either the Local Group Policy Editor or the Group Policy Management Console (GPMC). Enabling this policy setting ensures that only the TS client's default printer can be redirected on the TS server. This policy works with connections from any version of the TS client.
Partition User Data On a Dedicated Disk
If you allow users to upload data onto a terminal server's system drive, it is possible the data can seriously affect the server's performance, even to the point of becoming a DoS attack. For this reason, Microsoft recommends storing user data on a dedicated hard disk drive that is isolated from the operating system data.
To do this, you can use the Terminal Server User Profile setting in Group Policy to redirect the terminal server user account profile to the user's data drive.
To configure Terminal Services-specific profile settings manually
Open Active Directory Users and Computers.
Right-click the user account that you want to set profile settings on, and then click Properties.
Click the Terminal Services profile tab.
You can configure the following Terminal Services-specific profile settings manually using the following methods:
Terminal Services User Profile path. You can use this path to choose a place to store users' Terminal Services profiles other than the default location.
Terminal Services home folder. You can specify a path to a home folder for use with Terminal Server sessions. This directory can be either a local folder or a network share.
You also can enforce both of these options directly using Group Policy at the following location:
Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server
To provide additional protection, consider enabling quota management on the hard disk drive for user data to manage the disk space for users. For more information about using disk quotas, see Working with Quotas in the Step-by-Step Guide for File Server Resource Manager.
Create Specialized OUs for Terminal Servers
Where possible, Microsoft recommends that you consider placing the Terminal Server computer objects in a specialized OU to allow you to create system-wide restrictions for your terminal server environment. Doing this enforces computer-based restrictions on the Terminal Server. Administrators have the option to apply user-based restrictions to all users, including administrators who log on to the Terminal Server. You can add these restrictions, or establish them in place of policies for users when they log on to the domain. Refer to the computer loopback policy for additional information.
Note The policies mentioned in this section can severely restrict functionality for even the administrator account.
If you need to apply per-user restrictions, place the user account object into the locked down OU. However, this enforces user-based restrictions for that user account regardless of which computer the user accesses to log on to the domain.
Microsoft recommends one of two approaches when you implement Group Policy for this purpose:
Place user accounts into the locked down OU.
With this approach, you create Terminal Server-only user accounts and place them in the locked down OU. You can then allow user logons to the Terminal Server for only these users by using the Terminal Server Configuration MMC snap-in. Instruct users to only use these accounts on the Terminal Server. If some computer restrictions are necessary, disable loopback processing and place the Terminal Server computer object in the OU. Aside from the restrictive computer policies, users can have different levels of restrictions on the same Terminal Server. This implementation allows administrators to perform some operations on the Terminal Server while users are active.
Place only the Terminal Server computer object in the locked down OU.
With this approach, after installing and configuring all applications on the Terminal Server, you can place the Terminal Server computer object in the locked down OU, and then enable loopback processing. All users who log on to the Terminal Server are then restricted by user-based policies defined by the locked down Group Policy object (GPO), regardless of the OU that users are located in.
This can prevent many local changes from being applied to the Terminal Server. However, an administrator can still remotely maintain the server. If administrators need access to the Terminal Server, log off all users and temporarily restrict their logons to the Terminal Server. Move the Terminal Server computer object out of the locked down OU, then log on. Return the Terminal Server computer object to the locked down OU, and then re-enable user logons after maintenance is complete. This implementation does not require users to have multiple user accounts. It can also prevent configuration changes to the Terminal Server while it is in production.
After you have decided on the policy application approach that you want to use, the next step is to determine the Group Policy settings that you wish to apply to the environment. For the purposes of this guide, recommendations are included for the settings that can be most effective in helping to secure a terminal server installation in the EC and SSLF environments. However, due to potential compatibility and usability issues, these setting are not enforced in the GPOs that the SCM tool creates.
Important If you chose to enforce these setting recommendations, it is important to thoroughly test them to determine which ones are most effective in your environment. It is possible that some setting restrictions could cause compatibility issues with some applications that your organization requires.
|
