Managing Security Templates

The Security Template snap-in is a tool for defining security templates that can then be applied to a Group Policy object to define system security settings. For general, conceptual security information, see Security.

  • Before proceeding, see Checklist: Defining a security template for a Group Policy object or Checklist: Defining a security template for a local computer.
  • For help with specific tasks, see How To ....
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.
  • For detailed information on individual security parameters, consult the Windows 2000 Resource Kit.


Checklist: Defining a security template for a Group Policy object

Step | Reference
Start the Security Templates snap-in | Start Security Templates
Define a security template which meets the context of the Group Policy object to which it will be applied. | Define a security template
Import the security template to Group Policy. | Import a security template to Group Policy


Checklist: Defining a security template for a local computer

Step | Reference
Start the Security Templates snap-in | Start Security Templates
Define a security template which meets the context of the local computer to which the template will be applied. | Define a security template
Apply the security template to the local computer policy. | Apply a security template to a local computer


Best practices

This section relates specifically to Security Templates. For general security issues, see Best Practices for Security.

  • Account policies should not be configured for organizational units that do not contain any computers, since organizational units that contain only users will always receive account policy from the domain.
  • When setting account policies in Active Directory, keep in mind that Windows 2000 only allows one domain account policy: the account policy applied at the root domain of a domain tree. For more information, see Account policies.
  • When upgrading Windows 2000 Professional on computers that are members of a Windows 2000 domain, the account and password policies will take precedence over the local policy on any domain controllers, servers, and workstations in the domain. This is different from upgrade behavior in previous versions of Windows.
  • 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.
  • Event Log size and log wrapping should be defined to match the business and security requirements you determined when designing your enterprise security plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.
  • If you choose to set system service startup to automatic, perform adequate testing to verify that the services can start without user intervention.
  • Track the system services used on a computer. For performance optimization, set unnecessary or unused services to start only by manual intervention.
  • When security settings are imported to a Group Policy object in Active Directory, they will affect the local security settings of any computer accounts to which that Group Policy object is applied. In either case, your user account rights may no longer apply if there is a local policy settings that overrides those privileges.
  • Groups and users not specified in Restricted Groups are removed from the group specified. In addition, the reverse membership configuration option ensures that each restricted group is a member of only those groups specified. For these reasons, using Restricted Groups for security should be limited to primarily configuring membership of local groups on workstation or member servers.
  • Importing a security template to a Group Policy object ensures that any accounts to which the Group Policy object is applied, will automatically receive the template's security settings when the Group Policy settings are refreshed. For domain controllers running Windows NT 4.0, you will have to configure the Primary Domain Controller policies to enable this replication.


How to ...

  • Start Security Templates
  • Customize a predefined security template
  • Define a security template
  • Delete a security template
  • Refresh the security template list
  • Set a description for a security template
  • Apply a security template to a local computer
  • Import a security template to a Group Policy object
  • View effective security settings


Start Security Templates

To start Security Templates

  1. Decide whether to add Security Templates to an existing console or create a new console.
    • To create a new console, click Start, click Run, then type mmc, then click OK.
    • To add Security Templates to an existing console, open the console, then go to the next step.
  2. On the Console menu, click Add/Remove Snap-in, then click Add.
  3. Select Security Templates, click Add, click Close, then click OK.
  4. On the Console menu, click Save.
  5. Enter the name to assign to this console and click Save.

Note

  • The console will appear in My Documents accessible either on the desktop or from the Start menu.

Related Topics


Customize a predefined security template

To customize a predefined security template

  1. In the Security Templates snap-in, double-click Security Templates. See Related Topics for more information.
  2. Double-click the default path folder (Systemroot\Security\Templates), and right-click the predefined template you want to modify.
  3. Click Save As and specify a file name for the security template.
  4. Double-click the new security template to display the security policies (such as Account Policies) and double-click the security policy you want to modify.
  5. Click the security area you want to customize (such as Password Policy), then double-click the security attribute to modify (such as Minimum Password Length).
  6. Check the Define this policy setting in the template check box in order to allow editing.

Related Topics


Define a security template

To define a security template

  1. In the Security Templates snap-in, double-click Security Templates. See Related Topics for more information.
  2. Right-click on the template path folder where you want to store the new template and click New Template.
  3. Enter the name and description for your new security template. The new template is then displayed in the console tree.
  4. Double-click the new security template to display the security areas.
  5. Double-click the security policy (such as Account Policies) that you want to customize, then click the security area (such as Password Policy).
  6. Double-click the security attribute you want to configure (such as Minimum Password Length).
  7. Check the Define this policy setting in the template check box in order to allow editing.

