Share via

Infrastructure

  • Article

SP2 includes the following new policy settings for Terminal Services clients and User Profiles:

  • The Terminal Services policy setting, Do not allow password to be saved, is used to prevent users using Terminal Services clients from saving their passwords in the client, as explained in “Terminal Services Client: Prevent Users from Saving Passwords,” later in this document.

  • The User Profiles policy setting, Leave Windows Installer and Group Policy Software Installation Data is used to retain data pertaining to Windows Installer and Software Installation when a user’s roaming user profile is deleted, as explained in “User Profiles: Preserving Windows Installer and Software Installation Data During Profile Deletion,” later in this document.

On This Page

Terminal Services Client: Preventing Users from Saving Passwords
User Profiles: Preserving Windows Installer and Software Installation Data During Profile Deletion
Background Intelligent Transfer Service Bandwidth Management
Peer-To-Peer Networking
Remote Procedure Call Policy Settings

Terminal Services Client: Preventing Users from Saving Passwords

SP2 includes a new Terminal Services policy setting which allows users to disable the save password feature in the Terminal Services client. The Do not allow password to be saved policy setting is accessed in these Group Policy Object Editor nodes: Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Client and User Configuration\Administrative Templates\Windows Components\Terminal Services\Client.

The Do not allow password to be saved policy setting is appropriate for corporate environments in which you want to prevent managed computers and users from saving their Terminal Server credentials. An example of how you can use this policy setting is in an environment in which users use Terminal Services clients to connect from low security networks to high security networks to access their line of business (LOB) applications, and you want to prevent leaving passwords to high security networks on low security client computers. To provide enhanced security, you can use this policy setting.

Do not allow password to be saved

If you enable the Do not allow password to be saved policy setting, the Save my password check box in Terminal Services clients is disabled and any users affected by the GPO containing this policy are prevented from saving passwords from the Terminal Services client. When users open a Remote Desktop Protocol (.rdp) file by using the Terminal Services client and save their settings, any password that previously existed in the .rdp file is deleted. An .rdp file contains all the information for a connection to a terminal server, including the Options settings that were configured when the file was saved.

The Do not allow password to be saved policy setting applies to Terminal Services Remote Desktop Connection clients. This policy setting can be set to one of the following options:

  • Enabled. This option clears and disables the Save my password check box.

  • Disabled. This option allows passwords to be saved, but does not force users to save passwords.

  • Not Configured (default). If this policy is set to Not configured, any other Group Policy setting which applies is still in effect. This option does not affect other policy settings.

Computer configuration settings override user configuration settings, as with standard Group Policy behavior.

User Profiles: Preserving Windows Installer and Software Installation Data During Profile Deletion

Windows XP PS2 includes a new policy setting that you can use to specify that data related to Windows Installer and Group Policy Software Installation be preserved when a user profile is deleted. This new policy setting, Leave Windows Installer and Group Policy Software Installation Data is in the Computer Configuration\Administrative Templates\System\User Profiles node of Group Policy Object Editor.

By default, when a user’s roaming profile is deleted, all information related to the roaming user is deleted, including the user’s settings data, Windows Installer-related data, and so on. Consequently, the next time the user logs on to that computer, the user must reinstall all applications published by means Group Policy at logon, which increases logon time. To change this behavior, you can use the Leave Windows Installer and Group Policy Software Installation Data policy setting. This policy setting determines whether the system retains a roaming user’s Windows Installer and Group Policy-based software installation data when the user’s profile is deleted.

~note.gif  Note
If an administrator has enabled this policy for a computer and wants to delete this data and get the profile completely removed, the local administrator must remove the Windows Installer or Group Policy Software Installation data stored in the registry and file system of roaming users’ profiles stored on the computer. Network-Related Policy Settings.

SP2 includes policy settings to manage certain aspects of the following networking components:

  • Background Intelligent Transfer Service. These policy settings allow you to set limits on the network bandwidth that BITS uses. See “Background Intelligent Transfer Service Bandwidth Management,” later in this document.

  • Peer-To-Peer Networking. These policy settings allow you to turn off the Peer-to-Peer Networking Services, specify the seed server to use, and turn off multicast bootstraping. See “Peer-To-Peer Networking,” later in this document.

  • Remote Procedure Call. These policy settings allow you to block remote anonymous access to RPC interfaces on the system, and prevent anonymous access to the RPC Endpoint Mapper interface. See “Remote Procedure Call Policy Settings,” later in this document.

