Agent Security

The agent in MOM 2005 features some enhancements from those in MOM 2000 SP1, such as a separate account context for the MOM Service and the responses on the agent. This section gives an overview of these features.

MOM Service (MOMService.exe)

The MOM Service is roughly equivalent to the OnePoint Service in MOM 2000 SP1 and handles the infrastructure of the agent and the communications with the Management Server. The service must run as Local System (on Windows 2000 or Windows Server 2003) and Network Service (only on Windows Server 2003). The account should not be changed or assigned to another account.

The MOM Service runs as the MOMService.exe process. There is only one MOMService.exe process running at a time on the agent.

Specifically, the MOMService.exe performs the following tasks:

• Application event log - Read / Write

• Security event log - Read / Write

• WMI event provider (this thread within the MOMService.exe actually runs under the agents Action Account) - Read

• File Transfer - Receive

• File Transfer - Send (when using Windows Server 2003 or Windows 2000 with the Background Intelligent Transfer Service (BITS) 1.5 installed).

Action Account

The agents Action Account is used to gather information about, and run responses on, the managed computer. The MOMHost.exe processes runs under the Action Account as well as specific threads within the MOMServic.exe. Because more than one data provider or more than one response might be running at one time, MOM runs these as separate processes to protect other MOMHost.exe processes, should one of them fail. Therefore, there might be more than one MOMHost.exe process running at any given time on the agent.

Specifically, the MOMHost.exe can perform the following tasks:

• Monitors and collects Windows event log data.

• Monitors and collects Windows performance counter data.

• Monitors and collects Windows Management Instrumentation (WMI) data.

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

• Runs management pack responses, such as scripts or batches

• Runs managed code responses ("managed code" refers to code written upon the .NET Frameworks)

The separation of the MOMService process from the MOMHost process and the use of multiple MOMHost processes means that if a script running on the managed computer becomes stalled or fails, this will not affect the functionality of the MOM Service or other responses on the managed computer. This makes MOM 2005 agents more robust.

Using a Low-Privileged Account

You can use a low-privileged account for the agents Action Account under certain circumstances. On Windows 2000, the Action Account must be a member of the local administrators group or Local System. On Windows Server 2003, the account must have the following minimum privileges:

• Member of the local Users group

• Member of the local "Performance Monitor Users" group

• "Manage auditing and security log" permission (SeSecurityPrivilege)

• "Allow log on locally" permission (SeInteractiveLogonRight)

Important

The minimum privileges above are the lowest privileges that MOM 2005 supports. The actual privileges required for the Action Account will depend upon which Management Packs are running on the computer and how they are configured. For more information about what specific privileges are required, see the appropriate Management Pack Guide.

A low-privileged account can be used only on Windows Server 2003. On Windows 2000, the Action Account must be a member of the local administrator security group or Local System.

You might need to add other privileges to the Action Account for Management Packs to function properly. By default, the MOM setup only installs the Microsoft Operations Manager 2005 Management Pack. This Management Pack requires only that the account used for the Action Account have access to the following:

Table 5 - Access Types Required By the MOM 2005 Management Pack

The SNMP Response cannot be run when using a low-privileged account. If you require the use of the SNMP Response, then you must specify an account with administrator-level privileges for the agents Action Account.

Note

    The Action Account must be either a member of the Administrators group or Local System for MOM to monitor the Internet Information Services (IIS) logs.

Using a Highly-Privileged Account

You can also use a highly-privileged account if your security needs permit this. Using a highly-privileged account means that all management packs features will work.

Using a Domain Account

Although you could use a single domain account for several agent Action Accounts, this practice is not recommended by Microsoft because if the account credentials are discovered by an attacker they can use the account to attack many computers. You can use a different domain account for each Action Account, but the passwords might be forced to expire by global policy. In this case, using a local account might produce less management overhead.

Using the Local System Account

You can run the agent action account as Local System. Doing this will ensure that all management packs run with the correct user rights; however, the Local System account is an administrator-level account and using it might present a security issue. If an attacker is able to compromise the MOM processes, they can perform any action on the managed computer as Local System and even mount attacks against the Management Server under certain circumstances. Because of this, you can also use a lower-privileged account.

Action Account Password Changes

You can use the SetActionAccount.exe utility in the %Program Files%\Microsoft Operations Manager 2005 directory to change the password easily. You can also use this utility to specify a different account for the Action Account. You can use the utility 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 for the new password.

 - the management group must be specified, even if the agent is not multihomed.

Note

    You must restart the MOM Service on the computer for this change, or any other permission change to the Action Account, to complete.

Agent Proxying

In MOM 2005, an agent can forward data on behalf of another computer or network device. This is called "agent proxying". If you disable agent proxying, the Management Server attempts to match the data being sent from the agent and the agent name. If no match is found the data is rejected and an event is logged. This feature is intended to help prevent spoofing attacks where an attacker poses as an agent (or sends data to the agent that it will forward) and attempts to send data to the Management Server. For multi-homed agents, each management group has its own setting on the agent for agent proxying.

This setting is management group-wide, but you can override the setting for individual agents.

Note

    If mutual authentication is disabled, the agent proxying setting will be ignored and all agents can proxy, regardless of the setting.

Multihomed Agents

When an agent reports to more than one management group (or to a MOM 2000 SP1 configuration group), this is called "multihoming." This is accomplished by creating and running multiple instances of the component that communicates with the Management Server. These run within a single instance of the MOM Service process. Each instance of the communication component runs separately from the others and if one of them encounters problems it will not affect the operations of another.

Each instance runs under the MOM Service context for that management group (if they are different) and within the same MOM Service process. This means that if one instance fails, it will not affect the communications between the agent and the other management group. However, if the MOM Service is halted, all communication with all management groups is halted.

If an agent is unable to communicate with one management group, such as if the network between the two is down, then the agent might still be able to communicate with the other management groups. You cannot have two agents with different mutual authentication settings reporting to the same Management Server.

Agents Beyond a Firewall

You can have managed computers beyond a firewall from the Management Server and communications between them will be normal, if you open the TCP/UDP port 1270. However, you must manually install and update these agents.

Mutual authentication and the signed and encrypted communications will still be available, if a full Active Directory trust relationship exists between the Management Server domain and the agent domain. Otherwise only signed and encrypted communications are available.

Agents in a Non-Trusted Domain or a Workgroup

You can have agents in non-trusted domains or workgroups; however, mutual authentication is not available because, by definition, no two-way trust relationship exists between the Management Server domain and the agent domain. The secure channel is still available, however. You must install and update the agents manually. If the Management Server is configured to require mutual authentication, these agents will not be able to communicate with it.

To changes settings on agents outside a firewall, in a non-trusted domain or workgroup, or whose Control Level is set to "None", use the "To update an agent outside a firewall" procedure in this guide.