Related Topics


Delete a security template

To delete a security template

  1. In the Security Templates snap-in, double-click Security Templates. See Related Topics for more information.
  2. Double-click the template path folder where the security templates are stored, and right-click the security template you want to delete.
  3. Click Delete.

Related Topics


Refresh the security templates list

To refresh the security template list

  1. In the Security Templates snap-in, double-click Security Templates. See Related Topics for more information.
  2. Double-click the template path folder where the security templates are stored.
  3. Click Refresh. The console tree displays any new additions or deletions.

Related Topics


Set a description for a security template

To set a description for a security template

  1. In the Security Templates snap-in, double-click Security Templates. See Related Topics for more information.
  2. Right-click any of the following: Security Templates, the security template path folder, or a security template.
  3. Click Set Description.

Related Topics


Apply a security template to a local computer

To apply a security template to a local computer

  1. In the Security Configuration and Analysis snap-in, right-click Security Configuration and Analysis. See Related Topics for more information.
  2. If a working database is not already set, click Open Database to set a working database.
  3. Select Import Template.
  4. Select a security template file and click Open.
  5. Repeat the previous step for each template you want to merge into the database.
  6. Right-click Security Configuration and Analysis, and click Configure System Now

Notes

  • The security settings take effect immediately.

Related Topics


Import a security template to a Group Policy object

To import a security template to a Group Policy object

  1. In a console from which you manage Group Policy settings, click the Group Policy object to which you want to import the security template.
  2. In the console tree, right-click Security Settings.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
  3. Click Import Policy.
  4. Click the security template you want to import.

Note

  • The security settings are applied when the computer starts or as the Group Policy settings dictate.

Related Topics


View effective security settings

To view effective security settings

  1. In the console from which you manage Group Policy, double-click the Group Policy object.
  2. In the console tree, click Security Settings.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
  3. Double-click a security policy node (such as Account Policies) and click a security area (such as Password Policy).
  4. Double-click the security attribute you want to view (such as Minimum Password Length).

Note

  • Security settings will reflect both local policy and the policy in effect on the system. These may not be the same if the computer is inheriting Group Policy settings.

Related Topics


Concepts

This section provides general background information on using the Security Templates snap-in to manage system security:

  • Security Templates overview
  • Understanding Security Templates
  • Using Security Templates
  • Resources


Security Templates Overview

Windows 2000 provides a centralized method of defining security with the Security Template snap-in. It is a single point of entry where the full range of system security can be viewed, adjusted, and applied to a local computer or imported to a Group Policy object. Security Templates does not introduce new security parameters, it simply organizes all existing security attributes into one place to ease security administration. Security templates can also be used as a base configurations for security analysis, when used with the Security Configuration and Analysis snap-in.

What is a security template?

  • Security Policies:
    • Account Policies: security for passwords, account lockouts, and Kerberos policies
    • Local Policies: User rights, and logging for security events.
  • Restricted Groups: local group membership administration
  • Registry: security for local registry keys
  • File System: security for the local file system
  • System Services: security and startup mode for local services

You can import a security template to a Group Policy object. Any computer or user accounts in the site, domain, or organizational unit to which the Group Policy object is applied will receive the security template settings. Local Group Policy is a special Group Policy object: it cannot override domain-based policy, and only local and account policies are part of the local security template settings.

Importing a security template to a Group Policy object eases domain administration by configuring security for multiple computers at once. A Group Policy object defines access, configuration and usage settings for accounts and resources. For more information on Group Policy, see Group Policy.

Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of IP Security and public key policies, all security attributes can be contained in a security template.

The initial template applied to a computer is called the Local Computer Policy. The Local Computer Policy can be exported to a security template file, to preserve initial system security settings. This enables restoration of the initial security template at any later point. The only possible exceptions to this rule are legacy systems that are being upgraded to Windows 2000. For example, if a Windows NT 4.0-based computer has a customized security template that must not be overwritten, the new Local Computer Policy will not be applied during the upgrade. In this case, security can be configured and applied after the installation.

For information on how to use the Secedit.exe command line tool to automatically assign security templates to computers, see Automating security configuration tasks.


Understanding Security Templates

