Configuring MOM Security

The most logical place to start with MOM security is the Management Server Action Account (MSAA) as well as the Data Access Server Account (DASA). These two accounts are configured during MOM installation. The MSAA is used by the Management Server (MOM server) to poll data providers, execute responses, and perform various actions, including installing and uninstalling agents. A common use of the Management Server is to distribute agents to managed machines. If "pushing" and updating agents is something you want MOM to do, then you need to ensure that the MSAA is a domain account with administrator privileges on all machines that are candidates for being monitored by MOM. Microsoft does not recommend using a domain administrator account for the MSAA; if you attempt to do this during setup of MOM (you can ignore this warning by simply clicking Next) you will see the screen shown in Figure 14-1.

Figure 14-1

When you configure the MSAA account, you are really setting the security context of the MOMHost.exe process; this process is used for each task (thread) to be performed by MOM. To help you in evaluating what permissions your MSAA account will need, MOMHost.exe performs the following tasks on the Management Server:

• Monitors and collects Windows event log data.

• Monitors and collects Windows performance counter data.

• Monitors and collects Windows Management Instrumentation (WMI).

• Monitors and collects application-specific log data, such as IIS logs.

• Run Management Pack responses, such as scripts or batches.

• Runs managed code responses (see Chapter 11 for more details on managed responses).

You may want to consider assigning a domain account with a password that never expires, but in the event that your security policies are too strict to allow this you can always update the MSAA's password using the SetActionAccount.exe tool. SetActionAccount.exe is located in the %Program Files%\ Microsoft Operations Manager 2005 directory. You can use the tool as follows:

     Options:     //returns the current Action Account settings for the specified management group.     /sets the Action Account for the specified management group. - the tool will prompt you fo the new password.     - the management group must be specified, even if the agent is not multihomed. 

The DASA runs on the Management Server and accesses the data in the MOM database (OnePoint). The communication takes place over OLEDB. In the typical deployment model of MOM, both the database and the MOM server are on the same machine. In those cases when the database is remote, you should use a credential that has access to the database server. It's also worth noting that the MOM communication to the database is not secure by default; you can implement IPSec or OLEDB Encryption (SSL) to remedy this.

Important 

There is a step in the MOM installation process that asks if you wish to enable MOM Error Reporting. If you do wish to help Microsoft via this option, it uses a secure transmission, but we recommend using the "Queue reports and let me approve sending them to Microsoft" option. If you allow the automatic sending of error reports, keep in mind that this applies to not only the MOM server but also all managed machines as well.

Deploying Agents and the Agent Action Account

You can deploy agents to managed machines in one of two ways: automatically via discovery or manually using the Install/Uninstall Agents Wizard with the "add computers by name" option. Each method requires security considerations and configuring. Let's review both of them.

Discovery-Based Agent Deployment

Discovery is when you "discover" computers that match certain criteria you specify. Discovery is used in two places: the Install/Uninstall Agents Wizard with the Search Criteria option, and when the Management Server is configured to use full discovery (approval-required or automatically). In order for the Management Server to deploy agents to managed machines automatically, the following are required:

• The Server Message Block (SMB)

• The RPC port (135/TCP)

• The DCOM port range

All of these ports must be enabled on both the Management Server as well as the managed machines or you must install the agents manually. If a firewall is present between the Management Server and the desired managed machine and the required ports cannot be opened, automatic deployment obviously will not work.

Important 

Disabling the File and Printer Sharing for Microsoft Networks and the Client for Microsoft networks services disables the SMB ports.

If any of the ports in the preceding list are not open or any of the following issues are present, again automatic agent deployment will not work:

• The target machine is in an IPSec-enabled domain and the Management Server is in a non-IPSec-enabled domain.

• The target machine is running Windows NT 4.0.

• The target machine is a Microsoft Cluster Services Virtual server.

Manual-Based "push" Agent Deployment

In some situations, including some described in the preceding section, you simply cannot use discovery-based deployment. Manually pushing agents has its own security considerations. First, you must be logged on to the target machine with administrative credentials; you can either use the MSAA or specifically set the credentials. Port 1270 is used by default to communicate between the agent and the Management Server; thus, this port or whichever port you choose needs to be opened on both machines.

The AAA

