Additional Registry Entries
Applies To: Windows Server 2008
This section provides information about registry entries (also called registry values) that can be used in addition to the Group Policy settings you define for Windows Server 2008 and Windows Vista.
The following settings include registry entries that do not display by default through the Local Group Policy Editor. You can identify these settings by their "MSS:" prefix. The GPOAccelerator.wsf script that is provided with the Windows Vista Security Guide (https://go.microsoft.com/fwlink/?LinkId=74027) modifies the Local Group Policy Editor so that the Local Group Policy Editor properly displays the MSS settings.
TCP/IP-Related Registry Entries
Windows Server 2008 and Windows Vista provide a new implementation of the TCP/IP protocol stack known as the Next Generation TCP/IP stack. This stack is a complete redesign of TCP/IP functionality for both IPv4 and IPv6. The Next Generation TCP/IP stack supports:
Receive Window Auto Tuning. Optimizes TCP transfers for the host receiving data by automatically managing the size of the memory buffer (the receive windows) to use for storing incoming data based on the current network conditions.
Compound TCP (CTCP). Optimizes TCP transfers for the sending host by vigorously increasing the amount of data sent in a connection while ensuring that other TCP connections are not impacted.
Neighbor Unreachability Detection. Determines when neighboring nodes, including routers, cannot be contacted and reports the condition.
Automatic Dead Gateway Retry. Checks a previously unreachable gateway periodically to determine whether it has become available.
Automatic Black Hole Router Detection. Prevents TCP connections from terminating due to intermediate routers silently discarding large TCP segments, retransmissions, or error messages.
Routing Compartments. Prevents unwanted forwarding of traffic between interfaces by associating an interface or a set of interfaces with a login session that has its own routing tables.
Network Diagnostics Framework. Provides an extensible architecture that helps users to recover from and troubleshoot problems with network connections.
TCP Extended Statistics. Helps to determine whether a performance bottleneck for a connection is the sending application, the receiving application, or the network.
Windows Filtering Platform Provides application programming interfaces (APIs) for extending the TCP/IP filtering architecture so that it can implement packet filtering at all levels of the TCP/IP protocol stack to help to protect services and support additional services that inspect and filter TCP/IP packets, such as Windows Firewall.
Another important platform feature that makes the operating systems more secure by default is Windows Service Hardening, which reduces the attack surface of the operating system by assigning a Security Identifier (SID) to each Windows service and preconfigured access control that controls who can access the service and what the service can access. If necessary, these ACLs can be modified to be more or less restrictive, as defined by your organizational security needs. Combined with the improvements in the TCP/IP protocol, TCP/IP is more secure by default than in previous releases of Windows and includes SYN attack protection by design.
However, then are still denial of service (DoS) attacks that are directed at the TCP/IP stack. These attacks tend to be one of two classes: attacks that use an excessive number of system resources or attacks that send specially crafted packets that cause the network stack or the entire operating system to fail. For additional protection against the attacks that are directed at the TCP/IP stack, consider implementing the following registry settings.
The registry settings in the following table can be added to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ subkey.
More detailed information about each of these settings is provided in the subsections that follow the table.
Note
These setting can be applied to both IPv4 and IPv6 networks.
| Registry entry | Format | Windows Vista® and Windows Server® 2008 default setting | Recommended setting |
|---|---|---|---|
DisableIPSourceRouting |
DWORD |
1 for IPv4, 0 for IPv6 |
2 |
KeepAliveTime |
DWORD |
7,200,000 (time in milliseconds) |
300,000 (time in milliseconds) |
PerformRouterDiscovery |
DWORD |
2 |
0 |
TcpMaxDataRetransmissions |
DWORD |
5 |
3 |
DisableIPSourceRouting
This entry appears as MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) in the Local Group Policy Editor. IP source routing is a mechanism that allows the sender to determine the IP route that a datagram should follow through the network.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
No additional protection, source routed packets are allowed |
1 |
Medium, source routed packets ignored when IP forwarding is enabled |
2 |
Highest protection, source routing is completely disabled |
<Null> |
Not Defined |
The default configuration in Windows Vista and Windows Server 2008 is 1 for IPv4 networks and 0 for IPv6 networks.
Vulnerability
Source routing allows a computer that sends a packet to specify the route that the packet takes. Attackers can use source routed packets to obscure their identity and location.
Countermeasure
Configure the DisableIPSourceRouting entry to a value of 2.
Potential impact
If you configure this value to 2, all incoming source routed packets are dropped.
KeepAliveTime
Note
TCP keepalives for TCP/IP for Windows Server 2008 and Windows Vista are disabled by default. If enabled through the use of the setsockopt Windows Sockets function, a keepalive segment is sent every two hours by default, as controlled by the KeepAliveTime registry value. Even if enabled, other upper-layer protocols such as NetBIOS send their own keepalive value. If the keepalive interval that the upper-layer protocol uses is less than the TCP keepalive interval, TCP keepalive value is never sent. For example, NetBIOS sessions over TCP/IP send a NetBIOS keepalive request every 60 minutes. Therefore, TCP keepalive values that are enabled for a NetBIOS session are never used.
This entry appears as MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds (300,000 is recommended) in the Local Group Policy Editor and is stored in the HKLM\System\CurrentControlSet\Services|Tcpip\Parameters\KeepAliveTime registry key. This setting controls how often TCP sends a keep-alive packet to verify that an idle connection is still intact. If the remote computer is still reachable, it acknowledges the keep-alive packet.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
150000 |
150000 or 2.5 minutes |
300000 |
300000 or 5 minutes (recommended) |
600000 |
600000 or 10 minutes |
1200000 |
1200000 or 20 minutes |
2400000 |
2400000 or 40 minutes |
3600000 |
3600000 or 1 hour |
7200000 |
7200000 or 2 hours (default value) |
<Null> |
Not Defined |
You can specify settings with values 1 through 0xFFFFFFFF in the registry. The values identified in the Local Group Policy Editor UI and in the preceding table are provided as an aid in choosing the most useful keep-alive time periods. The default configuration is 7,200,000 (two hours).
Vulnerability
An attacker who is able to connect to network applications could establish numerous connections to attempt to cause a DoS condition.
Countermeasure
Configure the KeepAliveTime entry to a value of 300000 or 5 minutes.
Potential impact
Keep-alive packets are not sent by default by Windows. However, some applications may configure the TCP stack flag that requests keep-alive packets. For such configurations, lowering this value from the default setting of two hours to five minutes helps disconnect inactive sessions more quickly.
PerformRouterDiscovery
This entry appears as MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS) in the Local Group Policy Editor. It enables or disables the Internet Router Discovery Protocol (IRDP). IRDP allows the computer to detect and configure default gateway addresses automatically (as described in RFC 1256) on a per-interface basis.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
0 (Disabled) |
1 |
1 (Enabled) |
2 |
2 (enable only if DHCP sends the Perform Router Discovery option) |
<Null> |
Not Defined |
The default configuration is 2.
Vulnerability
An attacker who has gained control of a computer on the same network segment as a router could configure a computer on the network to impersonate the router. Other computers with IRDP enabled would then attempt to route their traffic through the already compromised computer.
Countermeasure
Configure the PerformRouterDiscovery entry to a value of 0 - Disabled.
Potential impact
If you disable this entry, servers cannot automatically detect and configure default gateway addresses on the computer.
TcpMaxDataRetransmissions
This entry appears as MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) in the Local Group Policy Editor. This entry sets the maximum number of retransmissions of a TCP segment containing data before the connection is abandoned. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume. The base timeout value is dynamically determined by the measured round-trip time on the connection.
Possible values:
- 0 to 0xFFFFFFFF
The default configuration is 5.
In the Local Group Policy Editor UI, this setting can be adjusted using a text entry box:
A user-defined number
Not Defined
Vulnerability
A malicious user could exhaust a target computer's resources if it never sent any acknowledgment messages for data that was transmitted by the target computer.
Countermeasure
Configure the TcpMaxDataRetransmissions entry to a value of 3.
Potential impact
TCP starts a retransmission timer when each outbound segment is passed to the IP. If no acknowledgment is received for the data in a given segment before the timer expires, the segment is retransmitted up to three times.
Tip
For additional information about these and other TCP/IP registry settings, see the downloadable white paper "TCP/IP Registry Values for Windows Vista and Windows Server 2008" (https://www.microsoft.com/downloads/details.aspx?familyid=12AC9780-17B5-480C-AEF7-5C0BDE9060B0&displaylang=en).
Miscellaneous Registry Entries
We recommend the registry entries in the following table. Additional information about each entry, including the location of each registry key setting, is provided in the subsections that follow the table.
Additional non-TCP/IP-related registry entries
| Registry entry | Format | Most secure value (decimal) |
|---|---|---|
AutoAdminLogon |
DWORD |
Not defined, except for highly secure environments, which should use 0. |
AutoReboot |
DWORD |
Not defined, except for highly secure environments, which should use 0. |
AutoShareWks |
DWORD |
Not defined, except for highly secure environments, which should use 1. |
DisableSavePassword |
DWORD |
1 |
Hidden |
DWORD |
Not defined, except for highly secure environments, which should use 1. |
NoDriveTypeAutoRun |
DWORD |
0xFF |
NoNameReleaseOnDemand |
DWORD |
1 |
NtfsDisable8dot3NameCreation |
DWORD |
1 |
ScreenSaverGracePeriod |
String |
0 |
RestrictRemoteClients |
DWORD |
1 |
EnableAuthEpResolution |
DWORD |
1 |
RunInvalidSignatures |
DWORD |
0 |
StorageDevicePolicies\WriteProtect |
DWORD |
1 |
UseBasicAuth |
DWORD |
0 |
DisableBasicOverClearChannel |
DWORD |
1 |
AutoAdminLogon
This entry appears as MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) in the Local Group Policy Editor. This entry determines whether the automatic logon feature is enabled. (This entry is separate from the Welcome screen feature; if you disable that feature, this entry is not affected.) By default, this entry is not enabled. Automatic logon uses the domain, user name, and password that are stored in the registry to log users on to the computer when the computer starts. The logon dialog box is not displayed.
You can add this registry value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
If you configure a computer for automatic logon, anyone who can physically gain access to the computer can also gain access to everything that is on the computer, including any network or networks that the computer is connected to. Also, if you enable automatic logon, the password is stored in the registry in plain text. The specific registry key that stores this setting is can be read remotely by the Authenticated Users group. As a result, this entry is appropriate only if the computer is physically secured and if you ensure that untrusted users cannot view the registry remotely.
Countermeasure
Do not configure the AutoAdminLogon entry except on highly secure computers, where it should be configured to a value of Disabled.
Potential impact
None. By default this entry is not enabled.
AutoReboot
This entry appears as MSS: (AutoReboot) Allow Windows to automatically restart after a system crash (recommended except for highly secure environments) in the Local Group Policy Editor. It determines whether the computer restarts automatically after it fails.
You can add this registry value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
There is some concern that a computer could get stuck in an endless loop of failures and restarts. However, the alternative to this entry may not be much more appealing—the computer stops running.
Countermeasure
Configure the AutoReboot entry to a value of 0 (disabled).
Potential impact
When this setting is enabled, the computer does not restart automatically after a failure.
AutoShareWks
This entry appears as MSS: (AutoShareWks) Enable Administrative Shares (not recommended except for highly secure environments) in the Local Group Policy Editor. By default, Windows® XP Professional and Windows Vista operating systems automatically create administrative shared folders such as C$ and IPC$.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
Because these built-in administrative shared folders are well-known and present on most Windows computers, malicious users often target them for brute force attacks such as guessing passwords as well as other types of attacks. In Windows Vista, these shared folders are configured by default not to be accessible remotely.
Countermeasure
Do not configure the AutoShareWks entry except on highly secure computers, where it should be configured to a value of 1 (enabled).
Potential impact
If you delete these shared folders, you could cause problems for administrators and programs or services that rely on these shares.
Note
To enable administrative shares to be accessed remotely on Windows Vista or Windows Server 2008, you must modify the registry setting HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System by adding the LocalAccountTokenFilterPolicy value as a DWORD with the setting of 1. We do not recommend this because it decreases the security of your system. However, if you have an operational requirement to access these shared folders remotely, monitor their use and implement additional security measures on the computers with this setting.
DisableSavePassword
This entry appears as MSS: (DisableSavePassword) Prevent the dial-up password from being saved (recommended) in the Local Group Policy Editor. It determines whether the passwords that are associated with dial-up network connection phone book entries are saved. If the user has many phone book entries, accumulated saved passwords can cause a slight delay after the user's credentials are entered in the Connecting To dialog box.
You can add this registry value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
An attacker who steals a mobile user's computer could automatically connect to the organization's network if the Save This Password check box is selected for the dial-up networking entry used to connect to your organization's network.
Countermeasure
Configure the DisableSavePassword entry to a value of 0 (disabled).
Potential impact
Users cannot automatically store their logon credentials for dial-up and VPN connections.
Hidden
This entry appears as MSS: (Hidden) Hide Computer From the Browse List (not recommended except for highly secure environments) in the Local Group Policy Editor. You can configure a computer so that it does not send announcements to browsers on the domain. If you do, you hide the computer from the Network Browser list; it does not announce itself to other computers on the same network.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
An attacker who knows the name of a computer can more easily gather additional information about the computer. If you enable this entry, you remove one method that an attacker might use to gather information about computers on the network. Also, if you enable this entry you can help reduce network traffic. However, the vulnerability is small because attackers can use alternative methods to identify and locate potential targets.
Countermeasure
Do not configure the Hidden entry except on highly secure computers, where it should be configured to a value of 1 (enabled).
Potential impact
The computer does not appear on the Browser list or in Network list on other computers on the same network.
NoDriveTypeAutoRun
This entry appears as MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) in the Local Group Policy Editor. Autorun starts to read from a drive on your computer as soon as media is inserted in it. As a result, the setup file of programs and the sound on audio media starts immediately.
To disable Autorun in all drives, you can add this registry value in the **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\**subkey.
Alternatively, to disable Autorun for CD/DVD drives only, you can add this registry value to the **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cdrom\**subkey.
Possible values:
- A range of hexadecimal values
A value of 0xb5 turns off the AutoRun feature for CD-ROMs. To turn on the AutoRun feature, type 91 in the Value data box, select Hexadecimal, and then click OK.
In the Local Group Policy Editor UI, the following options are available:
Null, allow Autorun
255, disable Autorun for all drives
Not Defined
Vulnerability
An attacker with physical access to the computer could insert an Autorun-enabled DVD or CD into the computer that automatically runs a malicious program.
Countermeasure
Configure the NoDriveTypeAutoRun entry to a value of 255, disable Autorun for all drives.
Potential impact
Autorun does not work when Autorun-enabled discs are inserted into the computer. Also, CD-burning tools might not work as expected because blank CDs are not recognized. Media applications such as Windows Media Player® do not recognize new CDs or DVDs that are inserted, which forces users to manually start them.
NoNameReleaseOnDemand
This entry appears as MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers (Only recommended for servers) in the Local Group Policy Editor. NetBIOS over TCP/IP (NetBT) is a networking protocol that, among other things, provides a way to easily resolve NetBIOS names that are registered on Windows–based computers to the IP addresses that are configured on those computers. This value determines whether the computer releases its NetBIOS name when it receives a name-release request.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
The NetBIOS over TCP/IP (NetBT) protocol does not use authentication and, therefore, is vulnerable to spoofing. Spoofing makes a transmission appear to come from a user other than the user who performed the action. A malicious user could exploit the unauthenticated nature of the protocol to send a name-conflict datagram to a target computer, which would cause the computer to relinquish its name and not respond to queries.
The result of such an attack could be to cause intermittent connectivity issues on the target computer, or even to prevent the use of Network Neighborhood, domain logons, the NET SEND command, or additional NetBIOS name resolution.
Countermeasure
Configure the NoNameReleaseOnDemand entry to a value of 1 (enabled).
Alternatively, you could disable the use of the Windows Internet Name Service (WINS) in your environment, and further ensure that all applications rely upon DNS for name resolution services. Although we recommend this approach as a long-term strategy, it is generally impractical for most organizations to attempt as a short-term solution. Organizations that still run WINS generally have application dependencies that cannot be quickly resolved without upgrades and software rollouts, which require careful plans and significant time commitments.
If you cannot deploy this countermeasure and you want to guarantee NetBIOS name resolution, you can take the additional step of pre-loading NetBIOS names in the LMHOSTS file on certain computers. Maintenance of LMHOSTS files in most environments requires a significant amount of effort. We recommend that you use WINS instead of LMHOSTS.
Potential impact
An attacker could send a request over the network and query a computer to release its NetBIOS name. As with any change that could affect applications, we recommend that you test this change in a non-production environment before you change the production environment.
NtfsDisable8dot3NameCreation
This entry appears as MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) in the Local Group Policy Editor. Windows supports 8.3 file name formats for backward compatibility with 16-bit applications. (The 8.3 file name convention is a naming format that allows file names that are up to eight characters in length, plus a three-character file type.)
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\ subkey.
Possible values:
| Registry value | Corresponding Local Group Policy Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
If you allow 8.3 style file names, an attacker only needs eight characters to refer to a file that may be 20 characters long. For example, a file named Thisisalongfilename.doc could be referenced by its 8.3 file name, Thisis~1.doc. If you do not use 16-bit applications, you can turn this feature off. Also, directory enumeration performance is improved if you disable short-name generation on an NTFS file system partition.
Attackers could use short file names to access data files and applications with long file names that would normally be difficult to locate. An attacker who has gained access to the file system could access data or run applications.
Countermeasure
Configure the NtfsDisable8dot3NameCreation entry to a value of 1 (enabled).
Potential impact
Any 16-bit applications in your organization will not be able to read, write or modify files unless the filename uses the 8.3 format, after the NtfsDisable8dot3NameCreation setting is enabled, those applications will not be able to write any new files. Some 32-bit applications also rely on the presence of short names, because short names tend not to contain embedded spaces and, therefore, do not require quotation marks when used in command lines. The installation routines for some programs may fail.
If you apply this entry to a server that already has files with autogenerated 8.3 file names, it does not remove them. To remove existing 8.3 file names, you must copy those files off the server, delete the files from the original location, and then copy the files back to their original locations.
ScreenSaverGracePeriod
This entry appears as MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) in the Local Group Policy Editor. Windows includes a grace period between the time when the screen saver is started and the time when the console is actually locked automatically if screen-saver locking is enabled.
You can add this registry value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ subkey.
Possible values:
- 0 to 255
The default value is 5 seconds.
In the Local Group Policy Editor UI, the value for this entry appears as a text entry box:
A user-defined number
Not Defined
Vulnerability
The default grace period that is allowed for user movement before the screen saver lock takes effect is five seconds. If you leave the default grace period configuration, your computer is vulnerable to a potential attack from someone who could approach the console and attempt to log on to the computer before the lock takes effect. An entry to the registry can be made to adjust the length of the grace period.
Countermeasure
Configure the ScreenSaverGracePeriod entry to a value of 0.
Potential impact
Users must enter their passwords to resume their console sessions as soon as the screen saver activates.
RestrictRemoteClients
This key enables you to modify the behavior of all RPC interfaces on the system and can be used to eliminate most remote anonymous access to RPC interfaces on the system. When an interface is registered through the RpcServerRegisterIf function, the remote procedure call (RPC) protocol 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. RPC clients that use the named pipe protocol sequence (ncacn_np) are exempt from these restrictions. The named pipe protocol sequence cannot be restricted because of several significant backward-compatibility issues.
This key is located at HKLM\Software\Policies\Microsoft\Windows NT\Rpc\RestrictRemoteClients.
Possible values:
The RestrictRemoteClients registry key can have one of three DWORD values:
0. This value is the default value in Windows Server 2008. It causes the computer to bypass the RPC interface restriction. Imposing appropriate RPC restrictions is entirely the responsibility of the server application. This configuration is equivalent to the configuration of previous versions of Windows operating systems.
1. This value is the default value in Windows Vista. All remote anonymous calls are rejected by the RPC runtime except calls that come in through named pipes (ncacn_np).
2. All remote anonymous calls are rejected by the RPC runtime with no exemptions. In this configuration, a computer cannot receive remote anonymous calls using RPC.
Developers can modify their applications to pass flags to the RPC subsystem that indicate whether the client or server accepts anonymous RPC requests.
Vulnerability
Attackers can potentially use RPC interfaces that allow unauthenticated connections in order to exploit buffer overruns and spread malicious code from a remote location.
Countermeasure
The default value of 0 for the RestrictRemoteClients entry in Windows Server 2008 allows backward compatibility. To add protection against worms that may attempt to exploit buffer overflows in RPC services from remote locations, configure RestrictRemoteClients to 1 or 2.
Potential impact
If you enable the RestrictRemoteClients registry key, the RPC Endpoint Mapper interface is not accessible anonymously. This restriction is a significant security improvement, but it changes how endpoints are resolved. Currently, an RPC client that attempts to make a call by using a dynamic endpoint first queries the RPC Endpoint Mapper on the server to determine what endpoint that it should connect to. This query is performed anonymously, even if the RPC client call uses RPC security. Anonymous calls to the RPC Endpoint Mapper interface fail if the RestrictRemoteClients key is set to 1 or higher. Therefore, the RPC client runtime must be modified to perform an authenticated query to the Endpoint Mapper. If the EnableAuthEpResolution key is set, the RPC client runtime uses NTLM to authenticate to the Endpoint Mapper. This authenticated query takes place only if the actual RPC client call uses RPC authentication.
If you plan to enable this key, you should also use the EnableAuthEpResolution key to enable authentication for the RPC Endpoint Mapper.
Warning
Client computers that do not have the EnableAuthEpResolution key set cannot make RPC service requests of servers that have RestrictRemoteClients enabled. This restriction may cause RPC-based services such as Distributed File System Replication and Cluster Administration to stop working.
If you support applications that make heavy use of the RPC Endpoint Mapper (for example, Exchange MAPI clients) enabling EnableAuthEpResolution will also cause a significant increase in NTLM Authentication load. In this case, you may want to increase the Netlogon registry entry MaxConcurrentAPI to 10. The registry entry needs to be set on all domain member servers and domain controllers along the trust path to the user domain. In addition, you can download a hotfix that will increase the MaxConcurrentAPI limit to 150, which is useful for high-latency servers. For more information about this hotfix, see article 975363.
You should test the use of this key thoroughly in your environment before applying it to identify other applications and services that may not work properly when this key is enabled.
EnableAuthEpResolution
Anonymous calls to the RPC Endpoint Mapper interface fail by default because of the default value for RestrictRemoteClients key. Therefore, the RPC client runtime must be modified to perform an authenticated query to the Endpoint Mapper. To do so, configure the EnableAuthEpResolution key to 1. When this configuration is in place, the RPC client runtime uses NTLM to authenticate to the Endpoint Mapper interface. This authenticated query only takes place if the actual RPC client call uses RPC authentication.
This registry key is located at HKLM\Software\Policies\Microsoft\Windows NT\Rpc\EnableAuthEpResolution.
Vulnerability
RPC interfaces that allow unauthenticated connections can potentially be used by attackers to remotely exploit buffer overruns and spread malicious software.
Countermeasure
To add protection against worms that may attempt to remotely exploit buffer overflows in RPC services, configure RestrictRemoteClients and then use EnableAuthEpResolution to enable NTLM authentication for computer RPC requests.
Potential impact
Clients that do not have the EnableAuthEpResolution key set cannot make RPC service requests of servers that have RestrictRemoteClients enabled. This restriction may cause RPC-based services to stop working. Enabling EnableAuthEpResolution will cause a significant increase in NTLM Authentication load and may require that you increase the Netlogon registry entry MaxConcurrentAPI to 10. The registry entry needs to be set on all domain member servers and domain controllers along the trust path to the user domain. In addition, you can download a hotfix that will increase the MaxConcurrentAPI limit to 150, which is useful for high-latency servers. For more information about this hotfix, see article 975363.
RunInvalidSignatures
By default, Windows Server 2003 with SP1, Windows Server 2008 and Windows Vista prevent the installation of signed code objects that have invalid signatures. These signatures may be invalid because the code has been modified, because the signing certificate has expired, or because the signing certificate appears on a certificate revocation list (CRL).
Vulnerability
A signed Microsoft ActiveX® control that has been tampered with may be downloaded and run by an application, which could compromise the computer on which it runs.
Countermeasure
The default value of RunInvalidSignatures blocks this vulnerability.
Potential impact
Applications that depend on legitimate signed controls do not function if those controls' signatures are invalid for any reason. If you have an application whose signature appears to be invalid, you can change this key configuration to allow the control to download and run. However, doing so creates a security vulnerability. The preferred solution is to contact the developers of the control that is used in the application to obtain a version with a valid signature.
StorageDevicePolicies\WriteProtect
By default, users can mount USB block storage devices on their computers and read from, or write to, these devices without limitation. However, administrators can restrict the ability of users to write to USB block storage devices.
To restrict users' ability to write to these devices, you can add the StorageDevicePolicies key and then add the WriteProtect DWORD value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ registry key and configure it to 1. When this value is configured, the Windows driver for USB block storage devices rejects write requests to mounted USB block storage devices.
Vulnerability
An attacker could copy data to a removable USB device and steal it.
Countermeasure
Configure the WriteProtect value to 1, to prevent the computer from writing data to USB block storage devices.
Potential impact
This registry key provides partial mitigation of a serious threat. However, there are many other ways that a skilled attacker can steal data with a USB device. For example, a USB device can be programmed to enumerate as a non-block storage device (like a printer or CD-ROM device), which bypasses this control. Organizations that want to prevent the theft of sensitive data by users or attackers can use this entry as part of a broader security strategy, in conjunction with physical access controls and other measures to restrict access to writable USB devices.
UseBasicAuth
Distributed Authoring and Versioning (DAV) is an HTTP–based protocol that allows remote access to file systems and file servers. Users can use UNC paths to access resources on DAV servers. In previous releases, the WebDAV redirector communicated with Web servers that support DAV through HTTP and could not use SSL-protected HTTP sessions. When these Web sites allowed the use of basic authentication, DAV requests transmitted the user's authentication credentials in plain text.
In Windows Server 2003 with SP1 and Windows Server 2008, the WebDAV redirector has been modified so that it never sends user credentials with basic authentication. This modification may affect applications or business processes that depend on the computer's default DAV redirector. Microsoft Office uses its own independent DAV client and is not affected by this entry.
This setting can be specified in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\UseBasicAuth subkey. If you configure its value to 1, the computer WebDAV redirector can communicate with Web servers that only support basic authentication.
Vulnerability
An attacker could set up a Web server that uses basic authentication, trick or spoof users, and make them attempt to connect to it to capture their credentials.
Countermeasure
Keep the default setting. By default, the Windows Server 2008 WebDAV redirector does not use basic authentication, which effectively blocks this vulnerability.
Potential impact
Applications that use the built-in WebDAV redirector to access Web resources fail if the Web server supports only basic authentication. To resolve this problem, you can either configure the Web server to support more secure authentication methods or enable the UseBasicAuth value. However, the preferred mechanism is to reconfigure the Web server, which does not allow exposure of users' credentials.
DisableBasicOverClearChannel
The WebDAV redirector is part of the remote file system stack. When users attempt to open URLs on remote computers, their credentials may be exposed if the remote server supports only basic authentication. An attacker may spoof a user and direct them to a Web site that requests credentials (through DAV) and uses basic authentication. If users respond, they expose their credentials to the malicious host.
The UseBasicAuth registry entry controls whether basic authentication can be used for WebDAV requests. If you configure the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\ DisableBasicOverClearChannel value to 1, the use of basic authentication with other Web resources is blocked.
Vulnerability
An attacker could set up a Web server that uses basic authentication trick or spoof users, and make them attempt to connect to it to capture their credentials.
Countermeasure
Configure the DisableBasicOverClearChannel value to 1 on client computers to restrict their ability to connect to HTTP servers by using basic authentication.
Potential impact
Many embedded devices (such as routers, print servers, and copiers) that offer HTTP access support only basic authentication, as do some business applications. When DisableBasicOverClearChannel is configured to 1, client computers cannot authenticate to these devices or applications.
Enable Additional Software Restriction Policies Levels
Additional software restriction policy levels can be enabled for greater flexibility in software restriction policy creation. You can use an additional registry setting to extend the software restriction policies behavior on the computer to make specific applications (or even all applications except for excluded ones) run under basic user privileges, even if the user has administrative privileges. Configure the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\Levels registry key by adding a DWORD with the value of 0x0031000 to enable additional software restriction policy levels.
Vulnerability
Basic users may need to run applications that require membership in the local Administrators group, which represents an inherent escalation of privilege risk. After the user has access to administrative credentials, the data the computer contains or that the computer has rights to access may be inadvertently or consciously compromised.
Countermeasure
After the levels are enabled, you can create a blanket software restriction policy rule to lower rights for all the applications as a default and to create exceptions only for the applications that must have administrative right. To do this, you specify a path rule that requires that all programs that run from the specified drive (such as C:\) be run with the Basic User security level. With this rule in effect, even if a user is logged on with an account that has Administrator privileges, all processes started by the user runwith basic user privileges. If you have programs that run from additional drives, create path rules to restrict those drives to basic user as well. Supplement this rule (or rules) by identifying the programs that must run with higher privileges and then create hash rules that allow those programs to be run with the Unrestricted security level.
Potential impact
With these rules in effect, all programs run on the computer except for those specified by the hash rules that run at the basic user level, regardless of the user account credentials. Any programs that require a higher privilege rule must be explicitly added to the software restriction policy for the computer. For this reason, we recommend that this countermeasure be used only on very tightly controlled, specialized workstations.
This countermeasure does not guarantee that there are not opportunities for escalation of privileges through other means, but it does provide one means of limiting exposure. When making program exceptions, you should carefully consider any processes that can be created by the program that you are allowing to run at a higher privilege level when assessing the risk. For example, a program such as the Microsoft Management Console (mmc.exe) requires higher privilege access but is not a good candidate for adding to the exception list because it encompasses so many other processes and tasks.