Security Standards for MFCF Windows 2000 Terminal Servers

This document outlines standard file system, registry and network security measures implemmented on all Windows 2000 Terminal Servers installed and managed by MFCF.

System drive (D:) and folder security modifications
As outlined in our MFCF Windows 2000 Terminal Server Build document, the entire Windows system is to be found on the D: drive for all our Terminal Servers. In fact the notes which follow here are excerpts from that very document.

Folder permissions in Windows 2000 are inherited from the parent folder by default. This process follows up all the way to the permissions set on the root of the logical drive. However, as a rule each of the top level folders on the system drive (D:) will not inherit permissions from the D: root. This is due to the fact that each folder's purpose is unique. In particular Temp and UserProfileCache must have special permissions to allow users to add and modify files.
Here we will specify the permissions applied to the root of the system drive (D:) and its imediate list of subfolders. Some of the permissions listed below may appear redundant. When the system is installed Windows provides some greater rights to special user groups such as TERMINAL SERVER USERS and Power Users. These rights have been reduced to simple Read and Execute. It is policy that non-administrative users have no rights to modify the system, the registry or any common software. They only have the right to affect materials which belong to them. The result is a fairly uniform permission structure for the possible exception of the D:\Temp directory.

D:\

D:\Local D:\Program Files D:\Regional D:\software D:\Temp D:\UserProfileCache D:\WINNT (*) Traverse Folder, List Folder, Create Files and Create Folders. Thus Authenticated Users may create files and folders for themselves. These items can be modified and deleted by the creating user and are not accessable to other users (expect the SYSTEM and Administrators).
(**) The SYSTEM caches the user's profile in D:\UserProfileCache not the user however since the profile is owned by the user the CREATOR OWNER permission gives the user Full Control of his profile folder within D:\UserProfileCache
(***) The use of CREATOR OWNER is handy on all folders since it will add the creator's/installer's id to the permission list of any new file or folder. This is a handy mechanism for determining which administrator installed what file.

Special Case of a User Retaining Personal Disk Space on the System
In some rare cases, a user may have some perminent personal disk space maintained on the local system as well as his mounted network disk space. The goal here is to create a folder for this user in which the user owns the contents of the folder but not the folder itself. That is, the user my create, modify and delete files and subfolders within this space however he can not move, rename or delete the folder itself. To accomplish this the Advanced... button must be used to set the folder permissions. Permissions for the folder are then assigned through the advanced editor as follows.

TypeNamePermissionApply To
AllowAdministratorsFull ControlThis folder, subfolder and files
AllowUsername of Folder OwnerFull ControlSubfolders and files only
AllowUsername of Folder OwnerSpecial Access(*)This folder only
AllowSYSTEMFull ControlThis folder, subfolder and files

(*) In this case Special Access means Full Control, take away the following privalages.

Registry Security Modifications
All the registry keys come with a set of default permissions to protect them. This situation is much like the file system after a fresh install. However, the default security on the registry has serious holes which are dangerous on a system used by as many as 1000 different students per week. These holes in the security exist for one of two reasons.

  1. By design. A Terminal Server is suppost to allow users to install their own software for their own purposes. These are called local or personal applications. - as opposed to common applications. In many cases though an application must register components to be run by the system. Thus CLSID keys need to be created in the HKCR hive. HKCR is a commonly accessed area of the registry. New keys may also be required in the HKLM hive.
  2. For software compatibility. Some Windows based applications do not create all required registry keys during the installation process. Some "re-create" these registry keys (as many as a hundred in some cases) when the application is run by the user. On an unprotected system, such as with Windows 95, this is an effective measure for ensuring the integrety of the keys upon which these applications depend. However registry errors can occur for a user if he does not have modification rights on these keys under Windows NT or Windows 2000
For us, allowing users to register their own software components is not desirable. Registered components are run under the SYSTEM authority once the server is rebooted. SYSTEM authority is the highest authorization level on a Windows server and not even administrators are given it. If such components are run at that level then they have full access to all server resources (even personal ones). If they turn out to be viruses or hacker traps then the system if effectively compromized.
Further, applications are not written specificly for the Terminal Server environment. These are usually PC applications which were created under the assumption that they would be used on a single user, single interface console and not on a multi-user, thin-client server. During installation, an application may make general changes which can have an undesired effect on other users - such as unexplained icons on everyone's desktop.

