Understanding security templates

The following excerpt series from Chapter 5 of "Microsoft Windows Group Policy Guide" by William R. Stanek, Darren Mar-Elia and Derek Melber is provided by Microsoft Press, copyright 2005. Click here to purchase the book.

Understanding security templates

Security templates are text files that are used to organize, configure, and manage security on computers throughout a Windows-based enterprise. These templates are organized into logical sections based on the various categories of security policies on all Windows-based computers. Once a security template is configured, you can use it to configure a single computer or multiple computers on the network. Security templates offer a method for centralizing the configuration and deployment of security configurations to computers.

Security templates are basic text files that are accessed through the Security Templates snap-in using the Microsoft Management Console (MMC), as shown in Figure 5-1.

Figure 5-1: Security Templates snap-in allows quick access to security templates

TABLE OF CONTENTS     Default security templates     Sections of the security template     Tools for accessing, creating and modifying security templates     Using the Security Configuration Wizard

Default security templates

Return to Table of Contents

Windows Server 2003 comes with a number of default security templates that are designed to help meet the needs of different computer security levels and functions. These templates can be used as is, or they can be modified to meet the needs of the computers on your network. All of the default security templates can be found in the C:WindowsSecurityTemplates folder. This following sections describe the default security templates and their functions.

Compatws.inf

The Compatws.inf template relaxes the default permissions for the Users group so that you don't have to make end users members of the Power Users group. Limiting the number of Power Users makes computers more secure when they run legacy applications.

In practice, the default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges and Users have the least. As a result, it is a best practice to put most user accounts in the Users group -- not the Administrators group -- assuming that applications can be successfully run by members of the Users group. For each application that requires more than Users group membership, there are two options: The users can be placed in the Power Users group or the permissions for the Users group can be relaxed to allow the Users group to run the application.

The Compatws.inf security template changes the default file and registry permission for the Users group so that its members can run the application, and it removes the Power Users group from running the application. Because 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.

WARNING   This security template should not be used for domain controllers because it will reduce security dramatically; it is designed for a local SAM, not Active Directory.

DC security.inf

This template is created when a server is promoted to a domain controller. It reflects file, registry, and system service default security settings. Reapplying it resets these areas to the default values, but it might overwrite permissions on new files, registry keys, and system services created by other applications.

Iesacls.inf

The Iesacls.inf template is designed to establish auditing for Registry keys that are associated with Microsoft Internet Explorer. The permissions for these keys are set using the security template to allow the built-in Everyone group Full Control access to the keys. Then, the auditing is configured to track when anyone attempts to modify the values located in the keys.

Securedc.inf

The Secure templates (Secure*.inf) define enhanced security in ways that are least likely to affect application compatibility. The security settings include stronger passwords, lockout, and audit settings. Both Secure templates also 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 further restrict anonymous users by preventing those users (such as users from untrusted domains) from enumerating account names and shares, as well as performing SID-to-name or name-to-SID translations.

IMPORTANT   If the Securedc.inf security template is applied to a domain controller, a user with an account in that domain cannot connect to any member server from a client computer configured to use only LAN Manager authentication when using that domain account.

Securews.inf

This template provides the same configurations as the Securedc.inf template, but it is designed to be applied to clients and member servers. The template enables server-side Server Message Block (SMB) packet signing, which is disabled by default for servers. Because client-side SMB packet signing is enabled by default, SMB packet signing is always negotiated when workstations and servers are operating at the Secure level.

If the Securews.inf security template is applied to a domain member, the following limitations apply:

• All of the domain controllers that contain the accounts of all users who log on to the client must run Microsoft Windows NT 4.0 Service Pack 4 or later.

• If the domain member is joined to a domain that contains domain controllers running Windows NT 4.0, the clocks of the domain controllers running Windows NT 4.0 and the member computers must be within 30 minutes of each other.

• Clients cannot connect to servers that use only the LAN Manager authentication protocol or that run Windows NT 4.0 before Service Pack 4 using a local account defined on the target server.

• Clients cannot connect to servers running Windows 2000 or Windows NT 4.0 using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.

