Lesson 1:Configuring Security Templates | MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)

< Day Day Up >

Early versions of Windows provided a great number of security configuration items. You could configure everything from the minimum password length to whether a logon was displayed. However, you had to use several different tools to configure these options. This made security configuration a cumbersome task and caused many administrators to overlook important security settings. Clearly, these tools needed to be simplified.

Windows NT 4.0 introduced the System Policy Editor, which provided a single user interface to manage all of the various security settings on the system. This single interface made it simple for an administrator to make critical decisions about the security of the system. Administrators managing multiple computers were especially thrilled with it, because they could easily copy configurations between systems on a network and apply various settings to different computers and users.

Windows 2000, Windows XP, and Windows Server 2003 use security templates and Group Policy to (mostly) replace System Policy. Security templates are files that represent a system's security configuration, and Group Policy provides an extremely flexible and robust distribution mechanism for security templates. Using these tools together, administrators can create complex security configurations and mix and match those configurations for each of the various roles computers serve in their organizations. When deployed across a network, security templates allow you to implement consistent, scalable, and reproducible security settings throughout your enterprise.

This lesson focuses on configuring security templates. In this lesson, you will explore the predefined security templates, familiarize yourself with the settings available in security templates, and learn the effects of changing key settings.

After this lesson, you will be able to

Edit security templates.
Use security templates to specify permissions for files, folders, services, event logs, and the registry.
Specify account policies and security options by using security templates.
Control group memberships by using security templates.
Determine the best methods to configure security settings for various Microsoft operating systems.

Estimated lesson time: 45 minutes

Predefined Security Templates

Security templates are text files that describe a set of security configuration settings. You can make your own security templates from scratch. However, it is almost always easier, and more thorough, to start with one of the default security templates included with Windows Server 2003. The Windows Server 2003 family includes several predefined security templates that you can copy and modify to meet the security requirements for your organization and apply to computers in your network. By default, these predefined security templates are stored in C:\Windows\Security\Templates.

Warning

Do not modify the predefined security templates. These files are well known, and another administrator might attempt to use your modified file without being aware of the changes you have made. Instead, copy the predefined security templates to create a new security template that you can modify as needed.

The following list describes each of these predefined security templates:

Setup Security.inf and DC Security.inf. The setup security template is the default security setting of a new install of the Windows Server 2003 family. Setup Security.inf is different for each workstation or server. For the domain controller setup, Security.inf is used with the DC Security.inf template. The DC security template defines system services settings that are appropriate for a domain controller.
Compatws.inf. If you do not want your users to run as Power Users, this template makes the default permissions for the Users group less restrictive so that older applications are more likely to run correctly. This configuration is not considered a secure environment. This template will remove all members in the Power Users group on computers running Windows Server 2003 family operating systems.
Securews.inf and Securedc.inf. These templates increase security for areas of the operating system that are not covered by permissions, including Account Policy, Auditing, and selected security-relevant registry keys. This template will remove all members in the Power Users group on computers running Windows XP.
Hisecws.inf and Hisecdc.inf. These templates are provided for computers that operate in a network running in Windows 2000 native or the Windows Server 2003 family domain functionality native mode. In this configuration, all network communications must be digitally signed and encrypted at a level that can only be provided by Windows 2000, Windows XP, or the Windows Server 2003 family. Thus, a highly secure computer running a Windows Server 2003 family operating system can communicate only with another computer running one of those operating systems.
Rootsec.inf. This template resets the default permission entries of the system root folder and propagates the permissions to all subfolders and files. The permission entries of the root folder are inherited by all files and subfolders, except those files or subfolders that have had explicit permissions set. Note that this template is new to Windows Server 2003.

Iesacls.inf. This template is provided to enable auditing of registry settings that control Microsoft Internet Explorer security. Applying this template does not improve Internet Explorer security; instead, this security template should be used as a starting point for creating a template for Internet Explorer-related security.

Security Template Planning

The predefined security templates are designed to secure different computer roles at different security levels. Whether you create your own security templates or use the predefined templates, you should use separate security templates for each of the various roles computers serve in your organization. If different computers require different levels of security, you might be required to create multiple templates for each role to satisfy the need to provide higher and lower security for different computers.

When deciding how your security templates will be designed, think in terms of computer roles, rather than individual computers. It's simple to apply multiple security templates to a single computer, but much more complicated to separate the security settings required by each of the individual roles a computer might serve. For example, if you have a domain controller that also acts as a file server, you should create separate security templates for the domain controller role and the file server role. In the future, if you add a dedicated domain controller or file server, you can apply only the security template that is required.

In large organizations, it is likely that different divisions within the organization will have different security requirements. This is most evident in government organizations, where material classified at different levels has distinctly different security requirements. In this case, you should first determine which roles are required, and then determine the security levels required by each role. If one organization has a file server that stores only public content, and another organization has a file server that stores highly confidential files, you should create two file server security templates.