The Security Template snap-in enables you to define security templates. A security template is a physical representation of a security configuration: a file that contains the security attributes supported for Windows 2000. These include security for:

  • Account Policies
  • Local Policies
  • Event Log
  • Restricted Groups
  • File System, registry, system services


Account Policies

These policies apply to user accounts. This security area contains attributes for:

  • Password policy: for domain or local user accounts, determines settings for passwords such as enforcement, and lifetimes.
  • Account lockout policy: for domain or local user accounts, determines when and for whom an account will be locked out of the system.
  • Kerberos policy: for domain user accounts, determines Kerberos-related settings, such as ticket lifetimes and enforcement.

Account policies should not be configured for organizational units that do not contain any computers, since organizational units that contain only users will always receive account policy from the domain.

When setting account policies in Active Directory, keep in mind that Windows 2000 only allows one domain account policy: the account policy applied to the root domain of the domain tree. The domain account policy will become the default account policy of any Windows 2000 workstation or server that is a member of the domain. The only exception to this rule is when another account policy is defined for an organizational unit. The account policy settings for the organizational unit will affect the local policy on any computers contained in organizational unit. For more information, see Active Directory overview.

Upgrading Windows 2000 Professional and default domain policies (Account/Password)

When upgrading Windows 2000 Professional on computers that are members of a Windows 2000 domain, the account and password policies will take precedence over the local policy on any domain controllers, servers, and workstations in the domain. This is different from the upgrade behavior in previous versions of Windows.


Local Policies

These policies pertain to the computer. Local policies are based on the computer you are logged into, and the rights you have on that particular computer. This security area contains attributes for:

  • Audit policy: determines which security events are logged into the Security log on the computer (successful attempts, failed attempts or both). (The Security log is part of Event Viewer.)
  • User rights assignment: determines which users or groups have logon or task privileges on the computer.
  • 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.

Local Policies, by definition, are local to a computer. When these settings are imported to a Group Policy object in Active Directory, they will affect the local security settings of any computer accounts to which that Group Policy object is applied. In either case, your user account rights may no longer apply if there is a local policy settings which overrides those privileges.


Event Log

This security area defines attributes related to the Application, Security, and System event logs: maximum log size, access rights for each log, and retention settings and methods.

Event Log size and log wrapping should be defined to match the business and security requirements you determined when designing your Enterprise Security Plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.


Restricted Groups

This provides an important new security feature that acts as a governor for group membership. Restricted Groups automatically provides security memberships for default Windows 2000 groups that have predefined capabilities, such as Administrators, Power Users, Print Operators, Server Operators, and Domain Admins. You can later add any groups that you consider sensitive or privileged to the Restricted Groups security list.

For example, the Power Users group is automatically part of Restricted Groups, since it is a default Windows 2000 group. Assume it contains two users: Alice and Bob. Bob adds Charles to the group, through the Active Directory Users and Computers snap-in, to cover for him while he is on vacation. However, no one remembers to remove Charles from the group when Bob comes back from vacation. In actual deployments, over time, these situations can add up, resulting in extra members in various groups, members who should no longer have these rights. Configuring security through Restricted Groups can prevent this situation. Since only Alice and Bob are listed in the Restricted Groups node for Power Users, when Group Policy settings are applied, Charles is removed from the group automatically.

Configuring Restricted Groups ensures that group memberships are set as specified. Groups and users not specified in Restricted Groups are removed from the specific group. In addition, the reverse membership configuration option ensures that each Restricted Group is a member of only those groups specified in the Member Of column. For these reasons, Restricted Groups should be used primarily to configure membership of local groups on workstation or member servers.


File system, registry, system services

You can configure security attributes for all existing files and folders in the local file system, existing registry keys on the local system and existing system services on the local computer:

  • Inherit: any child objects of this object inherit the parental object's security provided the child object is not protected from inheritance.
  • Overwrite: in this case, the parental object's security will override any security set on the child object regardless of the child object's protection setting.
  • Ignore: use this setting if you do not want to configure or analyze security for this object or any of its child objects.

From here, you can also edit the Security properties of the object: what user or group account(s) has permission to read/write/delete/execute, inheritance settings, Auditing, and Ownership permission.

If you choose to set system service startup to Automatic, perform adequate testing to verify that the services can start without user intervention.

You should track the system services used on a computer. For performance optimization, set unnecessary or unused services to Manual.


Using Security Templates

Security Templates offers the ability to define system security by storing system security settings in a security template, and then applying or importing that template to a system. You must have appropriate administrator rights to the appropriate Group Policy object or the local computer.

  • Defining security templates
  • Predefined templates
  • Assigning security templates


