Software restriction policies provide administrators with a policy-driven mechanism to identify software programs running on computers in a domain and to control the ability of those programs to execute. You can use policies to block malicious scripts, to lock down a computer, or to prevent unwanted applications from running.
For more information about software restriction policies, see the Using Software Restriction Policies to Protect Against Unauthorized Software.
Limit Terminal Server Security Auditing
Auditing any system can introduce significant performance overhead depending on the number of events you audit and the number of user sessions that generate the events. When you configure a terminal server on Windows Server 2008, the cumulative effect of auditing events for multiple users working on the server at one time can affect the terminal server's performance.
In addition, for event logs to have any value you need staff to effectively review the logs on a regular basis. The more events you log, the larger the impact on performance and the more effort it will take to assess them.
For these reasons, Microsoft recommends to only enable as much event auditing that your organization can effectively use to balance security logging needs with the performance requirements of your terminal servers. In addition, you should test the impact of any changes to the terminal servers' auditing policies before you introducing an updated policy set to any production servers.
The following table identifies audit policy object names, audit setting descriptions, and recommended audit settings in Windows Server 2008.
Table 11.28 Terminal Server Audit Policy Settings
Policy object
|
Description
|
Recommended setting
|
Audit account logon events
|
This policy determines whether to audit each instance of a user logging on or off from a computer that is used to validate the account. Account logon events are generated when a domain user account is authenticated on a domain controller. The event is logged in the domain controller's security log. This policy is typically enabled only on domain controllers and is not normally required on a terminal server.
|
No Auditing
|
Audit account management
|
This policy determines whether to audit each event of account management on the terminal server. Examples of account management events include:
A user account or group is created, changed, or deleted.
A user account is renamed, disabled, or enabled.
A password is set or changed.
|
Audit Success and Failure
|
Audit directory service access
|
This policy determines whether to audit the event of a user who accesses an Active Directory Domain Services (AD DS) object that has a specified system access control list (SACL). This policy is typically enabled only on domain controllers and is not normally required on a terminal server.
|
No Auditing
|
Audit logon events
|
You can use this policy to audit each instance of a user logging on or off a terminal server.
|
Audit Success and Failure
|
Audit object access
|
This policy determines whether to audit the event of a user who accesses an object, such as a file, folder, registry key, printer, or any object that has a specified SACL. Because this policy can generate a large number of entries, Microsoft recommends only using this setting to audit failures that indicate unauthorized users attempting to access objects.
|
Audit Failure
|
Audit policy change
|
This policy determines whether to audit each instance of a change to user rights assignment policies, audit policies, or trust policies on the terminal server. Because this data should rarely change, Microsoft recommends auditing these changes.
|
Audit Success and Failure
|
Audit privilege use
|
This policy determines whether to audit each instance of a user exercising a user right. This policy can also generate a large number of entries in the security event log. For this reason, Microsoft does not typically recommend to log successful events for this policy because the event volume is likely to slow the performance of the terminal server.
|
Audit Failure
|
Audit process tracking
|
This policy determines whether to audit detailed tracking information for events, such as program activation, process exit, handle duplication, and indirect object access.
|
Audit Failure
|
Audit system events
|
This policy determines whether to audit users when they restart or shut down the computer or when an event occurs that affects either the system security or the security log.
|
Audit Success and Failure
|
After enabling any of these audit settings, it is important to check the event logs on the terminal server regularly and archive them as needed. If you choose to enable the Audit object access setting, you also need to configure auditing on each object that you want to track. Microsoft recommends restricting this capability to a manageable number of objects.
In addition to the ability to audit file system and registry objects, terminal servers can also report audit information about terminal server connections. These auditing reports record actions attempted during user sessions. For example, you can monitor actions such as modifying connection properties or remotely controlling a user's session after enabling connection auditing.
To enable Connection Auditing
On the terminal server, click Start, click Administrative Tools, and then click Terminal Services Configuration to open this tool.
In the right-hand panel, under the Connections list, right-click the desired connection name (RDP-Tcp by default), and then select Properties.
In the Properties dialog box, click the Security tab. If a Terminal Services Configuration information dialog box pops up, click OK.
Click the Advanced button, and then select the Auditing tab.
Click the Add button, type the name of the user, computer or group that you want to audit, and then click OK.
Select the seven audit policies as indicated in the following figure.
Figure 11.2 Terminal Server Connection Audit Entry Options
The seven entries listed in the previous figure can be useful when checking for security issues on a terminal server. Typically, only a system administrator should attempt both the "remote control" and "logoff" actions on another session. If attempts for these actions occur from a standard user account, this could indicate unwanted user behavior and require further investigation.
There are also a series of events specific to TS Gateway. By default all of these event types are audited. You can use TS Gateway Manager to specify the types of events that you want to monitor, such as unsuccessful or successful connection attempts to internal network resources (computers) through a TS Gateway server. You also can configure what event types to audit by right-clicking the server you want to manage in TS Gateway Manager, and selecting Properties. Then in the Server Properties dialog box, click the Auditing tab.
Figure 11.3 Terminal Server Gateway Auditing Options
For more information about TS Gateway event types, see TS Gateway Server Connections in the "Troubleshooting" section of the Windows Server 2008 TechNet Library.
Securing the TS Gateway
After you install the TS Gateway role service and configure a certificate for the TS Gateway server, you must create Terminal Services connection authorization policies (TS CAPs), computer groups, and Terminal Services resource authorization policies (TS RAPs). These policies are required to ensure that the TS Gateway service functions correctly.
Although the Add Role Services Wizard for TS Gateway includes an option to generate a self-signed certificate, this selection is recommended only for testing and evaluation purposes. For your production deployment, Microsoft recommends to obtain a computer certificate from a trusted certificate authority (CA).
Microsoft recommends the following security-related configuration recommendations for the desktop environment on terminal servers. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 11.29 TS Gateway Configuration Checklist
|
Configuration tasks
|
|
Use Terminal Services connection authorization policy (TS CAP).
|
|
Use Terminal Services resource authorization policy (TS RAP).
|
|
Secure TS Gateway IIS installation.
|
Use Terminal Services Connection Authorization Policy (TS CAP)
Terminal Services connection authorization policies (TS CAPs) allow you to specify who can connect to a TS Gateway server. You can specify a user group that exists on the local TS Gateway server or in Active Directory Domain Services (AD DS). You can also specify other conditions that users must meet to access a TS Gateway server.
For example, you can specify that all users who connect to a specific terminal server that is hosting a human resources (HR) database through a TS Gateway server must be members of the "HR Users" security group. You can also specify that the client computer that initiates the connection must be a member of an Active Directory security group in the corporate network to connect to the TS Gateway server. By requiring that the computer be a member of a specific Active Directory security group in the corporate network, you can exclude users who attempt to connect to the corporate network from kiosks, airport computers, or home computers that are not trusted.
For enhanced security when client computers connect to the internal corporate network through TS Gateway, you can also specify whether to disable client device redirection for all devices supported by the Terminal Services client, or for a specific type of device, such as a disk drive or supported Plug and Play devices. If you disable client device redirection for all devices supported by the client, all device redirection is disabled, except for audio and smart card redirection.
When you select the option to disable device redirection for specific device types or to disable all device types except for smart cards, the TS Gateway server will send the request back to the client with a list of the device types to be disabled. This list is a suggestion only; it is possible for the client computer to modify the device redirection settings in the list.
Caution Because the TS Gateway server relies on the client computer to enforce device redirection settings that the server suggests, this feature does not provide guaranteed security. Suggested device redirection settings can only be enforced for RDC clients. The settings cannot be enforced for client computers that do not use RDC. In addition, it is possible for a malicious user to modify an RDC client so that the client ignores the suggested settings. In such cases, this feature cannot provide guaranteed security, even for RDC clients.
In addition, you can specify whether remote clients must use smart card authentication or password authentication to access internal network resources through a TS Gateway server. When both of these options are selected, client computers that use either authentication method are allowed to connect.
Finally, if your organization has deployed Network Access Protection (NAP), you can specify that the client must send a statement of health (SoH). For information about how to configure TS Gateway for NAP, see "Configuring the TS Gateway NAP Scenario" in the TS Gateway Server Step-by-Step Setup Guide for Windows Server 2008.
Important Users are granted access to a TS Gateway server if they meet the conditions specified in the TS CAP. You must also create a TS RAP. A TS RAP allows you to specify the internal network resources that users can connect to through TS Gateway. Until you create both a TS CAP and a TS RAP, users cannot connect to network resources through this TS Gateway server.
Use Terminal Services Resource Authorization Policy (TS RAP)
Terminal Services resource authorization policies (TS RAPs) allow you to specify the internal corporate network resources that remote users can connect to through a TS Gateway server. When you create a TS RAP, you can create a computer group, or a list of computers on the internal network to which you want remote users to connect, and then associate it with the TS RAP.
For example, you can specify that users who are members of the "HR Users" user group be allowed to connect only to computers that are members of the "HR Computers" computer group, and that users who are members of the "Finance Users" user group be allowed to connect only to computers that are members of the "Finance Computers" computer group.
Remote users connecting to an internal corporate network through a TS Gateway server are granted access to computers on the network if they meet the conditions specified in at least one TS CAP and one TS RAP.
Note When you associate a TS Gateway-managed computer group with a TS RAP, you can support both fully qualified domain names (FQDNs) and NetBIOS names by adding both names to the TS Gateway-managed computer group separately. When you associate an Active Directory security group with a TS RAP, both FQDNs and NetBIOS names are supported automatically if the internal network computer that the client is connecting to belongs to the same domain as the TS Gateway server. If the internal network computer belongs to a different domain than the TS Gateway server, users must specify the FQDN of the internal network computer. Together, TS CAPs and TS RAPs provide two different levels of authorization that allow you to configure a more specific level of access control to computers on an internal corporate network.
Computer Groups Associated With TS RAPs
Remote users can connect through TS Gateway to internal corporate network resources in the following ways:
As members of an existing security group. The security group can exist in Local Users and Groups on the TS Gateway server, or in AD DS.
As members of an existing TS Gateway-managed computer group or a new TS Gateway-managed computer group. You can configure the TS Gateway-managed computer group by using TS Gateway Manager after installation.
A TS Gateway-managed group will not appear in Local Users and Groups on the TS Gateway server, and you cannot configure it using Local Users and Groups.
Using any network resource. In this case, users can connect to any computer on the internal corporate network that they can connect to when they use Remote Desktop Connection. This option is not recommended because it expands the potential attack surface of your network.
Secure TS Gateway IIS installation
In high-security environments, to prevent authenticated users with valid password or smart card credentials from reaching the RPC layer, consider locking down the TS Gateway server by disabling IIS virtual directories. You can make the following modifications to the IIS installation to further decrease the attack surface of a TS Gateway server:
Eliminate unneeded ports from the ValidPorts registry key.
Disable password authorization in IIS for pure smart card deployments.
Limit password authorization in IIS to only users who are should authenticate to the TS Gateway.
Limit access to the RpcWithCert virtual directory to ensure that a username mapping has occurred in IIS.
Remove unneeded CA root certificates from the Trusted Root Certificate Authorities store.
More Information
The following resources on Microsoft.com can provide you with more security best practice information about how to design and maintain a server running Windows Server 2008 that performs Terminal Services:
"How to change Terminal Server’s listening port": Microsoft Knowledge Base article 187623.
Technical Reference Terminal Services for information about Group Policy settings.
Terminal Services in the TechNet Library.
The "Working with Quotas" section of the Step-by-Step Guide for File Server Resource Manager.
TS Gateway Server Step-by-Step Setup Guide: "Configuring the TS Gateway NAP Scenario" section.
Using Software Restriction Policies to Protect Against Unauthorized Software .
Windows Server 2008 TechNet Library.
Other Terminal Server and Virtualization-related Solution Accelerators:
Introduction to the Infrastructure Planning and Design guide series.
Microsoft Assessment and Planning Toolkit Solution Accelerator (MAP).
Microsoft Deployment Solution Accelerator, which is the next version of Business Desktop Deployment (BDD) 2007.
Windows Vista Security Guide.
Solution Accelerators microsoft.com/technet/SolutionAccelerators
|
