Using Operations Manager to Monitor Exchange Server 2010 : Securing OpsMgr

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 security, 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 non-trusted domain must be monitored, the gateway server can be installed in the non-trusted domain, agents can establish mutual authentication to the gateway server, and certificates on the gateway and management server are used to establish mutual authentication. In this scenario, you can avoid needing to place a certificate on each non-trusted 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 1 describes communication for this and other OpsMgr components.

The agent is the component that ports need 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 1 shows the major communications paths and ports between OpsMgr components.

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 installation 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.

• 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.