Defining security templates

The Security Template snap-in is a central console for viewing, defining, or modifying security templates.

This can be done by:

  1. Defining a new template, and modifying the default settings to meet your requirements.
  2. Applying an existing template to a computer, then modifying the template to fit the new context.
  3. Editing an existing security template, then saving it as a new template (in order to preserve the original).

For how to define security templates, see To define a security template or To customize a predefined security template.


Predefined security templates

Windows 2000 includes several incremental security templates. By default, these templates are stored in:

Systemroot\Security\Templates

These predefined templates can be customized using the Security Templates Microsoft Management Console (MMC) snap-in and can be imported into the Security Settings extension of the Group Policy snap-in.

Caution

  • These security templates are constructed with the assumption that they will be applied to Windows 2000 computers that use the default security settings for Windows 2000. 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, then perform the modifications.
  • You cannot secure Windows 2000 systems that are installed on FAT file systems.
  • 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.

The predefined security templates are:

  • Default workstation (basicwk.inf)
  • Default server (basicsv.inf)
  • Default domain controller (basicdc.inf)
  • Compatible workstation or server (compatws.inf)
  • Secure workstation or server (securews.inf)
  • Highly secure workstation or server (hisecws.inf)
  • Secure domain controller (securedc.inf)
  • Highly secure domain controller (hisecdc.inf)

Security Levels

The templates were designed to cover five common requirements for security:

  • Basic (basic*.inf)

    • The basic configuration templates are provided as a means to reverse the application of a different security configuration. The basic configurations apply the Windows 2000 default security settings to all security areas except those pertaining to user rights. These are not modified in the basic templates because application setup programs commonly modify user rights, to enable successful use of the application. It is not the intent of the basic configuration files to undo such modifications.

  • Compatible (compat*.inf)

    • The default Windows 2000 security configuration gives members of the local Users group strict security settings, while members of the local Power Users group have security settings that are compatible with Windows NT 4.0 user assignments. This default configuration enables certified Windows 2000 applications to run in the standard Windows environment for Users, while still allowing applications that are not certified for Windows 2000 to run successfully under the less secure Power Users configuration. However, if Windows 2000 users are members of the Power Users group in order to run applications not certified for Windows 2000, this may be too unsecure for some environments. Some organizations may find it preferable to assign users, by default, only as members of the Users group and then decrease the security privileges for the Users group to the level where applications not certified for Windows 2000 run successfully. The compatible template is designed for such organizations. By lowering the security levels on specific files, folders, and registry keys that are commonly accessed by applications, the compatible template allows most applications to run successfully under a User context. In addition, since it is assumed that the administrator applying the compatible template does not want users to be Power Users, all members of the Power Users group are removed.

  • Secure (secure*.inf)

    • The secure templates implement recommended security settings for all security areas except files, folders, and registry keys. These are not modified because file system and registry permissions are configured securely by default.

  • Highly Secure (hisec*.inf)

    • The highly secure templates define security settings for Windows 2000 network communications. The security areas are set to require maximum protection for network traffic and protocols used between computer running Windows 2000. As a result, such computers configured with a highly secure template can only communicate with other Windows 2000 computers. They will not be able to communicate with computers running Windows 95 or 98 or Windows NT.

  • Dedicated Domain Controller (dedica*.inf)

    • Local user security on domain controllers running Windows 2000 is not ideally secure by default. This enables an administrator to run existing server-based applications on domain controllers (not recommended) in a backwards-compatible fashion. If you do not run server based-applications on domain controllers (recommended), the default file system and registry permissions for the local users group can be defined in the same ideal fashion as that defined by default for Windows 2000 workstations and stand-alone servers. By implementing a dedicated security template these ideal security settings for local users on Windows 2000 domain controllers are applied.

For how to use predefined templates, see To customize a predefined security template.


Assigning security templates

Templates may be applied to local computer policy, imported to a Group Policy object, used for system security analysis, or assigned automatically using the Secedit command line tool.

Importing a security template to a Group Policy object ensures that any accounts to which the Group Policy object is applied, will automatically receive the template's security settings when the Group Policy settings are refreshed. For domain controllers running Windows NT 4.0, you will have to configure the Primary Domain Controller policies to enable this replication. The security settings are applied at system start time or as the Group Policy settings dictate.

