Management Server Security

  • Article

The MOM 2005 Management Server is the equivalent of the MOM 2000 SP1 DCAM. The functionality of the DCAM has been separated into three separate parts and each part can be run under different credentials in MOM 2005. This has been done for greater security, scalability, flexibility, and availability in MOM. The three parts handle communications with the agents, with the MOM database, with the agent on the Management Server itself, and with agentless-managed computers.

New in MOM 2005 is the MOM Connector Framework (MCF), which gives MOM the ability to receive data from, and send data to, other management products.

Data Access Service (DAS)

The DAS component runs on the Management Server and accesses and updates data in the MOM Database (OnePoint). The DAS component communicates over OLEDB, with the MOM Database Server. By default this transmission is not encrypted, but you can use either IPSec or OLEDB Encryption (SSL) to secure this data. For more information about using these technologies, see the "Configuring Additional Security" section in this guide.

The authentication and authorization for access to DAS functionality is enabled through COM+ roles. These roles are created by setup and should not be altered.

Important

    When you upgrade to MOM 2005, the DAS accounts privileges are unchanged from those in MOM 2000 SP1. This means this account is a local administrator and has much greater access to your databases than is necessary. You should change these to match the minimum privilege level required by MOM 2005. For more information, see the "Configuring Security After Upgrade" section in this guide.

Changing the DAS Account After Setup

You can specify a different account or change the DAS accounts password at any time, however, if you do, you also need to do the following:

  • Change the account settings on the Identity tab of the Microsoft Operations Manager Active Operations Data Access Service COM+ application on the Management Server.

  • If you are using a different account, you must also add that account as a SQL Server Security Login with "Permit" server access.

  • Give the account "db_owner" access to the OnePoint database on the MOM Database Server (if you are using a different account. MOM setup grants the DAS account this access by default).

  • If you also have the MMPC installed, add the account to the MOM Service security group on the Management Server.

MOM Service (MOMService.exe)

The MOM Service is comprised of the agent communications component and the agent on the Management Server. The MOM Service runs 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 will run as Local System on Windows Server 2003 if the Action Account is run as Local System.

Important

    The MOM Service will not start if it changed to run under credentials other than Local System or Network Service.

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

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 Action Account is new in MOM 2005 and is used to gather operations data from, and to run responses on, the Management Server. It can also be used to install agents on remote computers or update agent settings. These tasks run as a separate account so that the MOM Service functions can be separated from the other functions on the Management Server, such as Server-Side Responses, and from the agent management functions, such as installing or removing agents.

The MOMHost.exe process runs under the Action Account as well as specific threads within the MOMServic.exe. There can be more than one MOMHost.exe process running at one time.

Agent Management

The Management Servers Action Account can be used for installing/uninstalling agents on remote computers and updating settings on agents. If you choose to use the account for this purpose, the account must be a domain account with administrator privileges on all target computers that it is to install agents on.

An alternative to using this highly-privileged account is to configure the Management Servers Action Account to be a low-privileged account and to either specify credentials for installing agents when you use the Install/Uninstall Agent Wizard or to manually install agents. For more information, see the "Security For Agent Deployment" section in this guide. When you want to update agent settings, you can specify the proper credentials in the Update Agent Settings dialog in the MOM 2005 Administrator console.

Management Server Agent Tasks

The Management Servers Action Account is used to gather information about, and run responses on, the Management Server, even if you choose to not use it for agent management purposes. The account runs these agent tasks as one or more MOMHost.exe processes. 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 Management Server.

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 Management Server becomes stalled or fails, this will not affect the functionality of the MOM Service or other responses on the Management Server. This makes MOM 2005 Management Servers and agents more robust.

Action Account Password Changes

Because the Action Account must be a domain user account to access Active Directory, its password might expire or be forced to change by Global Policy. You can use the SetActionAccount.exe tool in the %Program Files%\Microsoft Operations Manager 2005 directory to change the password easily. 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 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.

Server-Side Responses

In MOM 2005, you can define code, called "Server-Side Responses," to be run on the MOM Management Server in response to data collected from a managed computer. This is a potential security risk because anyone with the ability to spoof operational data can cause Server-Side Responses to execute. Custom Server-Side Responses run within the MOMHost.exe process whereas non-custom Server-Side Responses run within the MOMService.exe process.

The enable/disable Server-Side Responses setting affects only custom Server-Side Responses. The setting is management group-wide and is disabled by default for both new installation of, and upgrades to, MOM 2005. If a management pack requires or uses these custom responses, you must enable the setting. None of the management packs that ship with MOM 2005 require Server-Side Responses. The following types of responses are affected by this setting:

  • Script responses configured to be launched on the Management Server.

  • Notification responses when a command is specified.

  • Command/batch file responses configured to be executed from the Management Server.

  • Managed-code responses.

