Microsoft KB Archive/885409

= Security configuration guidance support =

Article ID: 885409

Article Last Modified on 10/11/2007

-

APPLIES TO


 * Windows Vista Ultimate
 * Windows Vista Business
 * Windows Vista Enterprise
 * Microsoft Windows Server 2003, Standard Edition (32-bit x86)
 * Microsoft Windows Server 2003, Enterprise Edition
 * Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
 * Microsoft Windows Server 2003, Web Edition
 * Microsoft Windows Server 2003, Standard x64 Edition
 * Microsoft Windows Server 2003, Enterprise x64 Edition
 * Microsoft Windows Server 2003, Datacenter x64 Edition
 * Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
 * Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
 * Microsoft Windows XP Professional
 * Microsoft Windows XP Tablet PC Edition 2005
 * Microsoft Windows XP Tablet PC Edition
 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 MultiLanguage Edition
 * Microsoft Windows 2000 Professional Edition
 * Microsoft Windows 2000 MultiLanguage Edition
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Datacenter Server
 * Microsoft Windows 2000 Datacenter Server

-



SUMMARY
Microsoft, the Center for Internet Security (CIS), the National Security Agency (NSA), the Defense Information Systems Agency (DISA), and the National Institute of Standards and Technology (NIST) have published &quot;security configuration guidance&quot; for Microsoft Windows. ''

The high security levels that are specified in some of these guides may significantly restrict functionality of a system. Therefore, you should perform significant testing before you deploy these recommendations. We recommend that you take additional precautions when you do the following:''
 * Edit access control lists (ACLs) for files and registry keys
 * Enable Microsoft network client: Digitally sign communications (always)
 * Enable Network security: Do not store LAN Manager hash value on next password change
 * Enable System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
 * Disable Automatic Update service or Background Intelligent Transfer Service (BITS)
 * Disable NetLogon service
 * Enable NoNameReleaseOnDemand

''Microsoft strongly supports industry efforts to provide security guidance for deployments in high security areas. However, you must thoroughly test the guidance in the target environment. If you require additional security settings beyond the default settings, we highly recommend that you see the Microsoft-issued guides. These guides can serve as a starting point for your organization's requirements. For support or questions regarding third-party guides, contact the organization that issued the guidance.''



Introduction
Over the past several years, a number of organizations, including Microsoft, the Center for Internet Security (CIS), the National Security Agency (NSA), the Defense Information Systems Agency (DISA), and the National Institute of Standards and Technology (NIST), have published &quot;security configuration guidance&quot; for Windows. As with any security guidance, the additional security that is required frequently has an adverse effect on usability.

Several of these guides, including the ones from Microsoft, CIS, and NIST, contain multiple levels of security settings. These guides may include levels designed for the following:
 * Interoperability with older operating systems
 * Enterprise environments
 * Enhanced security that provides limited functionality

Note This level is frequently referred to as the Specialized Security-Limited Functionality level or the High Security level.

The High Security, or Specialized Security-Limited Functionality, level is designed specifically for extremely hostile environments under significant risk of attack. This level guards information of the highest possible value, such as information that is required by some government systems. The High Security level of most of this public guidance is inappropriate for the vast majority of systems that are running Windows. We recommend that you do not use the High Security level on general-purpose workstations. We recommend that you use the High Security level only on systems where compromise would cause the loss of life, the loss of extremely valuable information, or the loss of lots of money.

Several groups worked with Microsoft to produce these security guides. In many cases, these guides all address similar threats. However, each guide differs slightly because of legal requirements, local policy, and functional requirements. Because of this, the settings may vary from one set of recommendations to the next. The &quot;Organizations that produce publicly available security guidance&quot; section contains a summary of each security guide.



Microsoft Corporation
Microsoft provides guidance for how to help secure our own operating systems. We have developed the following three levels of security settings:
 * Enterprise Client (EC)
 * Stand-Alone (SA)
 * Specialized Security – Limited Functionality (SSLF)

We thoroughly tested this guidance for use in many different customer scenarios. The guidance is appropriate for any organization that wishes to help secure its Windows computers.

We fully support our guides because of the extensive testing that we have conducted in our application compatibility laboratories on those guides. Visit the following Microsoft Web sites to download our guides:  Windows Vista Security Guide:

http://go.microsoft.com/?linkID=5744573

 Windows XP Security Guide:

http://go.microsoft.com/fwlink/?LinkId=14839

 Windows Server 2003 Security Guide:

