Deploying Terminal Services
Deploying Terminal Services |
|
Security is an essential component of your Terminal Services deployment plan. In addition to the security issues addressed in your Windows 2000 deployment planning, Terminal Services has considerations that are specific to a multi-user environment.
This section discusses Terminal Services–specific security issues including the version of the NTFS file system used in Windows 2000, user and administrator rights, auto logon procedures, encryption, and other security considerations.
For more information about Windows 2000 security, see "Planning Distributed Security" in this book.
Because of the multi-user nature of Terminal Services, it is strongly recommended you use the Windows 2000 version of NTFS as the only file system on the server, rather than file allocation table (FAT). FAT does not offer any user and directory security, whereas with NTFS you can limit subdirectories to certain users or groups of users. This is vitally important in a multi-user system like Terminal Services. Without the security that NTFS provides, any user has access to every directory and file on the Terminal server.
Terminal Services is distributed with a default set of user rights that you can modify for additional security. In order to log on to a Terminal server, a user must have local logon rights on that computer. By default, a Terminal server in Remote Administration mode only grants rights to Administrators on the computer, and in Application Sharing mode grants rights to all members of the Users group. Because Windows 2000 includes all domain users in the Users group on a computer that is not a domain controller by default, all domain users are able to log on to a Terminal server providing Application Sharing. The groups and users allowed to log on, and the control granted to them, can be altered through the Terminal Services Configuration feature.
Users who are granted access through a protocol such as RDP, and who interactively log on to a Terminal Services–enabled server are automatically included in the built-in Terminal Services Users local group. A user only belongs to this group while they are interactively logged on to a Terminal server. This built-in group gives administrators control over resources Terminal Services users can access. This group is similar to the built-in Interactive group.
Avoid configuring Terminal Services as a domain controller because any user rights policies you apply to such a server will then apply to all domain controllers in the domain. For example, to use Terminal Services users must be authorized to log on locally. If the server running Terminal Services is a domain controller, users will be able to log on locally to all domain controllers in the Terminal Services domain.
Members of the Administrators group on a Terminal server have control over which users have access, the rights they have, and the applications they can run. Most of this control is part of the usual rights of an administrator on a Windows 2000 server. These rights are extended under Terminal Services to include:
Depending on how people will be using Terminal Services, you might need to grant them access to the file system. Users who only need access to a single application, such as a database, can be put directly into the application at startup. This can be done by configuring the Terminal server client through the Client Connection Manager to automatically initiate a specific application for the user. A preconfigured Terminal server client can be distributed to a group of users within a group to give them the same direct application. If a Terminal server will be used to deliver a single application to anyone allowed to connect, the server can be configured to automatically initiate that application upon logon. This is done using Terminal Services Configuration.
You can also allow users to connect without entering a user name and password. You can also do this on a per user basis through the Client Connection Manager or on a per server basis through Terminal Services Configuration or the User Manager extensions. Generally, you should plan to use this connection method only when users are logged directly onto a line-of-business application, especially when the application itself requires a password for access. Use this server feature with care because it means that anyone with a Terminal Services client can log on to the server.
Windows 2000 offers a secondary logon capability. This function is used primarily to allow users to execute applications using a different security context. It is valuable in a Terminal Services environment, where the client computers automatically log on with a basic user account and the current user wants to execute an application that requires a higher level of security. In this situation, you can use the runas command to start applications under a different context without having to log off the user.
You can enter the runas command from the command prompt or it can be incorporated into an application shortcut. After a shortcut to an application is created, the runas functionality can easily be incorporated into it by selecting the Run as different user in the Properties option of the shortcut. This prompts the user for the Windows 2000 domain user account and password prior to executing the application.
When a user logs on to the system, Terminal Services executes a batch file called UsrLogon.cmd in the System 32 directory. This file makes any necessary modifications to the user environment and ensures that users can run their applications correctly. If Terminal Services modifications to the user environment are necessary, you can make them by editing this file. Be aware that by editing this file you might cause a problem with the application compatibility scripts that are executed from this batch file.
In your logon scripts, consider checking for the presence of the environment variables
You can assign data transfers between the Terminal Services client and server at one of three different levels of encryption. Note that high encryption is available only in North America.
With low encryption, traffic from the client to the server is encrypted using the RC4 algorithm and a 56-bit key (40-bit key for RDP 4.0 clients), whereas traffic from the server to the client is unencrypted. Low encryption protects sensitive data like password entry and application data. The data sent from the server to the client is screen refreshed, which is difficult to intercept even when unencrypted.
With medium encryption, traffic in both directions is encrypted using the RC4 algorithm and a 56-bit key (40-bit key for RDP 4.0 clients).
Traffic in both directions is encrypted using the RC4 algorithm and a 128-bit key in the North American version of Terminal Services only. In the export version of Terminal Services, high encryption uses RC4 and a 56-bit key (40-bit for RDP 4.0 clients).
When planning security for Terminal Services, consider the following:
Smart Cards The Windows 2000 interactive logon has the ability to authenticate a user with the Active Directory network using an X.509 version 3 certificate stored on a smart card along with the private key. However, this feature is not available to users authenticating by means of Terminal Services. This also applies to other hardware-based authentication devices.
Network and Communications Security Remote Access does not limit access to Terminal Services users, so if one user establishes a modem or VPN link to the Internet or another system, every user on Terminal Services has access to the link.
Information Services on Terminal Services You need to disable anonymous File Transfer Protocol (FTP) to prevent unsecured access to the file system.
Removing Services That Are Not Used Removing the IBM OS/2 and POSIX subsystems prevents users from executing OS/2 or POSIX applications that circumvent security regulations. For more information about ensuring your system's security, see "Planning Distributed Security" in this book.