The predefined security templates are provided as a starting point for creating security policies that are customized to meet different organizational requirements. You can customize the templates with the Security Templates snap-in. Once you customize the predefined security templates, you can use them to configure an individual computer or thousands of computers. You can configure individual computers with the Security Configuration and Analysis snap-in, the Secedit.exe command prompt tool, or by importing the template into Local Security Policy You can configure multiple machines by importing a template into Security Settings, which is an extension to Group Policy. You can also use a security template as a baseline for analyzing a system for potential security holes or policy violations by using the Security Configuration and Analysis snap-in. By default, the predefined security templates are stored in:
systemroot\Security\Templates
| • | Default security (Setup security.inf) Setup security.inf is a computer-specific template that represents the default security settings that are applied during installation of the operating system, including the file permissions for the root of the system drive. You can use this template, or portions of it can be used for disaster recovery purposes. Setup security.inf should never be applied using Group Policy. | ||||||||||||||||||||
| • | Compatible (Compatws.inf) Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges while Users have the least. Because of this, you can significantly improve the security, reliability, and total cost of system ownership by:
People with User privileges can successfully run applications that take part in the Certified for Windows program. However, you probably cannot run applications that are not certified in a User context. If non-certified applications must be supported, there are two options:
Since Power Users have inherent capabilities, such as creating users, groups, printers and shares, some administrators would rather relax the default User permissions than allow end-users to be members of the Power Users group. This is precisely what the Compatible template is for. The Compatible template changes the default file and registry permissions that are granted to Users in a manner that is consistent with the requirements of most non-certified applications. Additionally, since it is assumed that the administrator that is applying the Compatible template does not want end users to be Power Users, the Compatible template also removes all members of the Power Users group. For more information, see Default security settings For more information on the Certified for Windows Program, see the Microsoft Web site. The Compatible template should not be applied to domain controllers. For example, do not import the Compatible template to the Default Domain policy or Default Domain Controller policy. | ||||||||||||||||||||
| • | Secure (Secure*.inf) The Secure templates define enhanced security settings that are least likely to impact application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings. Additionally, the Secure templates limit the use of LAN Manager and NTLM authentication protocols by configuring clients to send only NTLMv2 responses and configuring servers to refuse LAN Manager responses.
The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (such as users from untrusted domains) from:
Finally, the Secure templates enable server-side SMB packet signing, which is disabled by default for workstations and servers. Since client-side SMB packet signing is enabled by default, SMB packet signing is always be negotiated when workstations and servers are operating at the Secure level. | ||||||||||||||||||||
| • | Highly Secure (hisec*.inf) The Highly Secure templates are supersets of the secure templates that impose further restrictions on the levels of encryption and signing that are required for authentication and for the data that flows over secure channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LAN Manager responses, the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. While the Secure template enables server-side SMB packet signing, the Highly Secure template requires it. Additionally, the Highly Secure templates require strong encryption and signing for the secure channel data that constitutes domain-to-member and domain-to-domain trust relationships.
Clients that do not support NTLMv2 include Windows for Workgroups, Windows NT clients prior to Service Pack 4, and Windows 95 and Windows 98 platforms that do not have the DS Client Pack installed. In addition to further restrictions on the use of LAN Manager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the Highly Secure templates also limit the use of cached logon data, such as data stored by Winlogon and Stored User Names and Passwords. Finally, Hisecws.inf uses restricted group settings to:
Hisecws defines these group restrictions under the assumption that only applications that are certified for Windows 2000 are deployed. With certified applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can run certified applications successfully under the secure context of a normal User which is defined by the default security settings of the file system and registry. | ||||||||||||||||||||
| • | System root security (Rootsec.inf) Rootsec.inf specifies the new root permissions introduced with Windows XP Professional. By default, Rootsec.inf defines these permissions for the root of the system drive. This template can be used to reapply the root directory permissions if they are inadvertently changed, or the template can be modified to apply the same root permissions to other volumes. As specified, the template does not overwrite explicit permissions that are defined on child objects; it propagates only the permissions that are inherited by child objects. | ||||||||||||||||||||
| • | No Terminal Server user SID (Notssid.inf) The default file system and registry access control lists that are on servers grant permissions to a Terminal Server SID. The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not being used, this template can be applied to remove the unnecessary Terminal Server SIDs from the file system and registry locations. However, removing the access control entry for the Terminal Server SID from these default file system and registry locations does not increase the security of the system. Instead of removing the Terminal Server SID, simply run Terminal Server in Full Security mode. When running in Full Security mode, the Terminal Server SID is not used. |
| • | These security templates are constructed with the assumption that they will be applied to computers that use the default security settings. In other words, these templates incrementally modify the default security settings, if they are on the computer. They do not install the default security settings before performing the modifications. |
| • | Predefined security templates should not be applied to production systems without testing to ensure that the right level of application functionality is maintained for your network and system architecture. |
Security template settings can be viewed through Security Templates. The *.inf files can also be viewed as text files. These files are located in:
%windir%\Security\Templates
You cannot secure Windows XP Professional systems that are installed on FAT file systems.
Customize a predefined security template
Apply a security template to local policy
Import a security template to a Group Policy object