Selecting Predefined Security Templates

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Windows Server 2003 includes a set of predefined security templates that you can use to create customized security policies. You can customize the templates by using the Security Templates snap-in. It is recommended that you save one of the predefined templates under another name, and then modify it to meet the needs of your organization. You can use a template to configure either a single computer or an entire domain. You can also use a security template — with the Security Configuration and Analysis snap-in — as a baseline for analyzing the local computer for potential security problems or policy violations.

The default storage location of the predefined security templates is %systemroot%\Security\Templates. Only administrators have permissions to modify the templates in this folder; users without administrative permissions can save their templates to another folder. This folder includes the following templates.

Setup Security.inf

Setup security.inf is a computer-specific template that represents the default security settings that are applied when the operating system is installed, including the file permissions for the root of the system drive.

The Setup security.inf template is created for each computer during installation. It can vary from computer to computer and is based on whether the installation was a clean installation or an upgrade. This template 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.

Do not apply Setup security.inf using Group Policy. It contains a large amount of data and can seriously degrade performance if it is applied by using Group Policy. Degraded performance can occur because policy is periodically refreshed, and a large amount of data then moves through the domain.

It is recommended that you apply the Setup security.inf template in parts by using the Secedit command-line tool. For more information about Secedit, see "Secedit" in Help and Support Center for Windows Server 2003.

DC Security.inf

This template is created when Active Directory is installed onto a server. It reflects file, registry, and system service default security settings. Reapplying this template resets these settings to default values. Note that this template might overwrite permissions on new files, registry keys, and system services that are created by other applications. It can be applied by using the Security Configuration and Analysis snap-in or the Secedit command-line tool.

Compatws.inf

Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Of the three, the Administrators group has the most permissions, while the Users group has the least. Because of this, you can significantly improve security, reliability, and the total cost of system ownership by:

  • Making sure that end users are members of the Users group.

  • Deploying applications that can be run successfully by members of the Users group.

Members of the Users group can successfully run applications that are a part of the Windows Logo Program. However, members of the Users group might not be able to run applications that do not meet the requirements of the program. If other applications must be supported, there are two options:

  • Permit members of the Users group to be members of the Power Users group.

  • Relax the default permissions that are granted to the Users group.

Because Power Users have additional permissions such as creating users, groups, printers, and shares, some administrators prefer to relax the default User permissions instead of permitting members of the Users group 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 the Users group in a way that is consistent with the requirements of most applications that do not belong to the Windows Logo Program. Additionally, because it is assumed that the administrator who is applying the Compatible template does not want members of the Users group to be Power Users, the Compatible template also removes all members of the Power Users group. For more information, see "Default security settings for groups" in Help and Support Center for Windows Server 2003.

For more information about the Windows Logo Program for Software, see the Windows Logo Program for Software link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Do not apply the Compatible template to domain controllers. For example, do not import the Compatible template to the Default Domain GPO or the Default Domain Controllers GPO.

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.

The Secure templates prevent anonymous users, such as users from untrusted domains, from:

  • Enumerating account names and shares.

  • Performing SID-to-name or name-to-SID translations. If this is allowed, anonymous users can request user names (such as the administrator’s user name) based on the user’s security ID (SID) as well as requesting the SID for a user based on the user name.

The Secure templates enable server-side server message block (SMB) packet signing. By default, SMB packet signing is disabled for member 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.

Additionally, the Secure templates limit the use of LAN Manager and NTLM authentication protocols by configuring clients to send only NTLM version 2 (NTLMv2) responses and by configuring servers to refuse LAN Manager responses.

Considerations for applying Securews.inf to a member computer include:

  • All domain controllers that contain the accounts of all users that log on to the client must run Windows NT 4.0 Service Pack 4 (SP4) or later, Windows 2000, or Windows Server 2003.

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

If a client is configured with Securews.inf, it cannot connect to:

  • Servers that only use the LAN Manager authentication protocol or that run Windows NT 4.0 Service Pack 3 (SP3) or earlier using a local account that is defined on the target server.

  • Servers running Windows 2000 SP3 and earlier or Windows NT 4.0 using a local account that is defined on the target server unless the clock on the target server is set within 30 minutes of the clock on the client.

  • Computers running Windows XP by using a local account that is defined on the target computer unless the clock on the target computer is set within 36 hours of the clock on the client.

  • Servers running LAN Manager that are running in share-level security mode.

