Securing a Windows 2000 terminal server

When I was creating an online library for my students, I decided to use Windows 2000 Server Terminal Services to give them access to research material. Unfortunately, I discovered that this solution creates security problems because Terminal Services treats users as if they were logged on locally to the computer. The challenge was to find a way to control access to the system while still making resources available.

Overview of Terminal Services
Terminal Services lets users log on to a remote system as if they were logging on locally. The Terminal Services client program, which runs on any version of Windows, redirects the local keyboard and mouse and emulates the remote video display. To users, the session looks exactly like they're sitting in front of the remote computer.

The main benefit of Terminal Services for my situation is that I can give my MCSE students access to both Win2K and applications running under Win2K without requiring them to install that OS or the applications on their computers. With this solution, not only can my students avoid buying new hardware, but also I can centralize installation and administration and minimize my administrative overhead.

Terminal Services can operate in two modes: Remote Administration mode and Application Server mode. Remote Administration mode permits up to two concurrent sessions for management of the server, which lets you use the server without having to be sitting at the keyboard. In contrast, Application Server mode permits multiple concurrent sessions that share the server's hardware but provide individual environments and desktops. I use Application Server mode to let multiple students use research software.

You set security for Application Server mode the same way you would if the server had multiple users who could log on locally. The main difference between local users and Terminal Services users is that many Terminal Services clients can use the system at the same time. Otherwise, you need to secure the system for Terminal Services clients by using the techniques you would use to secure a system that had multiple accounts with Log on locally privileges.

I took a three-phase approach to securing my server. First, I control access to the server through Win2K domain accounts. Second, I control access to the hard disk through NTFS permissions. Third, I control what users can do on the system through profiles and Win2K Group Policy Objects (GPOs). This combination of approaches lets me tailor the list of tools to each student's needs while limiting the damage students can do to the system if they make a mistake.

Securing the Hard Disk
Because securing the hard disk is the most straightforward piece of the puzzle, let's tackle it first. The key to this phase is recognizing that Terminal Services users are members of a special local group named Terminal Services Users. Users in this group become members automatically upon logging on to the system through Terminal Services. (Note that Interactive and Terminal Services Users groups have mutually exclusive membership rules. No user can be in both groups at the same time.)

Users retain membership in all their other groups; therefore, they gain the cumulative rights and permissions granted to all the groups as a whole. By default, membership in the Terminal Services Users group means that all Terminal Services users are also in the Domain Users global group, which in turn means that they're also members of the Users local group on the terminal server itself. (Note that although I implemented a domain-based solution, you could substitute local accounts for domain accounts.) Unlike Windows NT, which assigns the Everyone local group Full Control permission to all objects on a new NTFS partition, Win2K limits access to sensitive areas of the hard disk through permissions assigned to a standard set of groups. The end result is that the Users local group has only Read and Execute permissions to all folders except those specific to a given user, such as the Documents and Settings folder and its contents.

In a typical Win2K server installation, the Power Users local group doesn't have any members and has Modify permission on all folders except the Documents and Settings folder. On servers running Terminal Services, the Terminal Services Users local group duplicates the permissions for the Power Users local group. The main exception is the Windows system folder, to which the Power Users local group has Read and Execute permission and the Terminal Services Users group has no permissions assigned. Where the Terminal Services Users group has no permissions, the permissions assigned to the Users local group apply. Figure 1 shows the top-level folders' permissions for a new installation of Win2K Server with Terminal Services installed.

The end result is that each Terminal Services user can see only the contents of his or her own folder in the Documents and Settings folder, can only read and execute files in the Windows system folder, and can modify files in the Program Files folder. Because subfolders are set to inherit permissions from the parent, Terminal Services users must have Modify permissions throughout the Program Files folder, which means that by default, Terminal Services users can modify or delete application files.

The Program Files folder, therefore, is the place to start securing the server's hard disk. I took advantage of the fact that all the Program Files folder's subfolders inherit the permissions granted to the Program Files folder and simply granted the Terminal Services Users local group Read and Execute permission instead of Modify permission. In my tests, Terminal Server clients could run applications but couldn't modify application files.

The one situation in which this solution doesn't work is when the application needs to update files stored in the application's folder, such as configuration files or temporary work files. The workaround is to grant Modify permission to the Terminal Services Users local group just for the application's folder. Because of the permission inheritance, you must change the permissions on the application's folder after you change the permissions for the Program Files folder. I also recommend that you make a note about this setting somewhere, because you're overriding the value that will be inherited from the top-level folder. Administrators following behind you need to know that the system deviates from the default settings.

Storage for User Files: Hard Disk
You can store documents that users create with applications such as Microsoft Excel and Microsoft Word in the user's profile folder in the Documents and Settings folder, in which users have Modify permission on all files and subfolders. Note that because users have Modify permission and ownership of the files and subfolders, they can change permissions to prevent administrators from viewing the contents of their personal directory. The workaround to this situation is for you to take ownership of the file or folder, then reset the permissions accordingly. Whether this situation arises depends on your company's policies, but you need to know how you can fix a problem if a user accidentally changes permissions incorrectly.