The agent action account is the security context used to gather information and execute responses on the managed computer. The MOMHost.exe process runs under the AAA on the managed machine. The MOMHost.exe process performs the following activities on the managed machines:

• Monitors and collects Windows event log data

• Monitors and collects Windows performance counter data

• Monitors and collects WMI

• Monitors and collects application-specific log data, such as IIS logs

• Runs Management Pack responses, such as scripts or batches

• Runs managed code responses (see Chapter 11 for more details on managed responses)

On a Windows 2000 machine, the AAA must be a member of the local administrators group or LocalSystem. On a Windows 2003 machine, the AAA must have these minimum privileges:

• Member of the local Users group

• Member of the local Performance Monitor Users group

• Managed auditing and security log rights

• Log on locally rights

Important 

These are the bare minimum privileges required by the AAA; each time you deploy new rules to a particular managed machine, you must consider what the agent must do to support those rules!

By default, the AAA uses the Local System account on the machine, and this is a good setting to ensure it runs under the correct security context and can perform most any action required by management packs. However, because the Local System account is an administrative account, it can present a security concern. You can create a dedicated domain account for all AAA on your network, but Microsoft discourages this practice because of hackers or malicious users who might compromise the account.

Advanced MOM Security

There are several optional security methods you can use to improve the security of your MOM environment. In the sections that follow, we discuss the following advanced MOM security topics:

• Using the IIS Lockdown tool

• Using IPSec

• Using Secure Sockets Layer (SSL)

• Using OLEDB encryption

• Using SMB packet signing

Using the IIS Lockdown Tool

The IIS Lockdown tool (which is very appropriately named) turns off unnecessary features of IIS. While using the IIS Lockdown tool is a good practice, there are just a few "gotchas" to be aware of. If you run the tool on a Management Server, be sure to re-enable ASP.NET after running the tool because the Web Console depends on ASP.NET. Running the tool on a reporting server requires you to re-enable ASP.NET and that you initially run the IIS Lockdown tool using the FrontPage Extensions template.

Using IPSec

IPSec is a framework for ensuring secure communications over Internet Protocol (IP) networks via cryptographic security services. The Microsoft implementation of IPSec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec working group. Windows Server 2003, Windows 2000, and Windows XP all support IPSec through Active Directory integration. IPSec policies can be applied at the domain, site, or organizational unit level. In addition, you can use the Local Security Policy MMC tool to configure local IPSec.

You can use IPSec to enhance the security of data flowing between the Management Server and the MOM database server, between the Management Server and the Administrator or Operator Consoles, or between the MOM database server and the MOM Reporting database. The settings for all of these connections that use IPSec will be the same, except for the IP address, and are summarized in the following list:

• Filter action: Require Security

• Authentication method: Kerberos V5 Protocol (default)

• Connection type: All network traffic (default)

• Tunnel setting: This rule does not specify an IPSec tunnel (default)

Important 

The communication between the Management Server and the agents is secured by default and IPSec is not needed.

Using SSL

SSL encryption uses a server certificate to create a securely shared session key between the server and the client browser used in symmetrical encryption/decryption. You must install a server certificate before you can enable SSL encryption. You can use SSL to securely transmit data to the Reporting Console or Web Console, or between MCF connectors.

Using OLEDB Encryption

OLEDB encryption uses SSL to communicate between clients and a named SQL Server instance. By using OLEDB encryption you can encrypt data flowing between the Management Server and the MOM database server or between the database server and the reporting database.

Using SMB Packet Signing

SMB does not encrypt data; rather, it digitally signs it to ensure that the data has not been tampered with while in transit. Your Management Server uses SMB to deliver the files required to install agents on remote machines as well as to update them. To enable SMB packet signing, use either the global or local security policy MMC tools and enable the following:

• Microsoft network client: Digitally sign communications (always)

• Microsoft network server: Digitally sign communications (always)

MOM Security Best Practices

Now that you have a good foundation in MOM security, the following are Microsoft's "Reducing Risks in MOM 2005" recommendations:

• Enable mutual authentication.

• Enable SMB packet signing or IPSec.

• Use a local account for the AAA.

• On Windows Server 2003 you can use a low-privilege MSAA.

• Use SSL to secure traffic between the Management Server and Web Console as well as between the reporting server and Reporting Console.

• Use SSL to secure traffic between MCF connectors.