Security Policies for Terminal Servers

Local security policies or certain areas of the Group Policies are used to configure the security settings on an individual computer. These settings include password policy, account lockout policy, audit policy, IP security policies, user permission assignment, software restriction policies, and other security options. The local security settings can be found in the Start menu under Administration\Local Security Policy, and they exist only on computers that are not domain controllers. If the computer is part of a domain, these settings might be overwritten by Group Policies. (See also Chapter 4.)

Note  

If you call up the local Group Policies with Gpedit.msc, the Computer Configuration\Windows Settings\Security Settings corresponds to the Local Security Policy tool that can be opened under Start\Administrative Tools\Local Security Policy.

Naturally, the Terminal Services-specific settings of the security policies play an important role for terminal servers and their users. This is why we will take a closer look at them now.

Figure 8-4: Security settings through the Local Computer Policy.

Account Policies

The account policy security settings apply to user accounts and contain attributes in the following categories:

• Password Policy Determines settings for passwords for local or domain accounts. Comprises password history, complexity requirements for passwords, encryption options, maximum and minimum password age, and minimum password length.

• Account Lockout Policy Determines conditions under which a local or a domain account can be locked to certain users. Comprises the number of invalid logons after which the account is locked, the duration an account is locked, and the option for resetting the account lockout counter after a preset time has passed.

• Kerberos Policy Determines Kerberos- related domain account settings. Comprises, for instance, the validity period of Kerberos tickets.

Of course, no one can establish a universally applicable standard for all kinds of terminal server environments. However, it has proven beneficial to enforce a minimum password length of six characters and to require compliance with password complexity. This is done when enabling the Password by following the complexity requirements policy found under Password Policy. It is also recommended that the Account lockout threshold in the Account Lockout Policy be increased from 0 to 3. This also enables you to set the Account lockout duration and Reset account lockout counter. The recommended default value is 30 minutes for both settings.

Note  

To prevent a successful attack on the predefined Administrator account, it has proven effective to rename the account, for example, by using the security options. Alternatively, you can create a new system administration account with a different name . The Administrator account is then added to the Guests group and removed from the Administrators group. Then, even if a hacker is still able to guess the account password, little damage can be done. Additionally, since Windows Server 2003, another global system security default setting ensures that a user or administrator cannot open a terminal server session with a blank password, unless that user is physically at the server hardware console.

Local Policies

Local computer policies allow you to set audit policies, assign user permissions, and select advanced security options. Each of these areas has a direct impact on the terminal server s security settings.

Audit Policy

One of the central functions in a network operating system is monitoring access to servers and controlling server status through the Event Viewer. On a terminal server, this includes, in particular, user actions, system errors, and system load.

The audit policies are therefore vital to system security. They can be determined to be either local or central settings. The most important policies include monitoring logon events, logon attempts, use of permissions, and policy changes. Only for very secure systems is it necessary to also control access to the Active Directory and objects (such as files).

Figure 8-5: Default audit policy settings.

It is relatively easy to configure the monitoring functions within the policies. The individual functions can be adapted in the local or central security settings. For example, Figure 8-6 shows the configuration for monitoring object access attempts.

Figure 8-6: Modifying the object access attempt policy.

So what objects are monitored with this configuration? Basically, this setting involves files that can be monitored for access by predefined users or groups. If, however, a simple change in the audit policy results in monitoring all file accesses on a terminal server, the system will quickly reach its performance limits. For this reason, it is possible to precisely identify the directories and files to be monitored.

To configure a directory or file for monitoring purposes, you must first select the object in Explorer. Open the Security tab from the Properties directory or file. On the Security tab, activate the Advanced button to get to the Auditing tab. Continue to navigate by activating the Add... button. In the next dialog box, select a user or group. Click OK to get to the last dialog box, where you choose the monitoring entries. After these configuration tasks (which might take some time), the monitoring activities will be saved in the security log file of the Event Viewer.

Figure 8-7: Determining a monitoring entry for a directory. There is a choice of two options: successful and failed access attempts.

In addition to directory and file accesses, a terminal server Event Viewer indicates the monitoring results of many functions and activities. For this, the auditing configuration needs to be linked to individual users or groups. It is recommended that the following list of monitoring functions be logged for all users of a secured terminal server.

• Audit logon events Events that occur when a user logs on. This is where successful and failed attempts should be recorded.

• Audit account logon events User logon action. This is where successful and failed attempts should be recorded.

• Audit policy change Changes to the security settings. This is where only failed attempts should be recorded.

The Event Viewer s security log displays the result of the configuration. The other two Event Viewer functions, Application and System, allow further analysis of the terminal server environment. However, these logs can be viewed by quite a large user group and therefore allow individual configuration to a very limited extent only. The specific system log messages are explained in Chapter 4.

Note  

A terminal server in a production environment should always have a minimum of extended security functions, as described earlier. Otherwise, the danger of misuse going unnoticed by administrators is too great.

The function of monitoring the system is assigned to the local group of administrators. Nevertheless, the last action of an administrator is always logged and stored for controlling and security purposes. This means that even if an administrator deleted all logged control data, this act would be the first entry in a new log.

Assigning User Permissions

This area of the security settings includes the tasks that a user on a computer system or in a domain can be permitted to perform ”for example, logon permissions, saving files and folders, or shutting down the server. The relevant permissions can be assigned to groups or user accounts. However, it is recommended that only groups have the option to assign permissions.

Particularly on terminal servers, logon using Terminal Services merits special attention. The default setting allows only users who are members of the administrator group or the local group of Remote Desktop users to log on through Terminal Services. There is also an option to exclude certain users or groups from logging on using Terminal Services. Changing these settings might conflict with the Terminal Services configuration and its settings for RDP client connections (as discussed in Chapter 2), which could, of course, lead to unexpected results.

Figure 8-8: Assigning user permissions for logon using Terminal Services.

Security Options

The security options comprise a wide range of settings that are relevant for the security of domain controllers, domain members, devices, logon options, accounts, networks, and system objects. The following policies are of special interest when working with terminal servers:

• Devices Prevent users from installing printer drivers: This security setting is very important for terminal servers because it allows only administrators and power users to install printer drivers on the local computer. This option is enabled by default.

• Interactive logon Do not display last user name: When this policy is enabled, the name of the user who successfully logged on last does not appear in the Windows logon dialog box.

• Interactive logon Require smart card: When this security setting is enabled, all users must have a smart card to log on.

• Accounts Rename administrator account: This security setting determines whether a new account name is assigned to the administrator account s security ID (SID).

• Accounts Limit local account use of blank passwords to console logon only: When this security setting is enabled, users with a blank password can log on only to the local console, but not via a Terminal Services session. In principle, blank passwords should not be allowed on terminal servers. (See earlier in the chapter.)

• Network access Remotely accessible registry paths and subpaths: This is where, on a terminal server, the specific areas of the registry are released for remote access, regardless of the users and groups enumerated on the access control list.

Naturally, all other security options should be examined for their suitability in specific terminal server environments.

Figure 8-9: Security options for remote access to registry paths.