Background Intelligent Transfer Service Bandwidth Management

Background Intelligent Transfer Service (BITS) is a file transfer service that transfers files in the foreground or background (default) between a client and a server. Background transfers use only idle network bandwidth in order to preserve the user’s interactive experience with other network applications, such as Internet Explorer. BITS examines the network traffic, and uses only the idle portion of the network bandwidth. BITS regulates its use of bandwidth as users increase or decrease their use of the bandwidth.

A BITS job is a container that includes one or more files to transfer; a job has a lifecycle that begins when the user creates the job, and it also has properties that specify how BITS transfers the files and interacts with the user’s application. BITS performs file transfers asynchronously, which means that applications do not need to be running for BITS to perform the transfer. After an application creates the transfer job, the user can close the application and BITS continues to transfer the files. The BITS file transfers continue as long as there is a network connection and the user who created the job is logged on the computer. Service accounts, such as LocalSystem, are always logged on, so transfer jobs created by a service always run.

BITS suspends file transfers if the user logs off or the network connection is lost. When the user logs on and a network connection exists, BITS resumes the transfer from where it left off previously. The same is true for system reboots.

BITS supports the HTTP protocol and provides Internet and authentication security. BITS also provides APIs that you can use to create and monitor transfer jobs from your application.

BITS is only aware of the network conditions on the client computer; BITS is not aware of network conditions beyond the client. If there are no applications running on the client that use the network, BITS consumes most of the available bandwidth.

SP2 provides a new BITS policy setting that you can use to set limits on the network bandwidth that BITS uses: Maximum network bandwidth that BITS uses. This setting is accessed in the Computer Configuration\Administrative Templates\Network\Background Intelligent Transfer Service node of the Group Policy Object Editor.

Windows XP with SP2 includes BITS 2.0, which listens for the network bandwidth policy settings (Maximum network bandwidth that BITS uses). Computers with earlier service packs of Windows 2000 or Windows XP can receive the BITS 2.0 software by using Automatic Updates or Windows Update Services.

The Maximum network bandwidth that BITS uses policy setting limits the network bandwidth that BITS uses for background transfers (this policy does not affect foreground transfers).

Typically, you use the Maximum network bandwidth that BITS uses policy setting to prevent BITS transfers from competing for network bandwidth when a client that has a fast network card (10 Mbps) is connected to the network through a slow link (56 Kbps). You can use this policy setting to specify a bandwidth limit to use during a particular time interval and a limit to use at all other times. This is useful in scenarios such as remote office environments where there are a small number of computers using Digital Subscriber Line (DSL) or shared access dial-up to connect to the network, and you want to allocate bandwidth usage for foreground applications during the day. For example, you might use this policy to limit the use of network bandwidth to 10 kilobits per second (Kbps) from 8:00 A.M. to 5:00 P.M. and use all available unused bandwidth the rest of the time.

To use the Maximum network bandwidth that BITS uses policy setting, specify a limit based on the shared network link, not the computer’s network adapter. BITS uses approximately two kilobits if you specify a value less than two kilobits. To prevent BITS transfers from occurring, specify a limit of zero. If you specify a limit of zero, BITS places all background jobs in a transient error state (the error code is set to BG_E_BLOCKED_BY_POLICY, 0x8020003E). After the time interval expires, BITS places the jobs in the queued state.

~note.gif  Note
If you set the Maximum network bandwidth that BITS uses (MaxInternetBandwidth) value to zero and run the BITSAdmin.exe tool, the BITS job is shown to be in a transient error state.
BITSAdmin is a command-line tool that you can use to create download or upload jobs and monitor their progress. It is included in the \Support\Tools\Support.cab file on the Windows Server operating system installation CD. To unpack and install BITSAdmin, run the Setup.exe file in the Tools directory. For more information about BITSAdmin, see the “BITSAdmin Tool” topic in “Background Intelligent Transfer Service,” in the Microsoft Platform SDK.