• Clients cannot connect to a computer running Windows XP or later using a local account defined on the target server unless the clock on the target server is within 20 hours of the clock on the client.

• Clients cannot connect to servers configured to use LAN Manager authentication that are running in share-level security mode.

• A user with a local account on a configured server cannot connect to it from a client computer running only LAN Manager that is using that local account.

• A user with a local account on a configured Windows Server 2003 server that is also configured to use NTLMv2 authentication cannot connect unless the clocks on the two machines are within 20 hours of each other.

Hisecdc.inf

The Highly Secure templates (Hisec*.inf) 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 Server Message Block (SMB) clients and servers. For example, the Secure templates cause servers to refuse LAN Manager responses, while the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. The Secure templates enable server-side SMB packet signing, while the Highly Secure templates require it. Also, 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.

If the Hisecdc.inf security template is applied to a domain controller, the following limitations apply to the domain controllers:

• All of the domain controllers in all trusted or trusting domains must run Windows 2000 or Windows Server 2003.

• A user with an account in that domain cannot connect to member servers using that domain user account if the connection is being attempted from a client that uses only the LAN Manager authentication protocol.

• A user with an account in that domain cannot connect to member servers using that domain account unless the client and target server are both running Windows 2000 or later. Users can also use Kerberos-based authentication rather than LAN Manager-based authentication, unless the client is configured to send NTLMv2 responses.

• Lightweight Directory Access Protocol (LDAP) clients cannot bind with the Active Directory LDAP server unless data signing is negotiated. By default, all Microsoft LDAP clients that ship with Windows XP request data signing if Transport Layer Security/Secure Sockets Layer (TLS/SSL) is not already being used. If TLS/SSL is being used, data signing is considered to be negotiated.

Hisecws.inf

The Hisecws.inf template works on the same premise as the Hisecdc.inf template, with some minor modifications. It removes all members of the Power Users group and ensures that only Domain Admins and the local Administrator account are members of the local Administrators group.

If the Hisecws.inf security template is applied to a domain member, the following limitations apply:

• All of the domain controllers that contain the accounts of all users that will log on to the client must be running Windows NT 4.0 Service Pack 4 or later.

• All of the domain controllers for the domain that the client is joined to must be running Windows 2000 or later.

• Clients cannot connect to computers that run only LAN Manager or computers that are running Windows NT 4.0 Service Pack 3 or earlier using a local account defined on the target server.

• Clients cannot connect to servers running Windows 2000 or Windows NT 4.0 Service Pack 4 using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.

• Clients cannot connect to computers running Windows XP or later using a local account defined on the target computer unless the clock on the target computer is within 20 hours of the clock on the client.

• Clients cannot connect to LAN Manager servers operating in share-level security mode.

• A user with a local account on a configured server cannot connect to the server from a client that does not support NTLMv2.

• A client with a local account on a configured server cannot connect to the server unless the client's computer is configured to send NTLMv2 responses.

• All clients that want to use SMB to connect to a configured server must enable client-side SMB packet signing. All computers running Windows 2000 and Windows XP operating systems enable client-side SMB packet signing by default.

Notssid.inf

The Notssid.inf template weakens security to allow older applications to run on Windows Terminal Services. The default file system and registry access control lists (ACLs) that are on servers grant permissions to a Terminal Server security identifier (SID). The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Services 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 SIDs, a better approach is to run Terminal Server in Full Security mode. In this mode, the Terminal Server SID is not used.

Rootsec.inf

The Rootsec.inf template establishes the security for the root of the system drive. The best use of this template is to reapply the root directory permissions if they have been changed accidentally or where the system is broken. The template will not overwrite explicit permissions for any child object; it will only establish permissions for the parent objects, with the default inheritance configuring the child objects.

Setup Security.inf

The Setup Security.inf template is created during installation for each computer. It can vary from computer to computer, depending on whether the installation was a clean installation or an upgrade. This template 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. It can be used on servers and client computers; it cannot be applied to domain controllers. You can apply portions of this template for disaster-recovery purposes.

