다음을 통해 공유

Predefined security templates

  • 아티클

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

Predefined security templates

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 security on an individual computer or thousands of computers. You can configure individual computers with the Security Configuration and Analysis snap-in, the Secedit command-line tool, or by importing the template into Local Security Policy. You can configure multiple machines by importing a template into Security Settings extension to Group Policy, 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)

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

    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 advisable to apply the Setup security.inf template in parts. Since the Secedit command-line tool gives you this option, it is advisable to use it.

    For more information, see Automating security configuration tasks.

  • Domain controller default security (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 may overwrite permissions on new files, registry keys and system services created by other applications. It can be applied using the Security Configuration and Analysis snap-in or the Secedit command-line tool.

  • 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:

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

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

    People with User privileges can successfully run applications that take part in the Windows Logo program for Software. However, Users may 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:

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

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

    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 applications that do not belong to the Windows Logo program for Software. 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 groups.

    For more information on the Windows Logo program for Software, 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.

    • In order to apply Securews.inf to a member computer, all of the domain controllers that contain the accounts of all users that log on to the client must run Windows NT 4.0Service Pack 4 or higher.

    • In order to apply Securews.inf to a member computer that is joined to a domain which contains domain controllers running Windows NT 4.0, the clocks between the domain controllers running Windows NT 4.0and the member computers must be within 30 minutes of each other.

    • If a client is configured with Securews.inf, it will not be able to connect to servers that only use the LAN Manager authentication protocol or that run Windows NT 4.0prior to Service Pack 4 using a local account defined on the target server.

    • If a client is configured with Securews.inf, it will not be able to connect to servers running Windows 2000or Windows NT 4.0using 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.

    • If a client is configured with Securews.inf, it will not be able to connect to a computer running Windows XPor above 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.

    • If a client is configured with Securews.inf, then it will not be able to connect to servers running LAN Manager that are running in share-level security mode.

    • If a server is configured with Securews.inf, then a user with a local account on that server will not be able to connect to it from a client computer running only LAN Manager that is using that local account.

    • If a server running Windows 2000is configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two machines are within 30 minutes of each other.

    • If a server running Windows XPis configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two machines are within 20 hours of each other.

    • If a domain controller is configured with Securedc.inf, then a user with an account in that domain will not be able to connect to any member server from a client computer running only LAN Manager using that domain account.

    • Computers that run LAN Manager include Windows for Workgroupsas well as Windows 95and Windows 98platforms that do not have the Active Directory Client Extensions Pack installed. If the Active Directory Client Extensions Pack is installed on Windows 95or Windows 98, then those clients will be able to use NTLMv2. Windows Millinnium Editionsupports NTLMv2 without additional modification.

    • Computers that run Windows NTService Pack 4 or higher can be configured to send only NTLMv2 responses by setting HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel to equal 3 or higher.

    • Computers that run Windows NTService Pack 4 or higher can be configured to send only NTLMv2 responses by specifying this preference in the Network security: LAN Manager authentication level security option.

    The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (such as users from untrusted domains) from:

    • Enumerating account names and shares.

    • Performing SID-to-name or name-to-SID translations.

    Finally, the Secure templates enable server-side Server Message Block (SMB) packet signing, which is disabled by default for servers. Since client-side SMB packet signing is enabled by default, SMB packet signing will 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. relationships. Thus, in order to apply hisecws.inf to a member machine:

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

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

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

    • Clients that are configured with Hisecws.inf cannot connect to servers running Windows 2000or Windows NT 4.0Service 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 that are configured with Hisecws.inf cannot connect to computers running Windows XPor above 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 that are configured with Hisecws.inf cannot connect to LAN Manager servers operating in share-level security mode.

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

    • If a server is configured with Hisecws.inf, then a user with a local account on that server will not be able to connect to it from a client that does not support NTLMv2.

    • If a server is configured with Hisecws.inf, then a client with a local account on that server will not be able to connect to the server unless the client's computer is configured to send NTLMv2 responses.

    • If a server is configured with Hisecws.inf, then all clients that want to use SMB to connect to that server must enable client-side SMB packet signing. All computers running Windows 2000and Windows XPoperating systems enable client-side SMB packet signing by default.

    • If a domain controller is configured with Hisecdc.inf, then 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 only uses the LAN Manager authentication protocol.

    • If a domain controller is configured with Hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers using that domain account unless:

Both the client and target server are running Windows 2000or above and can use Kerberos-based authentication rather than LAN Manager-based authentication.

The client is configured to send NTLMv2 responses.

  • If a domain controller is configured with Hisecdc.inf, then Lightweight Directory Access protocol (LDAP) clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. BIND requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XPwill request data signing if Transport Layer Security/Secure Sockets Layer (TLS/SSL) is not already being used. If TLS/SSL is being used, then data signing is considered to be negotiated.

  • Clients that do not support NTLMv2 include Windows for Workgroups, Windows NTclients prior to Service Pack 4, and Windows 95and Windows 98platforms that do not have the Active Directory Client Extensions Pack installed.

  • Computers that run Windows NTService Pack 4 or higher can be configured to send only NTLMv2 responses by setting HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel=3 or higher.

  • Computers that run Windows 2000or higher can be configured to send only NTLMv2 responses by specifying this preference in the Network security: LAN Manager authentication level security option.

    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:

    • Remove all members of the Power Users group.

    • Ensure that only Domain Admins 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 for Software. With those applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can run those applications successfully under the secure context of a normal member of the Users group, which is defined by the default security settings of the file system and registry. Members of the Administrators group can still use any application that they want.

    For information about the Windows Logo program for Software, see the Windows Logo program for Software page at the Microsoft Web site.

  • System root security (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.

  • 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 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 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.

  • Internet Explorer (iesacls.inf)

    The iesacls.inf template allows you to audit Internet Explorer use. This can be useful in conjunction with a plan to regularly review the event logs.

  • Optional Components (ocfiles*.inf)

    These templates from previous Windows versions are no longer used or needed. Setup Security.inf replaces them.

Caution

  • 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 Professionalsystems that are installed on file allocation table (FAT) file systems.

For more information, see Customize a predefined security template, Import a security template to a Group Policy object, Configure local computer security, and Reapply default security settings.