Server Security

To adequately analyze server security in Terminal Server environments we must divide the servers into their multiple roles and look at the security of each role separately. We'll examine each of the following Terminal Service environmental roles:

• Terminal Server application hosts.

• Terminal Service licensing servers

Terminal Server Application Server Security

Since the actual user sessions are executed on the Terminal Servers, they figure greater into a discussion of security. The basic actions to consider when securing your Terminal Servers are:

• Using the NTFS file system.

• Configuring NTFS file permissions.

• Using GPOs to secure the user environment.

• Installing Terminal Services on a domain controller.

• Disabling the "Secondary Logon" Service.

• Remove unnecessary software

• Applying hotfixes and service packs.

Use the NTFS File System

Each user that runs a session on a Terminal Server is essentially running a remote control console session. Without an NTFS file system, you won't be able to set any file-level security permissions. Any user that is logged would be able to access files in use by other users. No mechanism would prevent users from deleting key system files, potentially crashing the server!

There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an RDP session, even if his client is running on an operating system that cannot support NTFS, such as Windows 95.

Configure NTFS File Permissions

Using just the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your Terminal Servers or plan to run only initial applications, you should secure the basic file system.

When you install Terminal Services on a Windows 2003 server, you're asked whether you want to use "Full Security" or "Relaxed Security." (These options were known as "Windows 2000 Security" or "Permissions Compatible with NT 4.0" on Windows 2000 Terminal Servers.) This security setting has nothing to do with your domain configuration or your Active Directory environment. It affects only the level of security that users are given when they access your server via a Terminal Services session. To compare the two settings:

• Full Security. This setting results in Terminal Services users having the same permissions as regular members of the local users group. Regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this level of security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose Full Security, you should thoroughly test your applications before enabling them for any users.

• Relaxed Security This setting results in Terminal Services users having full access to many parts of the registry and many of the system files. This alternate level of security was developed to allow older applications to execute properly.

After selecting the "permissions compatibility" mode during the installation of Terminal Services you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:

Key: HKLM\System\CurrentControlSet\Control\Terminal Server\

Value: TSUserEnabled

Type: REG_DWORD

Data: 1 = Relaxed permissions. 0 = Full Security mode.

Do Not Install Terminal Services on a Domain Controller

Individual domain controllers cannot be managed separately from each other. In order for a user to be able to log on to Terminal Server sessions she must have "log on locally" (called "log on interactively" in Windows 2000) rights. If the Terminal Server is a domain controller, granting the user "log on locally" rights on the server will allow her to log on to any domain controller, even ones that are not Terminal Servers.

Also, domain controllers in Active Directory environments must be located in the "Domain Controllers" OU. You can't use OU-based Group Policy Objects if your Terminal Servers are installed on domain controllers.

Lastly, several security holes are associated with the operation of the Local System Account on domain controllers. In order to have a secure environment, never let log on to a domain controller. Installing Terminal Services on a domain controller makes it difficult to follow this recommendation.

Disable the "Secondary Logon" Service

Windows 2000 introduced a secondary logon ability (then called the "Run As" service) which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select "Run as..." from the context menu. Alternately, a user can enter the "runas" command into the command line.

Administrators often lock down Terminal Servers for those groups of users that should be using them. The secondary logon ability allows a user who's already connected to a Terminal Server to change his credentials, potentially bypassing any security measures the administrator has configured. (If you read the rest of this chapter, you'll know better than to build servers that exhibit this weakness.)

The secondary logon ability can be disabled at the server by stopping and disabling the "Secondary Logon" service. Disable the service after you stop it, or the system will start it again when it is needed.

Remove all Non-Essential Software

Any extra applications installed on your Terminal Servers represent an increased security risk. Each installed application brings introduces more vulnerabilities. Access to extra tools, (such as those included in the resource kits) makes compromising or abusing the server easier. You shouldn't give your users more than they need to do their job.

Apply Service Packs and Hotfixes

As in any computer environment, maintaining security requires that you frequently check for new hotfixes that address security issues, even if you already keep your servers up to date with the latest service packs.

Check for new hotfixes from Microsoft and from any other third party vendor (like Citrix or New Moon) at least once a week. Because history has shown that neither Microsoft nor these other vendors have a perfect track record for creating bug-free hotfixes, you should also check with an online discussion group (see www.brianmadden.com for details) to see if there are any issues surrounding newly released hotfixes.

To help maintain your hotfix environment, Microsoft has released at security hotfix checker utility (detailed in Microsoft Knowledge Base article 303215). This utility allows you to quickly and easily check the status of hotfixes on multiple servers.