In my last column, I talked about Group Policy and how it is applied based on a user's or a computer's location within Active Directory (AD). This week, I look at network security, one of several areas where you can use Group Policy to simplify the tasks that you face as a network administrator. With Group Policy, you can ensure that the machines on your network remain in a secure configuration after you deploy them.

When you create or modify a Group Policy Object (GPO), you can configure several security settings located under Group Policy Editor (GPE) Computer Configuration, Windows Settings, Security Settings. As Figure 1 shows, Security Settings is where you can configure a machine on your network to use IP security and specify settings for everything from user rights to system services. Although some individual settings are easier to configure under Windows NT 4.0, the ability to configure all the settings from one location is a key benefit of Windows 2000's Group Policy. And because you can apply Group Policy to Organizational Units (OUs) that contain multiple computers with similar security requirements, it's much easier to apply changes such as assigning permissions to a Registry key. One exception is the Account Policies settings, which apply at the domain level and which, by default, the Default Domain Policy sets.

As you can see, Group Policy makes it easy to configure security settings on the machines in your Win2K domain. In addition, two tools, Security Templates and Security Configuration and Analysis, are extremely useful for applying network security policy and evaluating whether individual machines comply with the policy, as Figure 2 shows. With these tools, you can build templates with particular security settings for different groups of machines, apply the settings to the machines, and then periodically evaluate the machines to verify that they remain properly configured.

Security Templates
You can use the Microsoft Management Console's (MMC's) Security Templates snap-in to build different templates that you can import into Group Policies. You can either create a new policy from scratch or modify one of the built-in policies. After you decide which template to use, you can import the template settings into your GPO using Group Policy Editor (GPE) by right-clicking Computer Configuration, Windows Settings, Security Settings and choosing Import Policy. This process applies all the settings you configured in the template to all the computers in the container (e.g., site, domain, OU) that you link the Group Policy to.

Security Configuration and Analysis
You can use the MMC's Security Configuration and Analysis snap-in to verify that the security settings you apply with Group Policy are in use. Before you perform an analysis, create a database to store the results. After you create and open the database and choose the template containing the settings that you want to apply to a specific machine, right-click the snap-in and choose Analyze Computer Now to check the actual security settings against the desired settings. You can also use Security Configuration and Analysis to apply the security template to the machine, but it's better to use Group Policy. If you use Security Configuration and Analysis to apply the settings, a user can come behind you and change the settings. With Group Policy, if a user changes a security setting, it changes back to its original value the next time Win2K applies the policy.

On a final note, be sure that you thoroughly test any security templates in a lab environment before rolling them into production. The Win2K default security setting provides a significant increase in security over the NT 4.0 default settings. If you need to ensure compatibility with any non-Win2K certified applications, you might have to use the built-in Compatible Template (compatws.inf) or put your users in the built-in Power Users group. If you want to ensure that all your machines are using the Win2K default settings, you can apply the appropriate default template (basicwk.inf, basicsv.inf, or basicdc.inf). However, if you apply the changes to machines that you upgraded from NT 4.0, you might experience problems with some applications that were working under NT 4.0.