The BITS code reads the Maximum network bandwidth that BITS uses policy setting immediately. However, you might need to do a Group Policy refresh (run the gpudate command) or restart the computer if you are using the Timeout (days) for inactive jobs BITS policy setting and you want to apply this policy immediately. Administrators should choose hours for daytime and nighttime that work well for their particular scenario, and keep in mind that times are local client time rather than Greenwich Mean Time or the time zone of the administrator’s computer. Administrators also need to decide whether to allow any background BITS traffic during the day. Allowing unlimited usage during the night (the default) is appropriate for most situations.

For more information about the BITS APIs, see “Background Intelligent Transfer Service” in the Microsoft Platform SDK. Also see the “Background Intelligent Transfer Service in Windows Server 2003” white paper on the Microsoft Web site.

Registry Keys Used by Maximum Network Bandwidth that BITS Uses Policy Setting

Table 6 summarizes the values for the BITS MaxInternetBandwidth registry keys.

Table 6  Values for BITS MaxInternetBandwidth Registry Keys

Setting name

Location

Default value

Possible values

EnableBITSMaxBandwidth

HKLM \Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

DWORD controlling whether BITS limits bandwidth of background jobs.

If not configured, BITS imposes no limit.

If zero, BITS imposes no limit.

If one, BITS limits bandwidth

MaxTransferRateOnSchedule

HKLM \ Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

DWORD maximum rate, measured in kilobits per second.

0xffffffff is interpreted as “unlimited”.

If the key is not present or invalid, 50 kbps is assumed.

MaxTransferRateOffSchedule

HKLM \ Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

DWORD maximum rate, measured in kilobits per second.  

0xffffffff is interpreted as “unlimited”.

If the key is not present or invalid, “unlimited” is assumed.

This value is ignored if UseSystemMaximum is nonzero.

UseSystemMaximum

HKLM \ Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

Zero means the off-schedule maximum is read from MaxTransferRateOffSchedule.

Any other value means the off-schedule maximum is unlimited.

MaxBandwidthValidFrom

HKLM \ Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

DWORD hour of the day, between 0 and 23.

If missing or invalid, “8” is assumed.

MaxBandwidthValidTo

HKLM \ Software \ Policies \ Microsoft \ Windows \ BITS

Not configured

DWORD hour of the day, between 0 and 23.

If missing or invalid, “18” is assumed.

Peer-To-Peer Networking

SP2 includes new policy settings that you can use to enforce Group Policy-based configuration of certain aspects of the Peer-to-Peer Networking Services.

The Peer Name Resolution Protocol (PNRP) allows for distributed resolution of a name to an IPV6 address and port number. The protocol operates in the context of clouds. A cloud is a set of peer computers that can communicate with each other by using the same IPv6 scope. There are three types of clouds, global, site-local, and link-local:

  • If a computer is connected to the Internet, it is part of a global cloud. Corporate firewalls might cause the global cloud to be split such that the cloud only exists in the corporation.

  • If a computer is connected to one or more local area networks, individual link-local clouds are available for each link.

  • If your organization has been configured to support IPv6 sites, individual site-local clouds are available for each specific site.

Before PNRP can participate in a cloud, it needs to be bootstrapped. This can be done in one of the following ways:

  • If the computer has participated in the peer to peer cloud previously, the protocol can use cached information to bootstrap itself.

  • If step 1 does not work, the computer sends a local multicast message (assuming SSDP service is already running) on the subnet to determine if there are other computers online that can help bootstrap it.

  • If step 2 does not work, the computer sends a message to a well known node (called a seed server) hosted on the Internet. Alternatively, you can use a Group Policy setting to point to a node within the corporation.

With the initial implementation of the Advanced Networking Pack for Windows XP, there was no way to configure the seed server by using Group Policy. SP2 provides three PNRP policy settings which allow for policy-based configuration of certain aspects of peer networking protocols, Turn off Microsoft Peer-to-Peer Networking Services, Set the Seed Server, and Turn off Multicast Bootstrap. These policy settings are in the Computer Configuration\Administrative Templates\Network\Microsoft Peer-to-Peer Networking Services node of Group Policy Object Editor.

By using these policy settings, you can centrally manage certain configuration options for Peer-to-Peer Networking Services and then rely on the system to enforce these policy settings.

Turn off Microsoft Peer-to-Peer Networking Services

This policy setting turns off Peer-to-Peer Networking Services in its entirety, and causes all dependent applications to stop working. Peer-to-Peer protocols allow for applications in the areas of RTC, collaboration, content distribution and distributed processing.