http://go.microsoft.com/fwlink/?linkid=14845

 Windows 2000 Security Hardening Guide:

http://go.microsoft.com/fwlink/?LinkId=28591



If you experience issues or have comments after you implement the Microsoft Security Guides, you can provide feedback by sending an e-mail message to [mailto:secwish@microsoft.com secwish@microsoft.com].

The Center for Internet Security
CIS has developed benchmarks that are designed to provide information that helps organizations make informed decisions about certain available security choices. CIS has provided three levels of security benchmarks:
 * Legacy
 * Enterprise
 * High Security

If you experience issues or have comments after you implement the CIS benchmark settings, contact CIS by sending an e-mail message to [mailto:win2k-feedback@cisecurity.org win2k-feedback@cisecurity.org].

Note CIS's guidance has changed since we originally published this article (November 3, 2004). CIS's current guidance resembles the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the &quot;Microsoft Corporation&quot; section earlier in this article.

The National Institute of Standards and Technology
NIST is responsible for creating security guidance for the United States Federal Government. NIST has created four levels of security guidance that are used by the United States Federal Agencies, private organizations, and public organizations:
 * SoHo
 * Legacy
 * Enterprise
 * Specialized Security–Limited Functionality

If you experience issues or have comments after you implement the NIST security templates, contact NIST by sending an e-mail message to [mailto:itsec@nist.gov itsec@nist.gov].

Note NIST's guidance has changed since we originally published this article (November 3, 2004). NIST's current guidance resembles the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the &quot;Microsoft Corporation&quot; section earlier in this article.

The Defense Information Systems Agency
DISA creates guidance specifically for use in the DOD. United States DOD users who experience issues or have comments after they implement the DISA configuration guidance can provide feedback by sending an e-mail message to [mailto:fso_spt@ritchie.disa.mil fso_spt@ritchie.disa.mil].

Note DISA's guidance has changed since we originally published this article (November 3, 2004). DISA's current guidance is similar or identical to the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the &quot;Microsoft Corporation&quot; section earlier in this article.ration&quot; section earlier in this article.

The National Security Agency (NSA)
The NSA has produced guidance to help secure high-risk computers in the United States Department of Defense. The NSA has developed a single level of guidance that corresponds approximately with the High Security level that is produced by other organizations.

If you experience issues or have comments after you implement the NSA Security Guides for Windows XP, you can provide feedback by sending an e-mail message to [mailto:XPGuides@nsa.gov XPGuides@nsa.gov]. To provide feedback on the Windows 2000 guides, send an e-mail message to [mailto:w2kguides@nsa.gov w2kguides@nsa.gov].

Note NSA's guidance has changed since we originally published this article (November 3, 2004). NSA's current guidance is similar or identical to the guidance that Microsoft provides. For more information about the guidance that Microsoft provides, read the &quot;Microsoft Corporation&quot; section earlier in this article.ration&quot; section earlier in this article.

Security guidance issues
As mentioned earlier in this article, the high security levels that are described in some of these guides were designed to significantly restrict the functionality of a system. Because of this restriction, you should thoroughly test a system before you deploy these recommendations.

Note The security guidance that is provided for the Legacy, SoHo, or Enterprise levels has not been reported to severely affect system functionality. This Knowledge Base article is primarily focused on the guidance that is associated with the highest security level.

We strongly support industry efforts to provide security guidance for deployments in high security areas. We continue to work with security standards groups to develop useful hardening guidance that has been fully tested. Security guidelines from third-parties are always issued with strong warnings to fully test the guidelines in target high security environments. However, these warnings are not always heeded. Make sure that you thoroughly test all security configurations in your target environment. Security settings that differ from those that we recommend may invalidate the application compatibility testing that is performed as part of the operating system testing process. Additionally, we and third-parties specifically discourage applying the draft guidance in a live production environment, instead of in a test environment.

The high levels of these security guides include several settings that you should carefully evaluate before you implement them. Although these settings may provide additional security benefits, the settings may have an adverse effect on the usability of the system.

File system and registry access control list modifications
Windows Vista, Microsoft Windows XP, and Microsoft Windows Server 2003 have significantly tightened permissions throughout the system. Therefore, extensive changes to default permissions should not be necessary.