If a server is configured with Securews.inf:

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

  • For Windows 2000 SP3 and earlier, a client using a local account on the server that is also configured to use NTLMv2 authentication cannot connect unless the clocks on the two computers are set within 30 minutes of each other.

Likewise, if a domain controller is configured with Securedc.inf, a user who has an account in that domain cannot connect to any member server from a client computer that is running only LAN Manager using that domain account.

You can configure computers running Windows NT SP4, Windows 2000, Windows XP, or Windows Server 2003 to send only NTLMv2 responses by doing at least one of the following:

  • Specify this preference in the Network security: LAN Manager Authentication Level security option.

  • Set HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel to 3 or higher.

    Caution

Computers that run LAN Manager include Windows for Workgroups and Microsoft® Windows® 95 and Microsoft® Windows® 98 platforms that do not have the Active Directory Client Extensions Pack installed. If the Active Directory Client Extensions Pack is installed on Windows 95 or Windows 98, those clients can use NTLMv2. Microsoft® Windows® Millennium Edition supports NTLMv2 without additional modification.

Hisec*.inf

The Highly Secure templates are supersets of the Secure templates that require greater levels of encryption and signing for authentication and for the data that flows over secure channels and between SMB clients and servers. For example, the Secure templates cause servers to refuse LAN Manager responses; the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. The Secure template enables server-side SMB packet signing; the Highly Secure template requires it.

The Highly Secure templates limit the use of cached logon data, such as data stored by Winlogon and Stored User Names and Passwords.

Hisecws.inf uses Restricted Group settings to:

  • Remove all members of the Power Users group.

  • Make sure that only the Domain Admins group and the local Administrator account are members of the local Administrators group.

Hisecws.inf defines these group restrictions under the assumption that users only use applications that belong to the Windows Logo Program. When using those applications, neither the Compatible template nor the Power Users group is needed. Instead, users can run those applications successfully under the secure context of a member of the Users group. The Users group is defined by the default security settings of the file system and registry. Members of the Administrators group can still use any application.

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. Thus, consideration for applying Hisecws.inf to a member computer include:

  • All of the domain controllers that contain the accounts of all users that can log on to the client must be running Windows NT 4.0 SP4 or later, Windows 2000, or Windows Server 2003.

  • All of the domain controllers for the domain that the client is joined to must run Windows 2000 or Windows Server 2003.

Clients that are configured with Hisecws.inf cannot connect to:

  • Computers that only run LAN Manager or computers running Windows NT 4.0 SP3 or earlier using a local account defined on the target server.

  • Servers running Windows 2000 SP3 and earlier or Windows NT 4.0 SP4 using a local account that is defined on the target server unless the clock on the target server is set within 30 minutes of the clock on the client.

  • Computers running Windows XP using a local account that is defined on the target computer unless the clock on the target computer is set within 36 hours of the clock on the client.

  • LAN Manager servers that are operating in share-level security mode.

To apply Hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must run Windows 2000 or Windows Server 2003 operating systems.

If a server is configured with Hisecws.inf:

  • A user who has a local account on that server cannot connect to that server from a client that does not support NTLMv2.

  • A client that has a local account on that server cannot connect to that server unless the client is configured to send NTLMv2 responses.

  • All clients that want to use SMB to connect to the server must enable client-side SMB packet signing. By default, all clients running Windows 2000 and Windows XP operating systems enable client-side SMB packet signing.

If a domain controller is configured with Hisecdc.inf:

  • If a user attempts to connect to member servers by using a domain account in the same domain, the connection will fail if the user’s client only uses the LAN Manager authentication protocol.

  • LDAP clients cannot bind with the Active Directory LDAP server unless data signing is negotiated. LDAP BIND requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients included 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 negotiated.

  • A user who has an account in that domain cannot connect to member servers by using that domain account unless:

    • Both the client and target server are running Windows 2000, Windows XP, or Windows Server 2003, and both can use Kerberos-based authentication instead of LAN Manager-based authentication.

    • The client is configured to send NTLMv2 responses.

Rootsec.inf

Rootsec.inf specifies the root permissions. 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.

Notssid.inf

The default file system and registry ACLs on servers assign 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 Server is not being used, this template can be applied to remove the Terminal Server SIDs that are not necessary from the file system and registry locations. However, removing the access control entry (ACE) 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, run Terminal Server in Full Security mode. When you run Terminal Server in Full Security mode, the Terminal Server SID is not used.