If you enable this policy setting, peer-to-peer protocols are turned off. If you disable or do not configure this policy setting, the peer-to-peer protocols are turned on (assuming the peer to peer optional component was installed previously).

If you set this policy setting to Enabled and subsequently to Disabled you need to restart applications.

Set the Seed Server

This policy setting sets the seed server to a specified node in the enterprise. You can apply this policy setting per cloud: global, site-local, and link-local. Set the Seed Server is available in Computer Configuration\Administrative Templates\Network\Microsoft Peer-to-Peer Networking Services\Peer Name Resolution Protocol, under each of these nodes: Global Clouds, Site-local Clouds, and Link-local Clouds.

  • Global Clouds. In the global cloud, this policy setting allows you to configure the seed server settings for mobile users to use their peer to peer applications from both the home and within the enterprise. To do this, you can enable this policy setting and set it to an IPv6 address or DNS name of a corporate seed server. You could optionally check the check box that disables the use of the global seed server, and only allows the internal seed server to be used. This, however, is not recommended because it prevents mobile users from using their peer to peer application outside of their enterprise.

  • Site-local Clouds or Link-local Clouds. In the site-local cloud or link-local cloud, an administrator can specify the name of the corporate seed server, as described previously for Global Clouds. Since DNS is not present in link-local clouds, you would only specify IPv6 addresses for that particular scope.

In all cases, if the Set the Seed Server policy setting is not configured, the well known seed server (pnrp.ipv6.microsoft.com) is used. Note that if your corporate firewall does not allow for outbound IPv6 traffic, this seed server is not accessible.

Turn off Multicast Bootstrap

This policy setting disables PNRP protocol from advertising the computer or from searching other computers on the local subnet in the specific cloud. If you enable this policy setting, PNRP does not use multicast for bootstrapping. If you configure this policy, scenarios where there is no seed server for bootstrap (such as adhoc collaborative scenarios) are not supported. This policy is available in Computer Configuration\Administrative Templates\Network\Microsoft Peer-to-Peer Networking Services\Peer Name Resolution Protocol, under each of these nodes: Global Clouds, Site-local Clouds, and Link-local Clouds.

If you do not configure this policy setting or disable it, PNRP uses multicast for bootstrapping on the same subnet, and advertises the local computer.

The multicast protocol used for bootstrapping is Simple Service Discovery Protocol (SSDP). The SSDP service must be enabled (which it is by default) for this policy setting to have effect.

Remote Procedure Call Policy Settings

SP2 includes changes to the Remote Procedure Call (RPC) service which are designed to help make RPC interfaces secure by default and reduce the attack surface of Windows XP. Two new policy settings have been added

  • Restrictions for Unauthenticated RPC clients. This policy setting allows you to modify the behavior of all RPC interfaces on the system and, by default, eliminates remote anonymous access to RPC interfaces on the system, with some exceptions. This policy setting sets the value of the new RestrictRemoteClients registry key.

  • RPC Endpoint Mapper Client Authentication. This policy setting allows you to direct RPC clients that need to communicate with the Endpoint Mapper Service to authenticate, provided that the RPC call for which the endpoint needs to be resolved has authentication information. This policy setting sets the value of the new EnableAuthEpResolution registry key.

Requiring calls to perform authentication, even a relatively low level of authentication, can help protect an interface from attacks. This is a particularly useful mitigation against worms which rely on exploitable buffer overruns that can be invoked remotely by using anonymous connections.

The RPC policy settings are accessed in the Computer Configuration\Administrative Templates\System\Remote Procedure Call node of the Group Policy Object Editor.

Restrictions for Unauthenticated RPC clients

When an interface is registered using RpcServerRegisterIf, RPC allows the server application to restrict access to the interface, typically through a security callback. The RestrictRemoteClients registry key forces RPC to perform additional security checks for all interfaces, even if the interface has no registered security callback. The Restrictions for Unauthenticated RPC clients Group Policy setting sets the value for this registry key.

Enabling the Restrictions for Unauthenticated RPC clients policy setting directs the RPC Runtime on an RPC server to restrict unauthenticated RPC clients connecting to RPC servers running on a computer. A client is considered an authenticated RPC client if it uses either a named pipe to communicate with the server or RPC Security. RPC Interfaces that have specifically asked to be accessible by unauthenticated clients might be exempt from this restriction, depending on the selected value for this policy.

