Configuring MOM SecurityThe 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. 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:
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.
Deploying Agents and the Agent Action AccountYou 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 DeploymentDiscovery 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:
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.
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:
Manual-Based "push" Agent DeploymentIn 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 AAAThe 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:
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:
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 SecurityThere 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 ToolThe 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 IPSecIPSec 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:
Using SSLSSL 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 EncryptionOLEDB 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 SigningSMB 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:
MOM Security Best PracticesNow that you have a good foundation in MOM security, the following are Microsoft's "Reducing Risks in MOM 2005" recommendations:
|