Microsoft solutions for Seuurity -Creating a Member Server Baseline

[Open Your Hands]

Creating a Member Server  Baseline

Overview

This chapter documents the configuration requirements for managing a baseline security
template for all servers running Microsoft® Windows Server™ 2003. The chapter will also
provide administrative guidance to set up and configure a secure Windows Server 2003
system in three enterprise environments. The configuration requirements in the chapter
form the baseline for all of the other hardening procedures that apply to the specific
server roles discussed in later chapters of this guide.
The setting recommendations in this chapter establish a solid foundation for business
application servers in an enterprise environment. However, you must comprehensively
test the coexistence of these security configurations with your organization's business
applications before implementing them in production environments.
The setting recommendations in this chapter are suitable for the majority of enterprises
and may be deployed on either existing or new systems running Windows Server 2003.
The default security configurations within Windows Server 2003 have been researched,
reviewed, and tested. For information about all default settings and a detailed explanation
on each of the settings discussed in this chapter, see the companion guide, Threats and
Countermeasures: Security Settings in Windows Server 2003 and Windows XP, available
at: http://go.microsoft.com/fwlink/?LinkId=15159. However, the majority of the following
configuration recommendations are for security levels that are higher than the default
settings.
The following baseline security settings for all Windows Server 2003 systems in
enterprise environments discussed in this chapter relate to the three environments
defined below. The environments are:
48
? Legacy Client — Provides adequate security that will not constrain a mixed – state
environment. The Legacy Client level is specific to environments with legacy
clients. This environment is the lowest lockdown level defined in this guide. In
order to further secure environments, organizations may choose to migrate to the
next lockdown level, the Enterprise Client level, or start at this level if they do not
have legacy clients to secure. This business environment includes Microsoft
Windows® 98, Microsoft Windows NT® version 4.0 Workstation, Window 2000
Professional, and Windows XP Professional workstations. This environment only
contains Windows 2000 or later domain controllers. There are no Windows NT 4.0
domain controllers in this environment, but Windows NT member servers may
exist.
? Enterprise Client — Provides solid security that is designed for a new system
environment. This business environment includes clients running Windows 2000
Professional and Windows XP Professional. The majority of work required to move
from the Legacy Environment to the Enterprise Environment involves upgrading
legacy clients, such as Windows 98 and Windows NT 4.0 Workstation to Windows
2000 or Windows XP. All domain controllers in this environment are Windows 2000
Server or later. Member servers in this environment are Windows 2000 Server or
later.
? High Security — Provides enhanced security standards from the previous
Enterprise Client level. Moving from the Enterprise Environment to the High
Security Environment requires conforming to stringent security policies for both
clients and servers. This environment contains clients running Windows 2000
Professional, Windows XP Professional, and domain controllers running Windows
2000 Server or later. In the High Security environment, concern about security is
so great that significant loss of functionality and manageability is considered to be
an acceptable tradeoff in order to achieve the highest level of security. Member
servers in this environment are Windows 2000 Server or later.
The following figure shows the three layers of security and the clients supported in each.
Figure 3.1
Existing and planned levels of lockdown
49
Organizations that want to provide a phased approach to securing their environments
may choose to start at the Legacy Client environment level and then gradually move to
the higher security levels as their applications and client computers are upgraded and
tested with tightened security settings.
The following figure shows how the .inf file security templates are used as a foundation
for the Enterprise Client – Member Server Baseline Policy (MSBP). The figure also shows
one possible way of linking this policy in order to apply it to all servers in an organization.
Windows Server 2003 ships with default setting values that are set to a secure state. In
many instances, this chapter prescribes settings other than default values, as well as
enforces specific defaults for the three environments defined in this guide. For
information about all default settings, see the companion guide, Threats and
Countermeasures: Security Settings in Windows Server 2003 and Windows XP, available
at http://go.microsoft.com/fwlink/?LinkId=15159.

[Open Your Hands]