~note.gif  Note
RPC clients that use the named pipe protocol sequence (ncacn_np) are exempt from all restrictions discussed in this section. The named pipe protocol sequence cannot be restricted by default, due to several significant backwards compatibility issues.

If you enable the Restrictions for Unauthenticated RPC clients policy setting, you can configure RPC Runtime Unauthenticated Client to Apply with one of the following options:

  • Authenticated (Default). This option allows only authenticated RPC clients to connect to RPC servers running on the computer on which the policy setting is applied. Interfaces that have asked to be exempt from this restriction are granted an exemption. This option represents the RPC_RESTRICT_REMOTE_CLIENT_DEFAULT (1) value.

  • Authenticated without exceptions. This option allows only authenticated RPC clients to connect to RPC servers running on the computer on which the policy setting is applied; it does not permit exceptions. If you select this option, a system cannot receive remote anonymous calls using RPC; it provides the highest level of security. This option represents the RPC_RESTRICT_REMOTE_CLIENT_HIGH (2) value.

  • None. This option allows all RPC clients to connect to RPC servers running on the computer on which the policy is applied. If you select this option, the system bypasses the new RPC interface restriction. This option is equivalent to the RPC behavior in previous versions of Windows. This option represents the RPC_RESTRICT_REMOTE_CLIENT_NONE (0) value.

Considerations for RPC Applications that May Receive Calls from Remote Anonymous RPC Clients

If your RPC application expects to receive calls from remote anonymous RPC clients, this RPC change might not allow your application to run correctly. To resolve this issue, you can use one of the following options (listed in order of preference):

  • Require your RPC clients to use RPC security when contacting your server application. This is the best method to mitigate security threats.

  • Exempt your interface from requiring authentication by setting the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface registration. This configures RPC to allow anonymous connections to only your application’s interface.

  • Force RPC to exhibit the same behavior as earlier versions of Windows by enabling the Restrictions for Unauthenticated RPC clients policy, and setting the RPC Runtime Unauthenticated Client to Apply value to None (registry key is RPC_RESTRICT_REMOTE_CLIENT_NONE (0)). RPC will accept anonymous connections to all interfaces. If possible, you should avoid using this option, as it reduces the overall security of the computer.

RPC Endpoint Mapper Client Authentication

An RPC interface that is remotely and anonymously accessible and is registered by default on Windows XP presents a significant attack surface. RPC itself must register such an interface to provide endpoint resolution for calls using dynamic endpoints.

With the addition of the RestrictRemoteClients flag, by default, the RPC Endpoint Mapper interface is not accessible anonymously. While this is a significant security improvement, it also changes the task of resolving an endpoint. Currently, an RPC client that attempts to make a call using a dynamic endpoint first queries the RPC Endpoint Mapper on the server to determine the endpoint to which it should connect. This query is performed anonymously, even if the RPC client call itself uses RPC security.

In SP2 anonymous calls to the RPC Endpoint Mapper interface fail by default because of the default value for the new RestrictRemoteClients key. This makes it necessary to modify the RPC client runtime to perform an authenticated query to the Endpoint Mapper. If the new EnableAuthEpResolution registry key is set, the RPC client runtime uses NTLM to authenticate to the Endpoint Mapper; this authenticated query only takes place if the actual RPC client call uses RPC authentication.

The RPC Endpoint Mapper Client Authentication Group Policy setting, which sets the EnableAuthEpResolution registry key, directs the RPC client runtime to use NTLM to authenticate to the Endpoint Mapper.

If you enable the RPC Endpoint Mapper Client Authentication policy setting, RPC clients that need to communicate with the Endpoint Mapper Service authenticate, provided that the RPC call for which the endpoint needs to be resolved has authentication information.

If you disable the RPC Endpoint Mapper Client Authentication policy setting, RPC Clients that need to communicate with the Endpoint Mapper Service do not authenticate. The Endpoint Mapper Service on computers running Windows NT® 4.0 operating systems cannot process authentication information supplied in this manner. This means that enabling this setting on a client computer prevents that client from communicating with a Windows NT 4.0 server using RPC if endpoint resolution is needed.

For more information and to learn about new RPC Interface Registration Flags, see the “RPC Interface Restriction” section in “Part 2: Network Protection Technologies” of the “Changes to Functionality in Microsoft Windows XP with Service Pack 2” document at on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=29126.