Some programs want to create a new folder in the Program Files folder and store application-created files in a subfolder. The drawback to this action is that you need to grant Modify permission to the folder that holds the data files. Fortunately, users access programs by using shortcuts stored in the Start Menu folder of each user's profile or in the All Users profile, which contains profile information that applies to all users. For programs such as Microsoft Visual Studio (VS), you can change the Start in property of the shortcut to point to the user's profile folder. When users save files, they'll see their profile folder as the default location for those files.

One trick I discovered is that you can use the %username% folder option in shortcuts to adjust the Start in property based on the user's account name. For VS, I simply changed the Start in property of the VS 6.0 shortcut to C:\documents and settings\%username% to make the user's profile folder the default folder. For Terminal Services users, this adjustment is an easy way to handle multiple users with a minimum of administrative overhead: Changing a shortcut in the All Users profile changes that shortcut for all users.

Storage for User Files: Other Options
So far, I've limited our discussion to the hard disk on the server running Terminal Services. However, two other important options are roaming profiles and shared folders.

Roaming profiles store the contents of the user's profile directory on a domain controller (DC); Win2K copies the files to the local computer when a user logs on, then copies the files back to the server when the user logs off. This option is good for Terminal Services users in an environment in which they log on to multiple servers because their environment settings and data files can follow them wherever they log on next. This option is also good for administrators because user files stay on a central server where you can easily back them up. The only drawback is that users must copy the entire contents over the network at logon and logoff, which can take some time if the files are big. For most users, however, this process isn't a significant enough inconvenience to deter implementation in multiserver environments.

The second option is to use shared folders for users' home directories. The benefit of this option is that the files stay on a file server and users copy the contents of a file only when they need to work on it. The shared folders option is much more efficient than roaming profiles for users who work with large files such as digital images, audio, or databases (e.g., Microsoft Access databases). However, this option has a couple of drawbacks. First, the Terminal Services Users local group exists only on the server running Terminal Services. Because this group is a local group, other servers on the network have no access to it; therefore, you can't use this group to control file access on shared folders.

You also need to configure appropriate share-level and NTFS permissions for each user's folder. If you created the shared folder before you used the %username% option to set the user's Terminal Services home directory, the Microsoft Management Console (MMC) Active Directory snap-in will automatically create the home directory and set the permissions to Full Control for administrators and Modify for users, just like the profile folder. Be sure to grant the Domain Admins global group Full Control share-level permission and the Everyone local group Change share-level permission. Lower-level permissions prevent the Active Directory snap-in from doing its work and prevent Win2K from using the shared folder as the user's home directory.

Using home directories in combination with the My Documents folder in the user profile can be confusing. Some programs decide which folder to show as the default by checking to see which one has files with extensions associated with the application, which means each application can have a different default. Other programs just ignore the My Documents folder and the home directories altogether. Users might have their files split between both My Documents and their home directories. Because too many possibilities exist to cover here, I leave it up to you to determine the best option for your environment.

Securing the Environment
In addition to securing the server's hard disk, you also need to secure the desktop environment. Because I'm providing my students access to certain research tools, I felt it was necessary to limit access to the system significantly. To do that, I used a GPO.

Figure 1 shows the GPO settings for the policy that Win2K applies when a student logs on. The main goals were to

  • Eliminate access to the internal network
  • Limit the damage someone could cause by either accidentally or deliberately changing settings
  • Limit the programs a user could run
  • Curtail access to the Internet through my server

The NTFS permissions I've discussed so far help a little in meeting these goals because they limit the programs a user can run and the files that those programs can affect. In fact, if you allow your users Internet access, these permissions can also prevent some viruses and Trojan horses.

Because my server is supposed to run only class-related programs, I wanted to make sure that none of my students could disrupt the other students' research time. Thus, I needed to make sure that students could run only approved programs, that they weren't using an excessive amount of memory or CPU time, and that they didn't place anything on the server that other students might consider offensive. I also didn't want the students to be able to browse my internal network.

Related Reading
If you haven't had an opportunity to use Group Policy Objects (GPOs), which are available only in Windows 2000 domains, check out the explanation in the Microsoft Windows 2000 Server Resource Kit. GPOs are the replacement for Windows NT 4.0's policies, and they offer a broad range of choices for managing computers and users' environments. (Note that the GPO in Figure 1 doesn't configure computer settings because I chose to manage my Win2K Server Terminal Services servers' settings with a separate GPO.)
A combination of user profiles, user rights, and the GPO let me meet those goals. The user profiles let my students keep some user-specific information (e.g., bookmarks, practice exam results, programs they've written) between logons. The GPO contains the user rights and desktop settings, which let me control access to the Run menu and control modifications to the Start menu and Taskbar, the desktop, and the system configuration settings found in Control Panel. The GPO also lets me disable access to Microsoft Internet Explorer (IE). As it turns out, because one application lets users type in a URL, I had to enable IE's Content Advisor feature to make sure students weren't accessing anything other than a list of permitted sites. For a GPO resource, see "Related Reading."

Take Time for Security
Securing a Terminal Services server offers some challenges that many administrators never face because most desktop systems in use today have just one user. You can effectively secure the desktop system's hard disk by controlling who can log on locally and who has access across the network. Terminal Services servers, however, have multiple users logged on as local users at the same time. To manage security effectively, you need to use a combination of NTFS permissions, user profiles, user rights, and desktop settings. You'll need some time to get all these options to work together correctly, but that time is necessary if you want to grant users no more access to the system than they need and no less than they require.