The following responses are not affected by this setting and will always be executed:

  • Any response configured to be executed locally on the managed computer.

  • Notification responses that use email or page notifications.

  • Update state variable responses.

  • SNMP trap responses.

File Transfer Responses

In MOM 2005, you can configure MOM to transfer files from a File Transfer server to a MOM 2005 agent, or from a MOM 2005 agent to a File Transfer server, in response to Task being run or rule criteria being met. File transfer responses run as Local System (on Windows 2000 or Windows Server 2003) and Network Service (only on Windows Server 2003) regardless of the privileges given to the Action Account.

Note

    The Network Service (only on Windows Server 2003) account does not have sufficient privileges to start the BITS service. You can either start the service manually, or configure the service to start automatically.

Download

The file transfer response uses the HTTP protocol to download files from a File Transfer server to a MOM 2005 agent. The files download to the %Program Files%\Microsoft Operations Manager 2005\Downloaded Files\<Management Group Name> directory. You can specify the default virtual directory as the source directory for these files by using the Web Addresses global setting dialog in the MOM Administrator console. You can override this setting by specifying other virtual directories for any Task or response. The source server must be running IIS 5.0 or above and the BITS service must be enabled.

Note

    No default URL for the file transfer server virtual directory is configured during MOM setup. If you do not specify this URL in the global settings dialog you will receive the "File Transfer Response - Default global virtual directory not configured" alert until it is set.

Upload

The file transfer response uses the HTTP protocol to upload files from the managed computer to the virtual directory specified in the Web Addresses global setting. You can override this setting by specify other virtual directories for each Task or response. BITS requires IIS 5.0 on Windows 2000 Server and IIS 6.0 on the Windows Server 2003 family; BITS does not support IIS 5.1 on Windows XP.

File upload is available for only Windows Server 2003. You cannot use file transfer for upload in Windows 2000 unless Background Intelligent Transfer Service (BITS) 1.5 has been installed. For more information about installing BITS 1.5 on Windows 2000 on the Management Server (or the server that the files are being uploaded to), search for "Background Intelligent Transfer Service Version 1.5" (Server Component) on the Microsoft Download Center website. For more information about installing BITS 1.5 on Windows 2000 on the MOM 2005 agent, search for "Background Intelligent Transfer Service Version 1.5" (Client) on the Microsoft Download Center website.

Note

    Some IIS installations include the UrlScan filtering component. If UrlScan is enabled, the administrator must add the "BITS_POST" verb to UrlScan's list of allowed HTTP verbs. Otherwise, BITS client uploads will fail. For further details on enabling verbs in UrlScan, see the UrlScan documentation

Setting Permissions on Virtual Directories For security reasons, BITS does not upload files to a virtual directory that has scripting and execute permissions enabled. If you upload a file to a virtual directory that has these permissions enabled, the job fails with an error code of BG_E_SERVER_EXECUTE_ENABLED.

BITS does not require the virtual directory to be write enabled, so it is recommended that you turn off write access to the virtual directory.

The authenticated user (or IISs Anonymous user for anonymous authentication) must have Change permissions on the physical directory to which the virtual directory is mapped; granting Write permissions does not suffice.

Securing File Transfers

By default, these file transfers are not secured. You can use Secured Sockets Layer (SSL) encryption to secure these transmissions. For more information about using SSL with IIS, see the Internet Information Services (IIS) help. For more information about using BITS, search the MSDN web site for "Using BITS" at https://go.microsoft.com/fwlink/?LinkId=942.

Important

    File Transfer Responses through a proxy server are not supported.

Mutual Authentication

This feature is new in MOM 2005 and requires the Management Server and the agent to authenticate each other before communicating. This uses the Kerberos v5 authentication protocol provided in Windows 2000, Windows XP and Windows Server 2003.

Mutual authentication can mitigate "man-in-the-middle" attacks where a malicious attacker could pose as a Management Server or an agent and communicate with, and perform action on, the other computer. To use mutual authentication, you must have an Active Directory trust relationship between the Management Server domain and the agent domain. Mutual authentication is a management group-wide setting and cannot be overridden.

Any agents that are configured to communicate with these Management Servers must be MOM 2005 agents or they will not be able to communicate with them if mutual authentication is enabled. Mutual authentication applies only to the MOM 2005 Management Servers and any agents reporting to MOM 2000 SP1 DCAMs will not be blocked by mutual authentication.

Secure Communications Channel