Creating and Editing Security Templates

There are three ways to create a new security template. The simplest way is to copy the predefined template that most closely matches your requirements and then change settings as needed. You can also create a new security template from scratch. If you have existing systems that you have configured to meet your security needs, you can create a new security template based on that existing configuration.

Copying a predefined template

Most of the time, when you create a new security template, you will do so by copying one of the predefined security templates. To copy a predefined security template using the Security Templates snap-in, follow these steps:

Create a new Microsoft Management Console (MMC) console, and add the Security Templates snap-in.
Expand the Security Templates node, and then expand the C:\Windows\Security
\Templates node.
Right-click the security template you want to copy, and click Save As.
In the Save As dialog box, specify the file name of the new template, and then click Save.

The Security Templates snap-in will automatically refresh the display. If you saved the security template in the same folder as the predefined security templates, it will immediately appear in the snap-in.

Tip

You can also create a new security template based on a predefined security template by manually copying the .inf file.

Creating a new security template

To create a new security template from scratch, follow these steps:

Create a new MMC console, and add the Security Templates snap-in.
Expand the Security Templates node.
If the folder you want to store your new security template in is not listed as a template search path within the Security Templates node, right-click Security Templates and then click New Template Search Path. Specify the location in which you will store the new template, and click OK.
Right-click the template search path that will contain your new template, and then click New Template.
Specify a name and description for the security template, and then click OK.

After you create a new security template, you should edit it by using the Security Templates snap-in. In the left pane of the Security Templates snap-in, you can browse the categories of security policies that can be defined. When you select a node in the left pane, the policies contained within that node will be displayed in the right pane.

If you created a new security template by copying an existing security template, all of the security settings defined in the original template will be defined for this template. If you created a blank security template, no policies will be defined. This is an important point to remember: blank security templates do not contain default settings; they simply have no policies defined. Policies that have not been defined show Not Defined in the Computer Setting column. Before a security template is useful, you must define one or more policies.

To define a policy, or to change a previously defined policy, double-click the policy in the right pane of the Security Templates snap-in. A dialog box will appear that allows you to choose whether the policy is defined and to specify the policy's definition. Select the Define This Policy Setting In The Template check box. Then specify the policy setting and click OK. Figure 3.1 shows the Security Templates snap-in being used to edit a security template with only the Minimum Password Length policy defined.

click to expand
Figure 3.1: The Security Templates snap-in

Copying an existing configuration

You can use the Secedit.exe command-line tool to create a security template using the security settings currently defined on a computer. This is an excellent way to copy the settings from a system that you have already configured to meet your organization's security requirements. This is also the preferred method for migrating to using Active Directory Group Policy, rather than local security policy, to apply security settings to computers.

To create a security template based on a computer's existing security configuration, follow these steps:

Open a command prompt by clicking Start, pointing to All Programs, pointing to Accessories, and then clicking Command Prompt.
At the command prompt, type secedit /export /cfg filename.inf. For example, to export the current configuration to the C:\Windows\Security\Templates\Current Security.inf file, execute the following command:

secedit /export /cfg 'C:\Windows\Security\Templates\Current Security.inf'

Security Template Settings

In Chapter 2, you learned how to use security policies to control authorization. The structure of security policies is identical to that of security templates, so you are already familiar with many of the settings available within a security template. For example, you can use a security template to configure the permissions associated with files, folders, registry entries, and services. Security templates can have more security options than the Local Computer Policy, however, because security templates include options for both standalone computers and computers that are participating in a domain.

Understanding the types of security settings that can and cannot be configured using security templates is critical for both passing the exam and using security templates successfully. The following sections describe the various types of settings that can be defined in a security template.

Tip

There are far too many security options in a security template to describe them all in detail. The best way to familiarize yourself with the options available is to browse through them, open each policy, and view the choices available.

Account policies

Account policies affect how user accounts can interact with the computer or domain. Account policies can only be defined once within a domain. The Account Policies node contains three nodes:

Password Policy. Determines settings for passwords, such as whether a password history is maintained, the minimum and maximum password ages, and password complexity and length requirements.

Security Alert

Set the minimum password age only if you have also defined a maximum password age and password history requirement. The minimum password age prevents users from changing their password back to the original password after being required to change it because it reached the maximum password age.

Account Lockout Policy. Determines the circumstances and length of time that an account will be locked out of the system.

Security Alert

Enabling account lockout doesn't necessarily increase security. In fact, it actually creates a new vulnerability. An attacker who knows valid user names can guess incorrect passwords for users and lock legitimate users out, creating a denial-of-service attack.

Kerberos Policy. Determines Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in Local Computer Policy.

