Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
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.”
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,