Chapter 18: Windows Server 2003 Security Management
Security management is a critical security service that guarantees that the security settings and software on computer platforms and security infrastructure servers can be configured and maintained in an easy and coherent way. The security configuration together with the software that’s allowed to run on a computer system are defined in a security policy. Computer platforms can become trusted platforms if the security policy is audited—this means checked for compliance by a trusted entity—at regular intervals. This is the goal of security-related auditing.
In what follows, we discuss how Microsoft supports security management in Windows Server 2003 in the following three key areas: security policy management, security patch management, and security-related auditing. This chapter specifically focuses on Microsoft security management solutions. A deeper coverage of third-party (non-Microsoft) security management solutions is beyond the scope of this book.
18.1 Security policy management
The security policy for a computer platform defines all security-related configuration settings for that platform. It includes all the configuration settings listed in Figure 18.1. As Figure 18.1 shows, Microsoft does not offer a single tool to deal with the configuration all security-related settings. Most of the settings can be configured using Group Policy Object (GPO) settings; others can be configured though the Security Configuration Editor; and some cannot be configured using a Microsoft security policy configuration tool.
Figure 18.1: Coverage of security-related configuration settings by Windows security policy management tools.
Next we introduce the security policy life cycle. The other sections contain an overview of the different security policy management tools available in the Windows Server 2003 and Windows XP platforms. We discuss Group Policy Objects (GPOs), the Security Configuration Editor and Analysis tool (SCE-SCA), the Security Configuration Wizard (SCW), and the Microsoft Baseline Security Analyzer (MBSA). We also look at third- party security policy management tools that can supplement the Microsoft tools.
18.1.1 The security policy life cycle
The life cycle of a Windows security policy can be split into several different phases:
-
Policy creation: During this phase, security administrators define the security configuration of a Windows platform. Typically, a different security policy is defined for each machine type in the enterprise: workstations, file servers, and mail servers.
-
Analysis: During this phase, security administrators validate the security configuration of a Windows platform against the settings defined in the security policy.
-
Enforcement: During this phase, the security settings defined in the security policy are enforced on the different Windows platforms.
-
Reporting: This phase deals with the generation of security policy compliance reports.
-
Monitoring: This phase deals with the generation of real-time alerts when a machine’s security settings are changed.
18.1.2 Group Policy and Group Policy Objects
Group Policy refers to a group of software technologies that allow centralized configuration and change management of user and computer environments. Through its tight integration with Active Directory, Group Policy Objects (GPOs) are highly scalable and extensible. Microsoft introduced Group Policy in Windows 2000.
Group Policy covers six major system management areas: registry setting management, software deployment, folder redirection, scripts, software restriction policy, and security settings management. Software restriction policies were added in Windows Server 2003 (and discussed in detail in Chapter 11).
The basic unit of Group Policy is a Group Policy Object (GPO), a collection of policy configuration settings that can be linked to an Active Directory container (a domain, site, or OU) or to a local machine. The latter GPO type is referred to as a Local GPO (LGPO). The administrative inter- face for GPO management is the MMC Group Policy snap-in, also known as the Group Policy Editor (GPE), which is illustrated in Figure 18.2.
Figure 18.2: GPE and different containers and settings.
Windows 2000 and Windows Server 2003 come with two predefined GPOs: the default domain controllers and the default domain policy GPO.
-
The default Domain Policy GPO is the GPO that is automatically applied to every user and computer object in a Windows 2000 or Windows Server 2003 domain. It is linked to an AD domain object. The default domain policy is the only policy that can be used to control the security settings (password quality, account lockout, and so forth) of AD account objects (also known as global accounts)
-
The default Domain Controllers GPO is the GPO that is automatically applied to every Windows 2000 and Windows Server 2003 domain controller. It is linked to the Domain Controllers Organizational Unit (OU) container.
Next we briefly introduce the major GPO changes in Windows Server 2003. Afterward we look at how you can use GPOs for security policy management. For more information on GPOs and GPO settings and to learn more about the GPO design and the GPO application process, see the information contained in the Microsoft Technet library or Chapter 7 of my previous book, Mission-Critical Active Directory.
Key Windows Server 2003 Group Policy changes
Windows Server 2003 includes important GPO enhancements that improve administrators’ ability to design, manage, and troubleshoot GPOs. The following sections provide an overview of the key enhancements. We will not come back to software restriction policies, which were covered extensively in Chapter 11.
Group Policy Management Console
The Group Policy Management Console (GPMC) provides a unified view (illustrated in Figure 18.3) of GPOs, sites, domains, and OUs in an enterprise and can be used to manage either Windows Server 2003 or Windows 2000 domains. Because GPMC supports the new forest trust type, administrators can use it to manage GPOs in multiple forests from a single console. Until the release of GPMC, enterprises had to look at third-party tools to obtain a unified Group Policy management interface. A good example is FullArmor’s FAZAM 2000 software.
Figure 18.3: GPMC interface.
GPMC comes with an HTML-based reporting feature and provides GPO backup, restore, and copy support. GPMC also provides a set of scripts that can be used to automate GPO operations at the command line. Among its most powerful features are GPO results and modeling support. GPMC exposes the Resultant Set of Policy (RSoP) data. RSoP makes it easy for administrators to determine the resulting set of policies for a user or computer in both actual and what-if scenarios.
GPMC runs on Windows XP Professional SP1 and Windows Server 2003. In Windows XP Professional, you must have Service Pack 1 and the.NET Framework installed before installing the GPMC. The tool can be downloaded from the Microsoft downloads Web site.
WMI filters
Windows 2000 supports a GPO feature, known as GPO filtering, that allows you to define to which users and computers a GPO will be applied. This can be done by modifying the permissions on the GPO. In Windows XP and Windows Server 2003, Microsoft adds an additional filtering mechanism based on the Windows Management Instrumentation (WMI) interface.
A WMI GPO filter lets you dynamically determine the application scope of a GPO based the on properties of the target computer or user. You can, for example, create a WMI filter that only applies the GPO if the target computer is running Windows XP Service Pack 1. When using a WMI filter, the GPO is only applied if the result of the WMI query is true. WMI filters use the WMI Query Language (WQL), a WMI-specific SQL-like query language.
Administrative template changes
Administrative templates drive the configuration of Windows registry settings using GPOs. Windows Server 2003 provides a great deal of additional information about the different registry settings: Every setting now comes with an explain text. The text contains information about OS requirements and details about the effect of enabling or disabling the setting. The explain text is visible from the Extended GPO view or by double-clicking a setting and going to the Explain tab.
Not every administrative template setting can be applied to every Windows version. Windows Server 2003 GPO includes new features to expose this template versioning system in the interface. Under the hood, this versioning system builds on the supported keyword in administrative template files (*.adm). To filter the administrative template settings based on the Windows version requirements, right-click an administrative templates container, and then in the View menu, select Filtering (as illustrated in Figure 18.4).
Figure 18.4: Administrative template changes.
Command-line support
Administrators can now refresh policy settings from the command line using gpup*date, which replaces the Windows 2000 secedit /refreshpolicy.
Windows Server 2003 includes a new tool called dcgpofix.exe to restore the default domain and the default domain controllers GPOs to their original state—meaning their default state after a fresh Windows Server 2003 installation.
Using GPOs for security policy management
The GPO security policy management portion includes configuration options for the following security policy areas (Table 18.1 contains an over- view):
| GPO Security Settings Subcontainer (Windows 2000,Windows XP, and Windows Server 2003) | Equivalent NT4 Administration Tool (NT4) |
|---|---|
| Account policies | |
| Password policy | User manager => Policy/Account Policy |
| Account lockout | User manager => Policy/Account Policy |
| Kerberos policy* | N/A |
| Local policies | |
| Audit policy | User manager => Policy/Audit Policy |
| User rights assignment | User manager => Policy/User Rights |
| Security options | N/A |
| Event log* | Event Viewer => Log/Event Log Settings |
| Restricted groups* | N/A |
| System services* | Control Panel => Services |
| Registry | N/A |
| File system* | N/A |
| Wireless network policies* | N/A |
| Public key policies | N/A |
| Encrypting File System | N/A |
| Automatic Certificate Request Settings* | N/A |
| Trusted Root Certification Authorities* | N/A |
| Enterprise Trust* | N/A |
| Software restriction policies | N/A |
| IP security policies | N/A |
* Not configurable on workstations, member servers, and stand-alone machines.
-
Account policies to configure password, account lockout, and Kerberos settings.
-
Local policies to configure auditing, user rights, and security options.
-
Event log settings to configure the properties of the application, system, and security logs.
-
Restricted group settings to configure the membership of security sensitive groups.
-
System services settings to configure security and startup settings for services.
-
Registry settings to configure security permissions on registry keys.
-
File system settings to configure security permissions on files and folders.
-
Wireless network settings to configure wireless network access policies.
-
Public key policies to configure EFS recovery agents, trusted root CAs, user and machine certificate autoenrollment settings, and Certificate Trust Lists (CTLs).
-
Software restriction policies to configure malicious mobile code protection rules.
-
IP security policies to configure IPsec-related settings.
All of these settings can be configured from the Windows Settings\Security Settings GPO container (as illustrated in Figure 18.2). To configure local security policy settings on member servers, workstations, and stand-alone machines, you must use the local security policy settings MMC snap- in (illustrated in Figure 18.5). The wireless network settings and software restriction policies settings are new to Windows Server 2003. Only the software restriction policies and public key policies can be configured in both the user- and machine-portion of the GPOs; the other settings can only be configured in the machine-portion of the GPO.
Figure 18.5: Local security policy configuration tool.
In the GPO security policy management portion, Microsoft brought together the configuration of several security settings that before, in NT4, were spread across different administration tools. Table 18.1 gives an over- view of the different security setting categories configurable through the Windows 2000, Windows XP, and Windows Server 2003 GPO security settings and their NT4 administration tool counterpart.
The Account policies in the GPO security policy management container deserve a bit more explanation. Account policies can refer to local accounts or domain accounts. Account policies for domain accounts can only be set in the Default Domain Policy. This means that password, account lockout, and Kerberos policies for domain accounts can only be defined once: on the domain level using the Default Domain Policy. Account policies that are set in other GPOs will not affect the domain account policy but local account policies. Local account policies means policies linked to accounts stored in the SAM (the local security database).
A very interesting category of GPO security settings is the Security Options, located in the Local Policies container. Windows Server 2003 comes with a lot of additional Security Options; they are listed in Table 18.2. I strongly advise you to look closely at these new security options. Administrators can also add additional security-related registry configuration settings to the Security Options. How to do this is explained in the Microsoft Knowledge Base article Q214752.
| Security Option | Values |
|---|---|
| Guest account status | Enabled/Disabled |
| Limit local account use of blank passwords to console logon only | Enabled/Disabled |
| Allow undock without having to log on | Enabled/Disabled |
| Allowed to format and eject removable media | Administrators/Administrators and Power Users/ Administrators and Interactive Users |
| LDAP server signing requirements: | None/Require Signing |
| Refuse machine account password changes | Enabled/Disabled |
| Maximum machine account password age | x days |
| Require strong (Windows 2000 or later) session key | Enabled/Disabled |
| Require domain controller authentication to unlock workstation | Enabled/Disabled |
| Require smart card | Enabled/Disabled |
| Allow anonymous SID/Name translation | Enabled/Disabled |
| Do not allow anonymous enumeration of SAM accounts | Enabled/Disabled |
| Do not allow anonymous enumeration of SAM accounts and shares | Enabled/Disabled |
| Administrator account status | Enabled/Disabled |
| Do not allow storage of credentials or .NET Passports for network authentication | Enabled/Disabled |
| Let Everyone permissions apply to anonymous users | Enabled/Disabled |
| Remotely accessible registry paths | Names of registry paths |
| Remotely accessible registry paths and subpaths | Names of registry paths and subpaths |
| Restrict anonymous access to Named Pipes and Shares | Enabled/Disabled |
| Shares that can be accessed anonymously | share names |
| Sharing and security model for local accounts | Classic: local users authenticate as themselves / Guest: local users authenticate as Guest |
| Do not store LAN Manager hash value on next password change | Enabled/Disabled |
| LDAP client signing requirements | None/Negotiate Signing/Require Signing |
| Minimum Session Security for NTLM SSP-based (including secure RPC) clients | Require message integrity/Require message confidentiality/Require NTLMv2 session security/Require 128-bit encryption |
| Minimum Session Security for NTLM SSP-based (including secure RPC) servers | Require message integrity/Require message confidentiality/Require NTLMv2 session security/Require 128-bit encryption |
| Allow automatic administrative logon | Enabled/Disabled |
| Use Certificate rules on Windows executables for SRPs | Enabled/Disabled |
| Force strong key protection for user keys stored on the computer | User input is not required when new keys are stored and used/User is prompted when the key is first used/User must enter password each time they use a key |
| Use FIPS compliant algorithms for encryption, hashing, signing | Enabled/Disabled |
| Default owners for object created by members of the Administrators group | Administrators group/Object creator |
| Allow floppy copy and access to all drives and all folders | Enabled/Disabled |
| Require case-insensitivity for non-Windows | Enabled/Disabled |
| Optional subsystems | Subsystem names (Posix) |
GPO security policy management is closely related to the Security Configuration Editor and Analysis tool (SCE/SCA), which is discussed later in this chapter. GPOs complement the SCE/SCA by making it possible to enforce security policy settings on the domain, OU, and site level. Both the SCA and GPO security management use the same client-side extensions for security policy enforcement: the scecli.dll on Windows client platforms and the scesrv.dll on Windows servers. Both also use the same local security configuration database: secedit.sdb.
Both the GPO- and SCE-rooted security policy management support security configuration templates (*.inf files). These are security configuration-specific templates that can be easily exchanged between different GPOs and machines. The templates are stored in the %systemdrive%\ winnt\security\templates directory. Like the administrative templates used for registry configuration (*.adm), the security configuration templates are customizable. To edit security configuration templates, you use a plaintext editor (like Notepad) or the Security Templates MMC snap-in, illustrated in Figure 18.6.
Figure 18.6: Security Templates MMC snap-in.
Microsoft provides two basic categories of security configuration templates: default and incremental security templates:
-
Default security templates contain the default Windows security settings, as they are applied to a Windows system during a normal installation.
-
Incremental security templates define higher or lower security levels; they can be used to bring a machine from the default security level to a higher or lower security level. The compatws.inf template, for example, loosens security on a Windows machine to allow applications to write to more registry keys. The hisecdc.inf template, on the other hand, tightens the security of a Windows domain controller. An incremental template should never be applied without first applying a default template. Microsoft defines three levels: compatible, secure, and high secure.
Each of these categories contains specific templates for a Windows workstation, server, and domain controller. The security configuration templates available in Windows are listed in Table 18.3.
| Security Template Category | Template Name | Meaning |
|---|---|---|
| Default templates | DC security.inf Setup security.inf | The default template for a Windows domain controller The default template for a Windows workstation |
| Incremental templates | Compatws.inf | Compatible incremental template for a Windows workstation. Relaxes security settings to deal with noncertified applications. |
| Rootsec.inf | Applies default root permissions introduced in Windows XP to the OS partition and propagates them to child objects that are inheriting from the root. | |
| Securedc.inf | Secure incremental template for a Windows domain controller | |
| Securews.inf | Secure incremental template for a Windows workstation | |
| Hisecdc.inf | High Secure incremental template for a Windows domain controller | |
| Hisecws.inf | High Secure incremental template for a Window |
To load a template in the GPO interface, right-click the security settings container and select import policy (as illustrated in Figure 18.7). The security settings are the only GPO settings that can be copy-pasted or imported-exported between different GPOs.To export the security settings defined in a GPO, you must use the secedit tool with the /export switch.
Figure 18.7: Importing security templates for a GPO’s security settings.
18.1.3 Security Configuration Editor
The Security Configuration Editor and Analysis (SCA) tool can be used to edit and analyze the security settings on a Windows 2000, Windows XP, or Windows Server 2003 computer. SCA was introduced in SP4 for NT4; an updated version is provided with Windows 2000, Windows XP, and Windows Server 2003.
Using the SCA, an administrator can validate a computer’s security settings against the values defined in a security template. He or she can also enforce the settings following the values defined in a security template. The security templates used by SCA are the ones used by the GPO security policy management section; they were explained in the previous section.
Like the GPO security policy management section, SCA uses the secedit.sdb security database. The SCA engine can be run from the Security Configuration and Analysis MMC snap-in or from the command prompt, using the secedit executable. Table 18.4 shows the secedit switches. Note that the secedit /refreshpolicy switch that was available in Windows 2000 to refresh GPOs has been replaced in Windows Server 2003 by the gpupdate tool.
| Secedit Switch | Meaning |
|---|---|
| /analyze | Analyze the security settings on a computer against the values defined in a security |
| /configure | Configure the security settings on a computer based on the values defined in a security template. |
| /export | Export security settings stored in secedit database. |
| /import | Import a security template into the secedit database. |
| /validate | Validate the syntax of a security template. |
| /generaterollback | Generate a rollback template with respect to a particular security template. When applying a security template to a computer, you have the option of creating a rollback template which, when applied, resets the security settings to the values before the configuration template was applied. |
18.1.4 Security Configuration Wizard
The Security Configuration Wizard (SCW or secwiz.exe) allows administrators to easily create a baseline security policy for a Windows server based on the server’s organizational role. SCW does not provide a complete Windows security policy coverage: instead it focuses on the network-related security policy settings. These include service configuration, and TCP and UDP port usage. The goal of the SCW is to help maximize the security of Windows server systems without sacrificing their required functionality. Microsoft refers to the SCW as a policy authoring tool, whose primary goal is to reduce the Windows attack surface.
The SCW constructs XML-formatted security policies for their different types of servers. These policies can be applied directly to a server using the wizard, or they can be transformed[1] into native scripts or security templates(*.inf) that can then be deployed on individual machines or via Group Policy. The SCW is linked to a database that’s referred to as the SCW knowledge base. It is made up of different xml-formatted files. These files are stored in the %windir%/security/ssr/KBs folder (ssr refers to the initial name of the tool: secure server roles) and hold the preferred security policy configuration settings for different server roles. If you want you can add your own SCW knowledge base extensions.
Microsoft makes the Security Configuration Wizard (see Figure 18.8) available as a part of Service Pack 1 (SP1) for Windows Server 2003. SCW supports Windows 2000 and Windows Server 2003.
Figure 18.8: Security Configuration Wizard.
18.1.5 Microsoft Baseline Security Analyzer
You can use the Microsoft Baseline Security Analyzer (MBSA- mbsa.exe) tool to perform a security scan on NT4 and later Windows systems. The tool can be installed on any Windows 2000 or later system. Although the MBSA tool cannot be installed on an NT4 system, it can be run against an NT4 system that has at least NT4 Service Pack 4 installed. The tool’s installation program (an *.msi file) can be downloaded for free from the Microsoft Web site. At the time of writing the latest MBSA release was version 1.1.1.
MBSA is a tool that can be run from both the Windows GUI and the command prompt (mbsacli.exe). It can analyze both the local and remote systems. It can scan for common security misconfigurations in the following products: Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Internet Information Server (IIS) 4.0, 5.0, and 6.0 SQL Server7.0 and 2000, Internet Explorer (IE) 5.01 and later, and Office 2000 and XP. MBSA can also scan for missing security patches for Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, IIS 4.0, 5.0 and 6.0, SQL Server 7.0 and 2000, Exchange 5.5 and 2000, IE 5.01 and later, and Windows Media Player 6.4 and later. Once a system is analyzed using MBSA, you must use other tools to deploy missing patches to the system (as explained in Section 18.2). More information on the MBSA tool is available in the following Microsoft Knowledge Base article: http://support.microsoft.com/default.aspx?scid=kb;en-us;q320454.
Running a security check against a system using the tool is as simple as starting the tool by double-clicking the desktop shortcut, clicking “Scan a computer,” entering the IP address of the computer you want to scan, selecting the scan options (check for Windows vulnerabilities, weak passwords, IIS vulnerabilities, and so forth), and clicking “Start scan.” Figure18.9 shows a report as it is automatically generated by the MBSA tool at the end of a security scan. The MBSA reports are stored in an XML format in the %userprofile%\Securityscans file system folder. To run MBSA, the user must have local administrator access to the computer.
Figure 18.9: Microsoft Security Baseline Analyzer.
18.1.6 Third-party security policy management tools
Microsoft currently lacks the tools to centralize security policy management and to provide advanced management features such as real-time alerting. Table 18.5 provides a nonexhaustive overview of other third-party management tools that can provide such functionality for the Windows platform.
| Third-Party Tool | More Information Is Available At… |
|---|---|
| Bindview Policy Compliance Center, Bindview Bv-Control | http://www.bindview.com/Products/PolicyComp/index.cfm |
| HP Openview Security Management | http://www.openview.hp.com |
| NetIQ VigilEnt Policy and Compliance Management | http://www.netiq.com/solutions/security/policy.asp |
18.1.7 Security policy management: Overview
Table 18.6 provides an overview of the security policy management tools explained previously and the security policy life cycle phases for which they can be used. A fundamental engine that is called on for most of the security policy life cycle phases is the security configuration engine and database. This engine and database are available on every Windows 2000, Windows XP, and Windows Server 2003 installation.
| Security Policy Life Cycle Phase | Tools |
|---|---|
| Policy Creation |
|
| Analysis |
|
| Enforcement |
|
| Reporting |
|
| Monitoring |
|
[1]At the time of writing, the tool to transform the SCW’s XML files to an *.inf file was not yet available.
EAN: 2147483647
Pages: 137