For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it is enforced by the domain controllers that make up the domain. A domain controller always obtains the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit (OU) that contains the domain controller. By default, workstations and servers that are joined to a domain (such as member computers) will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you define an account policy specifically for the local accounts.

Local policies

The Local Policies node in a security template contains policies that control auditing, user rights, and miscellaneous security options for a computer. The Local Policies node contains three nodes:

Audit Policy.The auditing policies that you choose for the event categories define your auditing policy. 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 turned off by default. By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization.

See Also
For information on using auditing to troubleshoot authorization problems, see Chapter 2.
User Rights Assignment. These policies define dozens of options that specify which users can perform various actions on a computer. You can use the policies contained in this node to control who can and cannot log on to a computer, back up files on a computer, and restart a system (among other actions). Generally, it is better to add users who need additional rights to built-in groups, such as Power Users.
Security Options. The Security Options node contains policies that didn't fit well into the other policy groups. These options include whether a computer will shut itself down when the Security event log is full, whether unsigned drivers can be installed, and whether Ctrl+Alt+Del is required to log on.

Event logs

The Event Log node in a security template contains policies that define how the computer's event logs behave. These policies define the maximum size for the three main log files: the Application event log, the Security event log, and the System event log. You can also use these policies to control which users are authorized to access each of the three primary event logs. Of particular importance for environments that require retaining a history of actions performed on a computer, you can define policies that control how log files are retained. Specifically, you can require that log files are retained for a minimum number of days, and specify whether events are overridden as needed or deleted after a specific number of days.

It is common practice to define the Retain Security Log policy so that Windows Server 2003 keeps security events for 30 days. This enables you to review the Security event log after an attack has been detected to potentially uncover clues as to how an attacker accessed your system.

Group memberships

Unlike the Account Policies, Local Policies, and Event Logs nodes, the Restricted Groups node does not contain a list of policies. Instead, you can use this node to specify security groups by name and limit the memberships of those groups. For each group you specify, you can specify two properties: Members and Members Of. The Members list defines who belongs and who does not belong to the restricted group. The Members Of list specifies which other groups the restricted group belongs to.

When a Restricted Groups Policy is enforced, any current member of a restricted group that is not on the Members list is removed. Any user on the Members list who is not currently a member of the restricted group is added.

Services

This node of a security template is used to define the startup type and authorization for system services on a computer. For example, if you want users to be able to start the Messenger service as needed, you can define a policy setting to set the Messenger service startup type to manual, and then configure the Messenger service authorization so that only Domain Users have permissions to start, stop, and pause the service.

Registry permissions

This node of a security template is used to define the authorization for registry keys and values. While the default registry authorization settings for Windows Server 2003 are sufficient for most environments, applications often store information that should be kept private in the registry. Applications that create their own registry keys and values might not adequately restrict the permissions associated with that information. Fortunately, you can use security templates to further restrict those permissions.

To add a registry key to a security template, right-click the Registry node and then click Add Key. Use the Select Registry Key dialog box to specify the registry key. If it does not exist on the local computer, but you will use the security template to apply permissions to other computers, you can manually type the name of the registry key in the Selected Key field.

File and folder permissions

The File System node of a security template allows you to use the security template to specify file and folder permissions. To add a file or folder to a security template, right-click the File System node and then click Add File. Use the Add A File Or Folder dialog box to specify the file system object. If it does not exist on the local computer, but you will use the security template to apply permissions to other computers, you can manually type the name of the file or folder. After specifying the file or folder, you can use the familiar graphical interface, introduced in Chapter 2, to configure standard and special permissions.

Security Configuration for Earlier Versions of Windows

Most administrators will use Group Policy to deploy security templates through a network. Windows Server 2003, Windows 2000 Server, Windows 2000 Professional, and Windows XP Professional all fully support Group Policy, making it simple to apply a security template. However, many enterprise networks will include other Windows operating systems, including Windows Millennium Edition, Windows 98, and Windows NT 4.0. You must consider the potential security vulnerabilities of earlier versions of Windows when deploying security configurations to systems on your network. After all, earlier versions of Windows are more likely to have security vulnerabilities than newer versions.

Windows NT 4.0, Windows 95, Windows 98, and Windows Millennium Edition clients use System Policy rather than Group Policy. System Policy is a policy based on registry settings specified by using the System Policy Editor, Poledit.exe. System Policy Editor can be obtained from a Windows NT 4.0 CD.

Off the Record

You can use both System Policy and Group Policy together, but it makes life much more difficult for you. You'll experience more problems deploying security settings, and you'll spend more time troubleshooting them. When possible, upgrade Windows NT 4.0 domains to Windows 2000 or Windows Server 2003 domains, and upgrade older computers to an operating system that supports Group Policy.

