Windows Server 2003/2000 Terminal Server Solutions, Third Edition, Implementing Windows Terminal Services and Citrix MetaFrame Presentation Server 3.0

BEFORE YOU BEGIN

1. Physical access — Physical access to your Terminal Server (and associated server hardware) should be restricted as much as possible to only the people responsible for managing the Terminal Server environment.



2. Administrative delegation — Before any other security considerations can be addressed, a decision must be made as to who will have administrative authority over the Terminal Server OU and all servers that reside within this OU.



3. User authentication — Almost all Terminal Server implementations have some form of user authentication to verify that a user is who they declare themselves to be. The most common form of authentication is the combination of user ID and password. In most organizations, this is also typically the weakest and most vulnerable of the security layers.



4. User authorization — Unlike user authentication, which deals with verifying identity of a user, user authorization deals with regulating what users have access to log on and what server resources they can access. Just because a user is who they say they are does not necessarily mean they are authorized to access the resource they are attempting to use.



5. System privileges and restrictions — Once an authorized user has logged on to the Terminal Server, their ability to interact with objects on the server is managed through user rights, security restrictions, and administrative templates. These three components work in combination to limit a user's access to only those components of the server pertinent to their job function.
6. Application privileges and restrictions — Usually access to the applications on a Terminal Server should be restricted to a subset of users based on their job function. For example, administrative applications are available only to administrators, while accounting-related applications should be accessible only to the accounting staff.



7. System auditing — Once you have implemented the desired security configuration for your Terminal Servers, you need a means of monitoring effectiveness of the configuration and flagging suspicious activity when it occurs. System auditing is an important part of any secure environment but is of little use unless an effective means of monitoring the logged information is also implemented.



8. Security patch management — A critical part of any secure environment is the timely deployment of all appropriate security patches. Poor patch management can be particularly damaging to a Terminal Server environment, since many of the exploits released into the wild specifically target end users and impact common applications such as Outlook or Internet Explorer. While a properly secured server normally limits the effects a user can have on stability of the server, some exploits can specifically target privilege elevation, effectively granting administrative access to the user's session and allowing a malicious program to cause system-wide problems. In Chapter 9, "Service Pack and Hotfix Management," I discussed security patch management in detail.

PHYSICAL ACCESS

1. Store servers in a room closed off from general staff traffic and accessible only with some form of card or key authentication.



2. If necessary, lock the servers in their own rack or shelving device accessible only by valid Terminal Server administrators.

ADMINISTRATION DELEGATION

Terminal Server Domain Group Creation

Delegating Organizational Unit Authority

• Account Operators
• Authenticated Users
• Domain Admins
• Print Operators
• ENTERPRISE DOMAIN CONTROLLERS (Windows 2003 Active Directory only)
• SYSTEM
• Terminal Server Administrators

Managing Local Group Membership

• Terminal Server Operators — Used to assign a subset of administrative privileges to those users responsible for managing the day-to-day operations of the Terminal Server. For example, members of this group would have the ability to terminate processes or restart the Terminal Server but would not have the ability to install/remove applications or modify configuration of the server.
• Terminal Server User Support — Used to assign privileges to those users who would perform typical user support functions. Among other privileges, members of this group would have the ability to shadow other users — something a regular user can't do.

@ECHO OFF
REM Create the desired local groups on the Terminal Server
net localgroup 'Terminal Server Operators' /add
net localgroup 'Terminal Server User Support' /add 

• Administrators — Members of this group will have full administrative control over the Terminal Server. Because of this, access should be very tightly controlled.
• Terminal Server Operators — This group name is used to assign a subset of administrative privileges to those users responsible for managing the day-to-day operations of the Terminal Server.
• Terminal Server User Support — Those users responsible for performing typical user support functions such as shadowing or session logoffs would be members of this group.
• Remote Desktop Users (Windows Server 2003 only) — To remotely log on to a Windows 2003 Terminal Server, a user must be a member of this existing local server group.
• Users — All regular users who require access to run one or more applications on the Terminal Server are assigned to this local group.
• Power Users, Guests — These two groups are included in the Restricted Groups policy to ensure that no users are members of either of them.
• Anonymous (MetaFrame servers only) — When MetaFrame is installed on a Terminal Server, it adds support for anonymous logons through the special Anonymous group. Just as with the Power Users and Guests groups, this group is included in the Restricted Groups policy to ensure that no users belong to this group. Of course, if your MetaFrame server will allow this type of support you will need to omit this entry from the GPO.

  PRODUCTION\Terminal Server Operators            

