Windows Server 2008 R2 Unleashed (160 page)

Monitoring Nondomain Member Considerations

DMZ, Workgroup, and Nontrusted Domain Agents require special configuration; in partic-

ular, they require certificates to establish mutual authentication. Operations Manager 2007

R2 requires mutual authentication, that is, the server authenticates to the client and the

client authenticates to the server, to ensure that the monitoring communications are not

hacked. Without mutual authentication, it is possible for a hacker to execute a man-in-

the-middle attack and impersonate either the client or the server. Thus, mutual authenti-

cation is a security measure designed to protect clients, servers, and sensitive Active

ptg

Directory domain information, which is exposed to potential hacking attempts by the all-

powerful management infrastructure. However, OpsMgr relies on Active Directory

Kerberos for mutual authentication, which is not available to nondomain members.

NOTE

Workgroup servers, public web servers, and Microsoft Exchange Edge Transport role

servers are commonly placed in the DMZ and are for security reasons not domain

members, so almost every Windows Server 2008 R2 environment will need to deploy

certificate-based authentication.

In the absence of Active Directory, trusts, and Kerberos, OpsMgr 2007 R2 can use X.509

certificates to establish the mutual authentication. These can be issued by any PKI, such as

Microsoft Windows Server 2008 Enterprise CA. See Chapter 14, “Transport-Level Security,”

for details on PKI and Windows Server 2008 R2.

Installing agents on DMZ servers is discussed later in this chapter in the section

“Monitoring DMZ Servers with Certificates.”

Securing OpsMgr

Security has evolved into a primary concern that can no longer be taken for granted. The

inherent security in Windows Server 2008 R2 is only as good as the services that have

access to it; therefore, it is wise to perform a security audit of all systems that access infor-

mation from servers. This concept holds true for management systems as well because

812

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

they collect sensitive information from every server in an enterprise. This includes poten-

tially sensitive event logs that could be used to compromise a system. Consequently,

securing the OpsMgr infrastructure should not be taken lightly.

Securing OpsMgr Agents

Each server that contains an OpsMgr agent and forwards events to management servers

has specific security requirements. Server-level security should be established and should

include provisions for OpsMgr data collection. All traffic between OpsMgr components,

such as the agents, management servers, and database, is encrypted automatically for secu-

rity, so the traffic is inherently secured.

In addition, environments with high-security requirements should investigate the use of

encryption technologies such as IPSec to scramble the event IDs that are sent between

agents and OpsMgr servers, to protect against eavesdropping of OpsMgr packets.

OpsMgr uses mutual authentication between agents and management servers. This means

that the agent must reside in the same forest as the management server. If the agent is

located in a different forest or workgroup, client certificates can be used to establish

mutual authentication. If an entire nontrusted domain must be monitored, the gateway

server can be installed in the nontrusted domain, agents can establish mutual authentica-

tion to the gateway server, and certificates on the gateway and management server are

ptg

used to establish mutual authentication. In this scenario, you can avoid needing to place a

certificate on each nontrusted domain member.

Understanding Firewall Requirements

OpsMgr servers that are deployed across a firewall have special considerations that must

be taken into account. Port 5723, the default port for OpsMgr communications, must

specifically be opened on a firewall to allow OpsMgr to communicate across it.

Table 23.1 describes communication for this and other OpsMgr components.

TABLE 23.1

OpsMgr Communication Ports

From

To

Port

Agent

Root Management Server

5723

Agent

Management server

5723

Agent

Gateway server

5723

Agent (ACS forwarder)

Management server ACS collector

51909

Gateway server

Root Management Server

5723

Gateway server

Management server

5723

Management or Gateway server

UNIX or Linux computer

1270

Management or Gateway server

UNIX or Linux computer

22

Securing OpsMgr

813

TABLE 23.1

OpsMgr Communication Ports

From

To

Port

Management server

Operations Manager database

1433

Management server

Root Management Server

5723, 5724

Management server

Reporting data warehouse

1433

Management server ACS collector

ACS database

1433

Operations Console

Root Management Server

5724

23

Operations Console (reports)

SQL Server Reporting Services

80

Reporting server

Root Management Server

5723, 5724

Reporting server

Reporting data warehouse

1433

Root Management Server

Operations Manager database

1433

Root Management Server

Reporting data warehouse

1433

Web console browser

Web console server

51908

Web console server

Root Management Server

5724

ptg

The firewall port for the agents is the port that needs to be opened most often, which is

only port 5723 from the agent to the management servers for monitoring. Other ports,

such as 51909 for ACS, are more rarely needed. Figure 23.6 shows the major communica-

tions paths and ports between OpsMgr components.

Operations

Reporting

Database Server

Database Server

1443

Gateway

Server

1443

1443

Root

1443

Management

Management

Server(s)

.5723 OpsMgr

.5723 OpsMgr

5723 OpsMgr

Server

5723 OpsMgr

5723 OpsMgr

5723 OpsMgr

1443

5723 OpsMgr

5723 OpsMgr

5723 OpsMgr

51909 ACS

51909 ACS

51909 ACS

5724

51908

5723 OpsMgr

5723 OpsMgr