You can directly apply a security template to local computer policy when a computer is not part of a domain. The system is immediately configured with the new template settings.

For how to assign security templates, see To import a security template to Group Policy or To apply a security template to a local computer.

For information on using security templates for security analysis, see Security Configuration and Analysis overview.

For how to use the Secedit command line tool to automatically assign security templates to computers, see Automating security configuration tasks.


Resources

The Microsoft Windows 2000 Resource Kit contains advanced information on how to configure, administer, optimize, and troubleshoot the security features of Windows 2000.

For information and the latest recommendations on Windows 2000 security deployment, and security tool set deployment information, see the Security Advisory page on the Microsoft Web site (http://www.microsoft.com/).


Troubleshooting

What problem are you having?

Security policy is not propagating correctly.

Cause: Any.

Solution: There is a registry value that creates a log file during policy propagation. The log file is located in systemroot\Security\Logs\Winlogon.log. You can examine this log file to identify specific errors that occur during policy propagation to the computer.

The registry key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}

For the new registry value, type: ExtensionDebugLevel

For the registry data type, click: REG_DWORD

For the registry data, type: 2

For more information about editing the registry, see Managing the Windows 2000 registry.

Received error message: Event message: Event ID 1202, Event source: scecli, Warning (0x%x) occurs to apply security policies.

Cause: Group Policy was not refreshed after changes were made.

Solution: Trigger another application of Group Policy settings or local policy refresh by using the Secedit command line tool to refresh security settings.

See also: Refresh security settings.

Received error message: Failed to open the Group Policy Object.

Cause: The most likely causes for this error are network-related.

Solution: Check the DNS configuration for the following: Make sure that there are no stale entries in the DNS database and resolve local DNS servers and Internet service provider (ISP) DNS server entries.

For example, the DNS settings for a local LAN network adapter points to two DNS servers: the local DNS server (possibly the same computer) , and the DNS server of an ISP. If you try to ping your domain, a message may indicate that this is an unknown host. Even with correct local DNS entries, the ISP DNS server cannot identify your domain, so there is a difference in their databases. To resolve this error, remove the second entry for the ISP DNS server, and add the ISP DNS server IPAddress to the forwarders in the local DNS server.

Modified security settings are not taking effect.

Cause: The Group Policy model specifies that any policies configured locally may be overridden by like policies specified in the domain. If your setting shows up in local policy but not in effective policy, it implies that there is a policy from the domain that is overriding your setting. Also, the Group Policy model applies policy changes periodically; therefore, it is likely that the policy changes made in the directory have not been refreshed in your computer yet.

Solution: Manually do a policy refresh by typing the following at the command line:

secedit /refreshpolicy MACHINE_POLICY

See also: Refresh security settings.

Policies do not migrate from Windows NT 4.0 to Windows 2000.

Cause: Windows NT 4.0 policies cannot be migrated to Windows 2000. In Windows NT 4.0, system policies were stored in one .pol file with group information embedded; no method is available to translate that information to the Windows 2000 Active Directory structure. Groups are handled very differently in Windows 2000.

Solution: Windows NT 4.0 clients accessing a Windows 2000 Server computer and Windows 2000 Professional clients accessing a Windows NT 4.0 Server computer will use the Netlogon share (the Windows NT 4.0 model). With Windows 2000 Server, when a Windows NT 4.0 client is upgraded to Windows 2000, it will get only Active Directory based Group Policy settings and not Windows NT 4.0-style policies. Although Windows NT 4.0-style policies may be enabled (using a Group Policy setting) if the administrator chooses to do so, this practice is strongly discouraged. Windows NT 4.0-style policies are applied only during the logon process. This means that both computer and user settings are processed. This is not optimal behavior for the following reasons: The Windows NT 4.0-style computer settings override the Group Policy settings that have already been applied to the computer during startup. During the Group Policy settings refresh cycle, the Group Policy settings change any conflicting settings back. This creates an indeterminate state. Windows NT 4.0-style policies result in persistent settings in the registry (tattooing). Note also that Terminal Server cannot allow computer settings to be set based on a user logon.


Set a new security template path

To set a new security template path

  1. If you do not want to store all your templates in the default path, in the Security Templates snap-in, right-click Security Templates. See Related Topics for more information.
  2. Click New Configuration Search Path, and select the new location.

    3. A folder with the path of the new location appears in the console tree.

  3. If you want to give a description to the new template path (in addition to the name), right-click the new template path folder, then click Set Description.

Related Topics