USER AUTHENTICATION

• A blank password or no password at all.
• Some variant of the word password.
• A password based on the user's name, their spouse's name, or some other common dictionary word such as bird, tree, snow, monkey, dog, and so on.
• A password based on a user's phone number, home address number, birthday, an so on.

• Dictionary attacks — Common words found in the dictionary are used to try to quickly match user passwords.
• Targeted-word attacks — A customized dictionary of specific words is used to try to determine the user password. Custom dictionaries are usually created based on information gathered either through social engineering or other means of personal information acquisition and typically target a specific user or group of users.
• Brute-force attacks — Every possible combination of characters is used to try to discern the password. In many cases the dictionary and brute-force attacks are integrated to try to find quick hits. With sufficient time, a brute-force attack will determine any password. Of course, the complexity and length of a password determine whether such an attack can discover a password in a realistically finite amount of time.

• LC5 — The latest version of the famous L0phtCrack password auditing and recovery tool. Different variants of this product are available to be purchased, with the high-end product offering a number of different password-cracking techniques such as brute-force, dictionary attacks and pre-computed password tables (also known as rainbow tables). Trial versions used to be available for the product, but at the time of this writing, the latest version did not offer a trial version. The Website is http://www.atstake.com/products/lc/
• Cain & Abel — A robust and powerful password recovery tool, Cain boasts an astounding array of features, including a number of different network packet filtering options. Best (or worst) of all, this tool is completely freeware. The product can be found at http://www.oxid.it/projects.html.
• Sarca Rainbow Tables — An online Web site that allows you to paste LanManager and NT password hashes onto the site and submit them for cracking using their generated rainbow tables. The site only processes hashes once per day but can crack a large number of passwords. Limitations on the actual processing are discussed on the site. http://sarcaprj.wayreth.eu.org

Account Password Policies

• Enforce password history — To counteract the tendency of users to reuse the same password (or small set of passwords) over and over, this policy ensures that a specific number of unique passwords are used before a user's oldest password can be reused. By default this option is set to the maximum of 24 passwords remembered in a Windows 2003 domain.
         A possible side effect of enforcing a lengthy password history is that users may start maintaining a paper record of their password to help them remember what they are currently using. The two most effective ways to counteract this are through the proper education of secure computing practices and the use of a suitably long maximum password age (described next) to allow the user time to learn the password before the system once again requires them to change it. My preference is to use the maximum value of 24 in all production Windows domains whenever possible.
• Maximum password age — The longer a user is allowed to retain the same password, the greater the chances that the account may be successfully cracked or accessed by someone who may already have the password to the account. Periodically forcing a user to change their password helps minimize these risks. A Windows 2003 domain has a maximum password age of 42 days, which most administrators find to be an optimal medium between frequent password change requirements and adequate password aging.
         Similar to enforcing a large password history, requiring users to change their passwords too often will likely result in at least some of the users keeping a paper record of their current password, often in an easily accessible location (taped to the monitor, under the keyboard, and so on). I highly recommend not setting the maximum password aging to zero (0) but instead using the default of 42 days.
• Minimum password age — Complimenting the maximum password age policy is the minimum password age policy. This policy defines the minimum number of days a user must use the same password before it can be changed. The main reason for this policy is to ensure that users do not attempt to quickly change their password multiple times in order to reuse a desired password, effectively circumventing the "Enforce password history" policy.
         Windows 2003 defaults to a minimum password age of one (1) day, meaning that a user can change their password only once per day. This policy does not prevent an administrator from resetting a user's password.