The security template Enterprise Client – Member Server Baseline.inf is imported into the MSBP, which is
then linked to the Member Servers organizational unit (OU)
50
Hardening procedures for specific server roles are defined in the remaining chapters of
this guide. The primary server roles in this guide include:
? Domain controllers, which include Domain Name System (DNS) services.
? Infrastructure server roles that include:
? Windows Internet Name Service (WINS)
? Dynamic Host Configuration Protocol (DHCP)
? File
? Print
? Internet Information Services (IIS)
? Microsoft Internet Authentication Server (IAS)
? Certificate Services servers (CA)
? Bastion Hosts
Many of the settings that appear in the Enterprise Client MSBP that follow also apply to
these server roles in the three environments defined in this guide. The security templates
are uniquely designed to address the security needs of each particular environment. The
following table shows the relationship between the baseline security templates and the
three environments. If there is a need to call out specifics in the Legacy Client, Enterprise
Client, or High Security levels, the security template that relates to the recommended
baseline policy contains the level identity to distinguish the correct template for it. For
example, the Enterprise Client – Member Server Baseline.inf file is the recommended
security template for the Enterprise Client environment.
Table 3.1: Baseline Security Templates for All Three Environments
Legacy Client Enterprise Client High Security
Legacy Client – Member
Server Baseline.inf
Enterprise Client – Member
Server Baseline.inf
High Security – Member
Server Baseline.inf
The security settings common to all of the environments in the Member Server
Baseline.inf security templates are described in the section below on the Windows Server
2003 Baseline Policy. These baseline security templates are also the starting point for the
security templates for domain controllers defined in Chapter 4, "Hardening Domain
Controllers."
The Enterprise Client – Domain Controllers Role.inf template provides the baseline for the
Group Policy object (GPO) of the Domain Controllers Group Policy and is linked to the
Domain Controllers organizational unit (OU) in all three environments. Step – by – step
instructions for creating the OUs and Group Policies, and then importing the appropriate
security template into each GPO, are provided in Chapter 2, "Configuring the Domain
Infrastructure."
Note: Some hardening procedures cannot be automated using Group Policy; these are
described in the Additional Member Server Hardening Procedures section of this
chapter.

[Open Your Hands]

Windows Server 2003 Baseline Policy
The settings at the Member Server OU level define the common settings for all member
servers in the domain. This is done by creating a GPO that is linked to the Member
Server OU, known as a baseline policy. The GPO automates the process of configuring
specific security settings on each server. The following settings are described as they
appear in the user interface (UI) of the Security Configuration Editor (SCE) snap – in.


Audit Policy

Administrators should set up an audit policy. An audit policy determines the security
events to report to the network administrators so that user or system activity in specified
event categories is recorded. The administrator can monitor security – related activity,
such as who accesses an object, if a user logs on to or off from a computer, or if changes
are made to an auditing policy setting.
Before implementing audit policies, one must decide which event categories need to be
audited for the corporate environment. The auditing settings that an administrator
chooses for the event categories define the corporate auditing policy. By defining audit
settings for specific event categories, administrators can create an audit policy that suits
the security needs of an organization.
If no auditing is configured, it will be difficult or impossible to determine what took place
during a security incident. However, if auditing is configured so that too many authorized
activities generate events, the security event log will fill up with useless data. Therefore,
the following recommendations help balance the decisions on what to monitor so that the
data collected is relevant.
The table below includes the Audit Policy setting recommendations for the three
environments defined in this guide. You may notice that the settings for most values are
similar across the three environments.
The following values can be configured in the Domain Group Policy section of Windows
Server 2003 at the following location:
Computer Configuration\Windows Settings\Security Settings\Local
Policies\Audit Policy