TIP   Setup Security.inf should never be applied using Group Policy. It contains a large amount of data and can seriously degrade performance if it is applied through Group Policy because policy is periodically refreshed and a large amount of data would move through the domain. It is a best practice to apply the Setup Security.inf template in parts, and the Secedit command-line tool is a good choice for doing this.

CAUTION   The default security templates are meant to be applied to computers that already use the default security settings. You should use these templates to incrementally modify the default security settings you configure on the computers. These security templates do not install the default security settings before performing the modifications. This means you should also test these security templates in a non-production environment to ensure that the right level of application functionality is maintained for your network and system architecture.

Sections of the security template

Return to Table of Contents

A security template has many sections, each with a specific role in protecting, securing, and hardening the computer it will be deployed to. Knowing the role of each section will help you move forward as you decide which security settings to configure for each type of computer in your organization.

Descriptions of the sections within the security template follow, along with some best practices for using them.

Account policies

The Account Policies section controls areas of authentication for user accounts and is configured at the domain policy level. Account Policies has three subsections:

• Password policy    Controls the password for user accounts -- the time period that a password is valid, the length of the password, and the complexity of the password

• Account Lockout policy    Controls how the authenticating computer will behave when incorrect passwords are typed multiple times

• Kerberos policy    Controls the ticketing that the Kerberos authentication protocol uses for domain communication and authorization

Table 5-1 lists some best practices for configuring these settings for domain policy in enterprise client environments -- that is, where client computers are running Windows 2000 Professional or Windows XP Professional and where all domain controllers are running Windows 2000 or later.

MORE INFO   For more information on these recommended domain policy settings in enterprise client environments, and for additional recommendations for configuring these settings in legacy client and high security client environments, refer to the Windows Server 2003 Security Guide. Additional recommendations for securing client computers can be found in the Windows XP Security Guide v2.

Table 5-1   Best-practice account policies settings

Account Policies Settings	Subsection	Best Practice Setting
Enforce Password History	Password Policy	24
Maximum Password Age	Password Policy	42 days
Minimum Password Age	Password Policy	2 days
Minimum Password Length	Password Policy	8
Password Must Meet Complexity Requirements	Password Policy	Enabled
Store passwords using reversible encryption	Password Policy	Disabled
Account Lockout Duration	Account Lockout Policy	30 minutes
Account Lockout Threshold	Account Lockout Policy	50 invalid logon attempts
Reset account lockout counter after	Account Lockout Policy	30 minutes
Any policy settings	Kerberos Policy	Leave at defaults

IMPORTANT   These Account Policy best practices will depend on your network, your corporate security policy, and your overall security needs. Therefore, be sure to consult your security staff before applying these security settings.

Local policies

The Local Policies section of the security template controls the local security settings that reside on each computer. It has three subsections:

• Audit policy   Triggers events to be logged in the Security log that resides in the Event Viewer. Each Audit Policy setting can be set to Log Successful, Failed, or to both types of attempts. There are different categories within the Audit Policy that you can configure. On member servers and workstations that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is enabled for most of the audit policy settings. By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization.

• User rights assignment   Determines what a user or group can do on a server or client. These settings are computer-specific but can be defined through a GPO. In many cases, the default user rights are too open and need to be limited.

• Security options   Enables or disables security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

Table 5-2 lists some best practices for configuring these settings in policy that applies to domain controllers and member servers in enterprise client environments -- that is, where client computers are running Windows 2000 Professional or Windows XP Professional and where all domain controllers are running Windows 2000 or later.

MORE INFO   For more information on these recommended settings in enterprise client environments, and for additional recommendations for configuring these settings in legacy client and high security client environments, refer to the Windows Server 2003 Security Guide. Additional recommendations for securing client computers can be found in the Windows XP Security Guide v2.

NOTE   The Local Policies section has nearly 75 security option settings. Table 5-2 lists best practice settings for only the settings that are very important for most computers on the network. For more information on all recommended settings as well as recommended values, refer to the Security Template snap-in and Security Configuration Wizard and the appropriate files that these tools generate. For help on this procedure, refer to Chapter 15 in this book. Also see the sections later in this chapter on