Best practices for configuring, managing, and auditing OS security features
You know that Windows 2000 has a robust security model. However, to ensure legacy compatibility and interoperability, Win2K Setup activates only a few of the available security features. For example, when you install a fresh copy of Win2K or upgrade a legacy platform to Win2K, default security settings don't implement account lockout controls or enable security auditing. You'll also discover that the default settings permit blank and zero-length passwords and set most services to start automatically with the system account. And although Win2K Setup implements access controls on the system root to limit nonadministrator access, the OS grants Everyone Full Control access to the root of all logical drives.
You'll find many compelling reasons to modify the default security settings, especially if you're configuring systems for a secure environment. For example, to ensure application compatibility when you upgrade a Windows NT 4.0 system to Win2K, Win2K by default adds the local Users group to the local Power Users group. Members of the Power Users group can manage and manipulate local user and group accounts and shared resources—tasks you might not want a typical interactive user to perform. Therefore, if you plan to upgrade many NT 4.0 systems to Win2K, you might want to remove the local Users group from the local Power Users group. Similarly, if you're setting up a VPN server that only manages connections, you might want to disable unnecessary services as a deterrent to unauthorized access and to eliminate potential security vulnerabilities. As you learn more about Win2K's default security settings and how they affect a mixed environment, you're guaranteed to discover new areas of vulnerability that require your attention to eliminate intrusion opportunities.
The Security Configuration Tool Set
Win2K includes a group of three security-based utilities, collectively called the Security Configuration Tool Set, that assist you in defining, implementing, and managing security roles for systems. These utilities—Security Templates, Security Configuration and Analysis, and Security Extensions to Group Policy—extend the controls available in NT 4.0 system policies.
Here's the big picture for how you leverage the security tool set. You start by defining enterprise security requirements for a common group of systems, such as end-user workstations, firewalls, or special-purpose servers. Then, you use the Microsoft Management Console (MMC) Security Templates snap-in to create a template that translates your security requirements into OS-specific settings. A security template defines values and behaviors for seven security-related categories—account policies, local policies, event-log controls, restricted groups, system services, the registry, and the file system—that implement the controls you need.
After you define the template, you use the MMC Security Configuration and Analysis snap-in to test the template and assign it to systems that share the same security role. You use the Security Configuration and Analysis snap-in to compare active settings with settings in a template. If you want to implement security templates through Group Policy, you must use the MMC Security Extensions to Group Policy snap-in. You can use the tools individually or together to define, implement, audit, and document corporate standard security settings on all systems in your enterprise.
Security Templates
Security Templates is a standalone MMC snap-in that lets you configure OS security by making selections from a GUI. Templates contain a lot of information, and it takes several seconds for the snap-in to locate and process the built-in templates. Similarly, the first time you expand a template, the snap-in might respond sluggishly; but after the template is loaded, response time improves. In the left pane of the Security Templates snap-in, which Figure 1 shows, you can see the 12 built-in templates that define security settings for generic classes of machines, from a basic workstation to a high-security server.
Built-in templates define five security roles: basic, secure, highly secure, compatible, and optional component file security. (The Web-exclusive sidebar "The Purpose of Built-in Templates," http://www.secadministrator.com, InstantDoc ID 23081, briefly explains the built-in templates.) Win2K stores the text versions of built-in templates in the default location \%windir%\security\templates. This directory contains one file with an .inf extension for each template. To avoid rights problems with legacy applications, all built-in templates make the local Users group a member of the local Power Users group.
The built-in templates define generic security roles for systems. The last one or two letters of each built-in security template describe the role to which the template applies: wk or ws represents a workstation, sv represents a server, and dc represents a domain controller (DC). Workstation templates are less restrictive than server templates, and server templates have fewer controls than DC templates. As with any template, anticipating the many ways an enterprise might need to configure and control workstations and servers is difficult. You can use a built-in security template in your enterprise if the settings meet your security needs. You can also use a built-in template as a baseline to define a custom template that implements more rigorous controls. To customize a template, you can make a copy of an existing template, rename it during the copy operation, and add policies and controls that implement your site-specific security requirements. (For an example of a custom security template, see the Web-exclusive sidebar "Building a Custom Security Template," InstantDoc ID 23082.)
Each security template contains a key for seven security categories. (Figure 1 shows the keys for the Setup Security template.) If you've previously examined or modified the Local Security policy on a Win2K system, many of these entries will look familiar. Expand any key in the left pane to display the available controls and their current settings in the right pane.
A side benefit of security templates is that they permanently document a system's security configuration. When implementing security controls, you often make changes on different days over a long period of time, and it's difficult (if not impossible) to reconstruct the whole picture on demand. However, if you define all the modifications in a template, you can reference the template to answer questions about specific settings. With a template, you can recreate the same configuration at will on any system with just a few mouse clicks.
Prev. page
[1]
2
3
next page 