For a summary of the prescribed settings in this section, see the Windows Server 2003
Security Guide Settings Microsoft Excel spreadsheet. For information on the default
settings and a detailed explanation of each of the settings discussed in this section, see
the companion guide, Threats and Countermeasures: Security Settings in Windows
Server 2003 and Windows XP, available at: http://go.microsoft.com/fwlink/?LinkId=15159.
Audit account logon events
Table 3.2: Settings
Member Server Default Legacy Client Enterprise Client High Security
Success Success Failure Success Failure Success Failure
The Audit account logon events setting determines whether to audit each instance of a
user logging on to or off another computer that validates the account. Authenticating a
domain user account on a domain controller generates an account logon event. The
event is logged in the domain controller's security log. Authenticating a local user on a
local computer generates a logon event. The event is logged in the local security log.
There are no Account logoff events logged.
53
The following table includes some of the important security events that this setting logs in
the Security Event Log.
Table 3.3: Account Logon Events
Event ID Event Description
672 An authentication service (AS) ticket was successfully issued and validated.
673 A ticket granting service (TGS) ticket was granted. A TGS is a ticket issued by the
Kerberos version 5 ticket – granting service TGS that allows a user to
authenticate to a specific service in the domain.
674 A security principal renewed an AS ticket or TGS ticket.
675 Pre – authentication failed. This event is generated on a Key Distribution Center
(KDC) when a user types in an incorrect password.
676 Authentication ticket request failed. This event is not generated in Windows XP
Professional or in members of the Windows Server family.
677 A TGS ticket was not granted. This event is not generated in Windows XP
Professional or in the members of the Windows Server family.
678 An account was successfully mapped to a domain account.
681 Logon failure. A domain account logon was attempted. This event is not
generated in Windows XP Professional or in members of the Windows Server
family.
682 A user has reconnected to a disconnected terminal server session.
683 A user disconnected a terminal server session without logging off.
The event IDs above can be useful when creating custom alerts to monitor any software
suite, for example, Microsoft Operations Manager (MOM).
Audit account management
Table 3.4: Settings
Member Server Default Legacy Client Enterprise Client High Security
No Auditing Success Failure Success Failure Success Failure
The Audit account management setting determines whether to audit each account
management event on a computer. Examples of account management events include:
? A user account or group is created, changed, or deleted.
? A user account is renamed, disabled, or enabled.
? A password is set or changed.
Organizations need to be able to determine who has created, modified, or deleted both
domain and local accounts. Unauthorized changes could indicate mistaken changes
made by an administrator who does not understand how to follow corporate policies or a
deliberate attack.
For example, account management failure events often indicate that a lower – level
administrator — or an attacker who has compromised a lower – level administrator's
account — might be attempting to elevate his or her privilege. From the logs you can see
which accounts an attacker has modified and created.
54
For this reason, the countermeasure for this setting is to configure it to include both the
Success and Failure values for all three environments. The following table includes
some of the important security events that this setting records in the Security Event Log.
Table 3.5: Account Management Events
Event ID Event Description
624 A user account was created.
627 A user password was changed.
628 A user password was set.
630 A user account was deleted.
631 A global group was created.
632 A member was added to a global group.
633 A member was removed from a global group.
634 A global group was deleted.
635 A new local group was created.
636 A member was added to a local group.
637 A member was removed from a local group.
638 A local group was deleted.
639 A local group account was changed.
641 A global group account was changed.
642 A user account was changed.
643 A domain policy was modified.
644 A user account was automatically locked.
645 A computer account was created.
646 A computer account was changed.
647 A computer account was deleted.
648 A local security group with security disabled was created.
Note: SECURITY_DISABLED in the formal name means that this group cannot
be used to grant permissions in access checks.
649 A local security group with security disabled was changed.
650 A member was added to a security – disabled local security group.
651 A member was removed from a security – disabled local security group.
652 A security – disabled local group was deleted.
653 A security – disabled global group was created.
654 A security – disabled global group was changed.
655 A member was added to a security – disabled global group.
656 A member was removed from a security – disabled global group.
657 A security – disabled global group was deleted.
658 A security – enabled universal group was created.
659 A security – enabled universal group was changed.
660 A member was added to a security – enabled universal group.
661 A member was removed from a security – enabled universal group.
662 A security – enabled universal group was deleted.
663 A security – disabled universal group was created.
55
(continued)
664 A security – disabled universal group was changed.
665 A member was added to a security – disabled universal group.
666 A member was removed from a security – disabled universal group.
667 A security – disabled universal group was deleted.
668 A group type was changed.
684 The security descriptor of administrative group members was set.
Note: Every 60 minutes on a domain controller, a background thread searches all
members of administrative groups (such as domain, enterprise, and schema
administrators) and applies a fixed security descriptor on them. This event is
logged.
685 Name of an account was changed.
The event IDs above can be useful when creating custom alerts to monitor any software
suite, for example, MOM. Most operational management software can be customized
with scripts in order to capture or flag events based on the event IDs above.

[Romio]

This is great man. Thanks....