Additional ACL changes may invalidate all or most of the application compatibility testing that is performed by Microsoft. Frequently, changes such as these have not undergone the in-depth testing that Microsoft has performed on other settings. Support cases and field experience has shown that ACL edits change the fundamental behavior of the operating system, frequently in unintended ways. These changes affect application compatibility and stability and reduce functionality, both with regard to performance and capability.

Because of these changes, we do not recommend that you modify file system ACLs on files that are included with the operating system on production systems. We recommend that you evaluate any additional ACL changes against a known threat to understand any potential advantages the changes may lend to a specific configuration. For these reasons, our guides make only very minimal ACL changes and only to Windows 2000. For Windows 2000, several minor changes are required. These changes are described in the Windows 2000 Security Hardening Guide.

Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults, you cannot roll back the original ACLs.

Changes to the ACL in the %SystemDrive% folder may cause the following scenarios:
 * The Recycle Bin no longer functions as designed, and files cannot be recovered.
 * A reduction of security that lets a non-administrator view the contents of the administrator’s Recycle Bin.
 * The failure of user profiles to function as expected.
 * A reduction of security that provides interactive users with read access to some or to all user profiles on the system.
 * Performance problems when many ACL edits are loaded into a Group Policy object that includes long logon times or repeated restarts of the target system.
 * Performance problems, including system slowdowns, every 16 hours or so as Group Policy settings are reapplied.
 * Application compatibility problems or application crashes.

To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, currently, you cannot roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting the hard disk drive and by reinstalling the operating system.

For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

Microsoft network client: Digitally sign communications (always)
When you enable this setting, clients must sign Server Message Block (SMB) traffic when they contact servers that do not require SMB signing. This makes clients less vulnerable to session hijacking attacks. It provides significant value, but without enabling a similar change on the server to enable Microsoft network server: Digitally sign communications (always) or Microsoft network client: Digitally sign communications (if client agrees), the client will be unable to communicate successfully with the server.

Network security: Do not store LAN Manager hash value on next password change
When you enable this setting, the LAN Manager (LM) hash value for a new password will not be stored when the password is changed. The LM hash is relatively weak and prone to attack compared with the cryptographically stronger Microsoft Windows NT hash. While this setting provides extensive additional security to a system by preventing many common password cracking utilities, the setting can prevent some applications from starting or running correctly.

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
When you enable this setting, Internet Information Services (IIS) and Microsoft Internet Explorer use only the Transport Layer Security (TLS) 1.0 protocol. If this setting is enabled on a server that is running IIS, only Web browsers that support TLS 1.0 can connect. If this setting is enabled on a Web client, the client can connect only to servers that support the TLS 1.0 protocol. This requirement may affect a client’s ability to visit Web sites that use Secure Sockets Layer (SSL). For more information, click the following article number to view the article in the Microsoft Knowledge Base:

811834 Cannot visit SSL sites after you enable FIPS compliant cryptography

Additionally, when you enable this setting on a server that uses Terminal Services, clients are forced to use the RDP client 5.2 or later versions to connect.

Automatic Update service or Background Intelligent Transfer Service (BITS) is disabled
One of the key pillars of the Microsoft security strategy is to make sure that systems are kept current on updates. A key component in this strategy is the Automatic Updates service. Both Windows Update and Software Update services use the Automatic Updates service. The Automatic Updates service relies on the Background Intelligent Transfer Service (BITS). If these services are disabled, the computers will no longer be able to receive updates from Windows Update through Automatic Updates, from Software Update services (SUS), or from some Microsoft Systems Management Server (SMS) installations. These services should only be disabled on systems that have an effective update distribution system that does not rely on BITS.

NetLogon service is disabled
If you disable the Net Logon service, a workstation no longer functions reliably as a domain member. This setting may be appropriate for some computers that do not participate in domains, but should be carefully evaluated before deployment.

NoNameReleaseOnDemand
This setting prevents a server from relinquishing its NetBIOS name if it conflicts with another computer on the network. This setting is a good preventive measure for denial of service attacks against name servers and other critical server roles.

When you enable this setting on a workstation, the workstation refuses to relinquish its NetBIOS name even if the name conflicts with the name of a more important system, such as a domain controller. This scenario can disable important domain functionality. Microsoft strongly supports industry efforts to provide security guidance that is targeted to deployments in high security areas. However, this guidance must be thoroughly tested in the target environment. We highly recommend that system administrators who require additional security settings beyond the default settings use the Microsoft-issued guides as a starting point for their organization's requirements. For support or for questions about third-party guides, contact the organization that issued the guidance.