Although System Policy Editor (Poledit.exe) is mostly replaced by Group Policy, it is still useful to create .pol files that can define security-related registry settings on a computer. .pol files contain a list of registry values and can be automatically deployed to a computer upon startup or when a user logs on. The .pol file you create varies depending on the operating system you are targeting:

Windows 95 or Windows 98.System Policy Editor must be run locally on computers that run Windows 98 or Windows 95 to create Config.pol files that are compatible with the local operating system.
Windows NT 4.0 Workstation and Windows NT 4.0 Server.Run System Policy Editor on a Windows NT 4.0 computer, as shown in Figure 3.2, to create a file named Ntconfig.pol.

Figure 3.2: System Policy Editor on Windows NT 4.0

After creating a system policy, copy the resultant .pol file to the Netlogon share (%systemroot%\sysvol\DomainName\scripts) of any domain controller. Client computers running Windows XP and Windows 2000 ignore System Policy settings that are put in the Netlogon share of a Windows Server 2003 domain controller. Instead, they will apply Group Policy settings. These clients will apply System Policy if they're joined to a Windows NT 4.0 domain controller, however.

Planning

Neither System Policy nor Group Policy apply to Windows XP Home Edition, Windows NT 3.51, Windows 3.1, and MS-DOS operating systems. In your planning, be sure to create a strategy for migrating these clients to newer platforms.

Practice: Create and Examine a New Security Template

In this practice, you will create a security template. You will apply this template in Lesson 2.

Exercise 1: Create a Security Template

In this exercise, you will create a new blank security template.

Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Create a new MMC console, and add the Security Templates snap-in.
Expand the Security Templates node.
Right-click Security Templates, and then click New Template Search Path.

In the Browse For Folder dialog box, click My Documents, and then click Make New Folder. Type the name Templates, and then click OK.

Security Alert

It is important to store security templates used for a production environment in a secure location that only administrators responsible for implementing security can access-not because others should be unable to view the security templates, but rather to prevent unauthorized changes to security templates.

Right-click the newly created template search path that will contain your new template, and click New Template.
In the Template Name field, type Domain Password Requirements. In the Description field, type Security template that defines the password requirements for domain member computers. Created by your name on today's date for learning purposes only. Click OK.
Expand the Domain Password Requirements node, expand Account Policies, and then click Password Policy.
In the right pane, double-click Minimum Password Length. Select Define This Policy Setting In The Template, and then specify 10 characters. Click OK.
Double-click Passwords Must Meet Complexity Requirements. Select Define This Policy Setting In The Template, and then click Enabled. Click OK.
Double-click Store Passwords Using Reversible Encryption. Select Define This Policy Setting In The Template, and then click Disabled. Click OK.
In the right pane, right-click Domain Password Requirements, and then click Save.

Real World

Descriptions are important. A descriptive name isn't enough, because other administrators might have to analyze, edit, and apply your security template. If another administrator applies the wrong template because the name was confusing, your network's security could be reduced. For example, if you name a Web server security template 'Web template,' another administrator might confuse your template with the template that should be applied to desktop computers to secure Internet Explorer. Not only would your template fail to secure Internet Explorer, it might even reduce the security of the desktop computers by granting network access to files-a necessary setting for a Web server, but a dangerous setting for a desktop computer. Always provide a detailed description that includes your name, the date, and precisely what the template should be used for.

Exercise 2: Examine the Security Template

In this exercise, you will examine your newly created security template using a text editor.

Start Windows Explorer, and navigate to the My Documents\Templates\ folder.
Double-click the Domain Password Requirements.inf file.
Examine the security template. In particular, notice the [System Access] section of the file.
Close Notepad.

You will use this security template in the following lesson's practice.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the 'Questions and Answers' section at the end of this chapter.

Which predefined security template can be used to improve the ability of Users to run applications without being logged on as an administrator?
1. Setup Security.inf
2. Compatws.inf
3. Securews.inf
4. Hisecws.inf
Which predefined security template can be used to return a system to its original security settings?
1. Setup Security.inf
2. Compatws.inf
3. Securews.inf
4. Hisecws.inf
Which of the following tools can be used to copy a security template? (Choose all that apply.)
1. Active Directory Users And Computers
2. Group Policy Object Editor
3. Security Templates snap-in
4. Security Configuration And Analysis
5. Secedit
6. Windows Explorer

Lesson Summary

Most new security templates should be based on predefined security templates.
Create security templates for computer roles, not for individual computers.
The Security Templates snap-in is a graphical tool for creating and editing security templates.
Secedit is a command-line tool that can create security templates based on an existing computer's settings.
Security templates can be used to configure account policies, group memberships, event log settings, local policies, and permissions for folders, files, services, and the registry.

< Day Day Up >