• Minimum password length — An adequate password length is critical to ensuring that user passwords remain secure by minimizing the effectiveness of bruteforce attacks. Each increase in the minimum password length by one character exponentially increases the number of possible password permutations. Using only the standard characters on the keyboard, users have 94 possible characters to choose from when selecting their password. These 94 characters are comprised of 52 alphabetical characters (uppercase and lowercase), 32 additional characters (#, $, *, @, etc.), and 10 numeric characters (0, 1, 2, 3, etc.). When the minimum password length is 7, the user can choose from 947 (approximately 64,000,000,000,000) possible different passwords.
         Of course, as the password length increases, so does the risk that a user will be unable to remember the password they are using. Windows 2003 defaults to a minimum length of seven characters, and I recommend that passwords use at least this many characters.
• Password must meet complexity requirements — Even with all these password requirements in place, education alone will not ensure that the end user consistently selects a strong password. Without some means of ensuring that a minimum level of strength is being used, the users are likely to pick the simplest password possible that complies with the policies in place.

• Store passwords using reversible encryption — In most situations, this policy should never be enabled because it forces Windows to store passwords in such a way that they can be decrypted. This is inherently much weaker than the standard method of one-way encryption and provides an attacker with an additional means of compromising one or more user accounts.

Account Lockout Policies

• Account lockout duration — This policy determines the amount of time a user's account remains disabled until it is automatically re-enabled by the system. I typically recommend that the duration be set to zero (0) in order to minimize the number of brute-force or dictionary-based attempts that can be performed against a user account before an administrator's intervention is required. When set to zero, an account remains locked until manually unlocked by an administrator.
         The one thing to consider when setting the lockout duration to zero is that a user cannot log on until an administrator manually re-enables the account. To minimize the chances of a user legitimately locking themselves out, settings for the other two account lockout policies must be set accordingly, as discussed in the following points.
• Account lockout threshold — The lockout threshold represents the number of incorrect password attempts allowed before a user's account is disabled. One factor influencing this value is the lockout duration you configured for your environment. If the duration is set to zero (0), the lockout threshold can typically be assigned a value of 10 to 15. In most situations a user is not likely to repeatedly try their password this many times within the account lockout reset interval (see the following point).
• Reset account lockout counter after — This setting dictates the amount of time that must pass before the lockout counter is automatically reset to zero. A value of 30 minutes is usually appropriate for most environments.

CONNECTION AUTHORIZATION

• LOCAL SERVICE — This is a special built-in user account that has the same privileges as a member of the local Users group. This account has very limited access to network resources, presenting only null session information with no user credentials when prompted by a remote system. This account exists to make it easier for an administrator to grant limited privileges to services that require only local access on a server. By default this account has permissions to send text messages to all RDP protocol users on a server.
• NETWORK SERVICE — This built-in account also has privileges equivalent to a member of the local Users group. Where this account differs from the LOCAL SERVICE account is in the network privileges it has been granted. When prompted by a remote system for network credentials, this account sends the computer's account credentials.
• Remote Desktop Users — By default, a user requires membership in this local group in order to log on to a Windows 2003 Terminal Server. The appropriate connection privileges and local user rights are all preconfigured for members of this group.

• Reset (Windows 2000 only) — This attribute grants the user the ability to reset any RDP connection to the server. A reset forces the connection to be terminated and the resources allocated to be immediately freed. Unlike the execution of the Logoff command (controlled using the Logoff privilege; see the third point in this list), this does not send the Windows logoff message to the session's running applications, allowing them to terminate. If a user has an application open and their connection is reset, any unsaved data is likely lost.
• Remote Control — This attribute grants the user the ability to remotely control (or shadow) another user's session. The specific remote control permissions are discussed in Chapters 19 and 20, where I discuss connection-specific settings for both the RDP and ICA clients.
• Logoff — This attribute lets a user log off another user's session just as if that target user had themselves selected Logoff from the Start menu. All running applications receive the Windows logoff message, allowing them an opportunity to cleanly shut themselves down before the user's session is terminated.
• Disconnect — Instead of being logged off, a user can also be disconnected. This simply terminates the presentation connection between the client and the server but leaves the running desktop session active on the Terminal Server. Any running applications continue to run and be available if the user reconnects before the session is terminated by an administrator or automatically logged off by the system. Maintaining disconnected sessions on a server for long periods of time is usually discouraged because maintaining the state information consumes additional server resources.