If mutual authentication is enabled, communications between a MOM 2005 agent and the Management Server are encrypted and digitally signed by default. To negotiate secure communications, the MOM 2005 agent uses the Kerberos Microsoft Windows Security Support Provider Interface (SSPI). The Kerberos security support provider determines which encryption algorithm is used for the session. The encryption algorithm depends on Group Policy settings, the operating system, the service pack, and other factors. Different sessions can use different algorithms.

If mutual authentication is disabled, no authentication is used. Communications between the MOM 2005 and the Management Server are encrypted by using the Schannel security support provider (SSP) with individual client certificates. Schannel uses Transport Layer Security (TLS) or Secure Sockets Layer (SSL). Depending on the SSP, the encryption might be RC4, DES, Triple DES, or another encryption algorithm.

Communications between the MOM 2000 SP1 agent and the Management Server is encrypted by default as it was in MOM 2000 -- that is, by using Diffie-Hellman key exchange. (If mutual authentication is enabled, MOM 2000 SP1 agents cannot communicate with the Management Server.)

Only mutual authentication requires an Active Directory trust.

Agent and Management Server Security Settings

When there is a difference between the agents security settings (except for communications port) and these settings on the Management Server, the Management Server will synchronize its settings down to the agents. To change the communications port use the "To update an agent outside a firewall" procedure in this guide.

Block Legacy Agents

You can configure the Management Servers in the management group to block communications from MOM 2000 SP1 agents. This setting is management group-wide and cannot be overridden. This setting is automatically enabled when you enable mutual authentication.

Reject New Manually Installed Agents

This setting tells the Management Server to reject communications from, and not detect, agents that are manually installed after this setting takes place. It does not affect agents that have already been manually installed and detected. After enabling this setting, manually installed agents will not appear in the MOM Administrator console and they cannot be changed to Agent-managed status, unless this setting is disabled. This setting is management group-wide and cannot be overridden. To disable this setting and detect agents the have already been manually installed, use the "To enable or disable the Reject new manually installed agents setting" procedure in this guide.

Note

    This setting is only effective if mutual authentication is enabled. Otherwise, MOM ignores this setting and new manually installed agents will be accepted.

Agentless-Management Security

New in MOM 2005is the ability to monitor computers without installing a MOM agent on them. This is called "agentless management." You can use agentless management for computers that are in special environments where an agent cannot be installed or where you do not need the rich management provided by a MOM agent.

The Management Server communicates to the agentless-managed computer over the RPC port (TCP 135) and the DCOM port range, and therefore using agentless management for computer outside a firewall is not supported. The Management Servers Action Account must also be a local administrator on the remote computer if you want to use agentless management, so they must either be in the same domain or a trust relationship must exist between their domains.

MOM Connector Framework and MMPC

The MOM Connector Framework (MCF) and MOM-to-MOM Product Connectors (MMPC) are new in MOM 2005 and provide the ability to share and synchronize data between MOM 2005 and MOM 2000 SP1 configurations, between MOM 2005 management groups, and between MOM 2005 and other management programs.

The MCF is a Web Service on the Management Server and communicates using TCP port 1271. Because of this, you can use MCF connectors through firewalls and over a LAN, WAN, or even the Internet.

MOM does not provide encryption for either the MMPC or the MCF connection; however, you can use Secure Sockets Layer (SSL) encryption for this purpose. For more information about configuring SSL encryption, see the Internet Information Services (IIS) documentation. You can also use IPSec for this purpose. For more information about using IPSec, see the "IP Security (IPSec)" section in this guide.

Important

If you are using the MCF over a "non-secure" connection, you should use SSL or IPSec to secure the data being sent because some of the data might be of a private nature, such as information passed in events or alerts.

Also, be aware that using SSL or IPSec, could degrade the performance of the MCF transmissions somewhat.

By default, MOM uses the DAS account for the MOM-to-MOM Product Connector (MMPC) - the MOMConn Service. The MMPC service account should be member of MOM Service security group on the source management group. If there is an Active Directory trust between source and destination management groups, the MMPC service account should also be member of MOM Service security group on the destination management group. If there is not an Active Directory trust, you must assign a client certificate for the MMPC service account and map it to an account that is member of MOM Service security group on the destination management group.

Using Client Certificates and SSL Encryption With MCF or MMPC

You can use SSL encryption and client certificates to further secure data being transmitted when using either the MCF or the MMPC. To use client certificates with the MMPC, follow the "To use client certificates and SSL with MCF or MMPC" procedure in this guide.

Configuring the Web Console As Read-Only

You can configure the Web console to be read-only, that is, that operations data can be seen but tasks cannot be run or changes made. This setting does not affect the Operator console read/write access. To configure the Web console for read-only access, follow the "To enable or disable Read-Only access for the Web console" procedure in this guide.