5723 OpsMgr

5724

5723 OpsMgr

5723 OpsMgr

5723 OpsMgr 51909 ACS

51909 ACS

51909 ACS

51909 ACS

51909 ACS

51909 ACS

Exchange Shell Operations

Web

Console

Console

Agents

FIGURE 23.6

Communications ports.

814

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

Outlining Service Account Security

In addition to the aforementioned security measures, security of an OpsMgr environment

can be strengthened by the addition of multiple service accounts to handle the different

OpsMgr components. For example, the Management Server Action account and the

SDK/Configuration service account should be configured to use separate credentials, to

provide for an extra layer of protection in the event that one account is compromised.

.
Management Server Action account—
The account responsible for collecting data

and running responses from management servers.

.
SDK and Configuration service account—
The account that writes data to the

operations database; this service is also used for all console communication.

.
Local Administrator account—
The account used during the agent push installa-

tion process. To install the agent, local administrative rights are required.

.
Agent Action account—
The credentials the agent will run as. This account can run

under a built-in system account, such as Local System, or a limited domain user

account for high-security environments.

.
Data Warehouse Write Action account—
The account used by the management

server to write data to the reporting data warehouse.

ptg

.
Data Warehouse Reader account—
The account used to read data from the data

warehouse when reports are executed.

.
Run As accounts—
The specific accounts used by management packs to facilitate

monitoring. These accounts must be manually created and delegated specific rights

as defined in the management pack documentation. These accounts are then

assigned as Run As accounts used by the management pack to achieve a high degree

of security and flexibility when monitoring the environment. New to OpsMgr 2007

R2 is the ability to selectively distribute the Run As Account to just the agents that

need them.

Installing Operations Manager 2007 R2

As discussed in the previous section, Operations Manager 2007 R2 is a multitier and multi-

component application that can be deployed in a variety of architectures. This allows

OpsMgr to support scaling from a small organization to a very large enterprise.

For the purposes of this chapter, an all-in-one single-server install is used. This allows for

monitoring of small- to medium-sized Windows Server 2008 R2 organizations spanning a

handful of servers to up to 250 servers.

Installing Operations Manager 2007 R2

815

Single-Server OpsMgr 2007 R2 Install

This section steps through the install of OpsMgr and Reporting on a single-server configu-

ration. The specification for a single-server configuration to support up to 250 agent

systems is as follows:

. 2 x 2.8GHz Cores

. 8GB RAM

. 4 Drive RAID 0+1 Disk (200+GB Space)

23

These hardware requirements ensure that the system can perform to specification.

NOTE

If the configuration were to be virtualized on a Windows Server 2008 Hyper-V host or a

VMware ESX host, a single-server configuration is not recommended. Instead, a two-

server configuration is recommended and SQL Server 2008 should be installed on the

second server to balance the load.

ptg

The steps in this section assume that the single server has been prepared with the following:

. Windows Server 2008 R2 operating system installed

. Web role with the appropriate features installed

NOTE

To install SQL Reporting Services and the Web components of OpsMgr 2007 R2, the

following Windows Server 2008 Web role features need to be installed: Static Content,

Default Document, HTTP Redirection, Directory Browsing, ASP, ASP.NET, ISAPI Extension,

ISAPI Filters, Windows Authentication, IIS Metabase, and IIS 6 WMI.

. SQL Server 2008 with Reporting Services installed

. An OpsMgr service account with local administrator rights to the server and system

administrator rights to SQL Server 2008

This prepares the system for the install of OpsMgr 2007 R2. See the following prerequisite

checker information for additional requirements and how to check them.

Before installing, it is important to run the built-in prerequisite checker. This utility is

available on the OpsMgr installation media and confirms a host of software prerequisites

before attempting the actual installation. This gives the administrator time to download

816

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

and install the necessary software, rather than have the installation bomb out in the

middle after entering a lot of configuration information.

This section assumes a Windows Server 2008 and SQL Server 2008 server will be used for

the single-server installation, but the prerequisite checker looks at more general require-

ments based on the OpsMgr supported platforms. The prerequisite checker looks for the

following software on a single-server configuration:

. Windows Server 2003 Service Pack 1 or Windows Server 2008 Service Pack 1

. Microsoft SQL Server 2005 Service Pack 1 or SQL Server 2008 Service Pack 1

. Microsoft SQL Server 2005 Reporting Services Service Pack 1 or SQL Server 2008

Reporting Services Service Pack 1

. World Wide Web Service is running and set for automatic startup

. WS-Management v1.1

. MDAC version 2.80.1022.0 or higher

. ASP.NET AJAX Extensions 1.0

. .NET Framework 2.0 and .NET Framework 3.0 components

ptg

. Windows PowerShell

. Key hotfixes

To use the Prerequisite Viewer for a single-server configuration, run the following steps:

1. Log on with an account that has administrator rights.

2. Insert the Operations Manager 2007 R2 installation media.

3. The setup will start automatically or launch the SetupOM.exe.

4. Click Check Prerequisites to start the Prerequisite Viewer.

5. Select Operational Database, Server, Console, PowerShell, Web Console, Reporting,