In order to balance system stability and security with the practicle matters of compatability we have targeted certain strategic keys that when secured will effectively protect the registry. This coupled with a general policy of not permitting the users to access the registry editors seems to have prevented all forms of virus attacks, accidents and mischief. This is by no means as good a "lock down" as the file system but it is a happy meadian for the time being. As better registry monitoring/editing tools appear this procedure will be refined. The keys in question are as follows.

Registry key permissions in Windows 2000 are, like the file system, inherited from the parent key by default. This process follows up all the way to the permissions set on the hive root (HKLM, HKCU or HKCR). In every case above the idea is to keep the Special access permissions for subkeys but reduce access to simple Read on the keys themselves. Hence user can not create their own subkeys at important levels of the registry but still retain their freer access at less sensitive levels. The Advanced permissions editor permits this by allowing permissions to be inherited by all subkeys and yet not applied to the key itself. You may then create a new Read Only entry for TERMINAL SERVER USER or Power User which does apply to the key itself. The permissions should read as outlined below.
(*) Special permission, in this case, refers to the following permission attributes. Query Value, Set Value, Create Subkey, Enumerate Subkey, Notify, Delete, Read Control.
(**) Read permission, in this case, refers to limited permission attributes. Query Value, Enumerate Subkey, Notify, Read Control.

Network Security Modifications
Windows 2000 Standard and Advanced Servers come with what can be described as a built-in firewall service. It is a mechanism which, amungst other things, can allow an administrator to pick and choose what network locations (IP addresses and ports) may connect to the server or specific ports on the server. This is particularly useful if you desire to limit which specific terminals may connect as terminal server clients. This feature is the IP Security Policy in the Local Security Policy admin tool. The methods involved in defining a local network security policy are outlined in the MFCF Windows 2000 Terminal Server Build document.

Network Ports for Terminal Services Client Connections

Access to the above ports are controlled on a client-by-client basis. For example, if a connection request is made to port 3389 from an unauthorized IP address (an RDP client that is not known to be licensed or not authorized for access by the administration) then the connection request is ignored. If the IP address represents an authorized client then the connection is permitted.

Network Ports that Require Special Control

These are network ports used for system information exchange. Such exchanges are file and printer sharing, user authentication and comunication between Windows 2000 and Windows NT systems. Unfortunately, they also may be attacked from outside our networks to gain system and user information which should remain private. These ports could also be attacked in order to break these system services (DoS attack). We wish to make use of these ports locally however there is no need for systems off of campus to access them. Thus we will cause all queries that are not from on campus (129.97.*.* in our case) to be ignored by the server. Except for the case of the SNMP ports where we have chosen to be more restrictive. We require that all queries to SNMP ports must come from our local management subnet (MFCF-net) otherwise the connection request is ignored.

(*)Windows Universal Plug and Play (UPnP) is listed here for future concerns involving Windows XP Terminal Servers. Windows 2000 does not come with UPnP. When XP Terminal Servers become more common, if UPnP is used it will be restricted to on-campus connections only.

Shared Folder Security Modifications
At the present time we have no security standard for permanent shares on MFCF Terminal Servers. The file permissions associated with any shared folder are usually sufficient to protect the contents from unauthorized access (or modification). In addition, the default drive root shares (C$ and D$) are set for administrative access only by the SYSTEM at start up.

Local User Groups and User Rights
The most important purpose of this section is to provide an easy mechanism for selecting which users may log in to a Terminal Server. To this end we create a new local user group called Local Accounts. The membership of this group is limited to accounts on the local system which are permitted to login to the Terminal Server. Usually, these accounts are the local Administrator and one test user account.
Then in the Local Security Policy tool Logon Locally rights are granted to the Local Accounts group. At this time Logon Locally rights are removed for the Guest account and the Users group. Once the server is installed and in production Logon Locally rights may be granted to other local (or domain) groups as desired by the server's administrator.

This page was last updated on Wednesday, the 13st day of February in the year 2002 AD.
Contact Clayton Tucker for questions or comments.