MOM in a Nutshell
MOM is a management tool for consolidating information about your Windows servers and administering them from a centralized location. To use MOM 2005, you need at least one Windows Server 2003 machine on the network, but you can even run UNIX and Linux servers from MOM using a third party add-on such as MetiLinx Connect for MOM. You can monitor performance and track security, analyze network assets and automate many administrative tasks.
Note:
For more information about MetiLinx Connect, see http://www.metilinx.com/images/ConnectforMOM2005.pdf.
Although management software tends to be deployed by enterprise level businesses, Microsoft offers a Workgroup edition of MOM 2005 for small networks (10 or fewer servers). The Workgroup edition costs less and doesn’t require a SQL server (it can use the Microsoft Desktop Engine). However, it lacks the reporting component and doesn’t include the MOM Connector Framework (MCF), which allows for Web-based communications for sharing of data between multiple instances of MOM and other third party management systems. The Workgroup Edition requires Active Directory and runs only on Server 2003, whereas you can install the full MOM product on a Windows 2000 server.
MOM consists of several components. In a nutshell, here’s how they work together: You need at least one MOM server and a SQL server to store the MOM database (unless you’re using Workgroup Edition). The infrastructure is managed through the Administrator Console on the MOM server. The Operator Console is used to view specific information and perform specific tasks by members of the MOM users group. Managed computers typically have the MOM agent software installed (you can install the agent software remotely from the Administrator Console or manually at the local computer).
MOM 2005 also supports agentless management, so that if the agent software can’t be installed, you still have limited management capability. However, this can present a security issue since MOM communicates with the agentless computers through the RPC port. Best practice is to use agentless management only on systems within the local network segment. Microsoft doesn’t support use of agentless management on computers outside a firewall.
Note:
For more detailed information about each component of MOM and how MOM works, see the Microsoft Operations Manager 2005 Conceptual Guide, which you can download at http://www.microsoft.com/downloads/details.aspx?FamilyID=e06970bb-02f9-40da-b986-00d98d595696&DisplayLang=en.
MOM’s Built-in Security Mechanisms
MOM 2005 was built with security in mind. For instance, MOM can now run under the Network Service account on Windows Server 2003, or under the Local System account. Since the Network Service has a lower level of privileges, using this option increases the security of the service.
One security feature that’s new in this version is mutual authentication. This ensures that the MOM server and the agent will both authenticate with one another, using Kerberos v5 before they can send any data to each other. In order to use mutual authentication, you have to set up a trust relationship between the domain to which the MOM server belongs and the domain to which the agent belongs.
In addition to being authenticated, all of the data passed between the MOM server and agent is encrypted and signed by default. If you disable mutual authentication, you can still use encryption, and you don’t have to establish an AD trust to use encryption without mutual authentication. When you do have mutual authentication enabled, you can set MOM to not recognize or communicate with any agents that are installed manually after you enable the setting.
Note:
Enabling or disabling mutual authentication on the MOM server is as simple as checking a checkbox (in the Security Properties dialog box of the Administration | Global Settings node in the MOM console). However, you do need to restart the MOM service on all management servers in the management group after you change the setting, and you’ll need to change the settings on the agents through the Agent Setup component in Add/Remove Programs on the agent machines.
Other security features of MOM 2005 includes:
- You can control which groups of computers individual administrators can manage, using scopes of operation.
- Task auditing is enabled (and cannot be disabled) so that information about the tasks that are run on MOM and on the agents is recorded.
MOM Security Issues
As mentioned earlier, agent software can be deployed manually or it can be deployed automatically. The latter is called discovery-based deployment. You run the Install/Uninstall Agents wizard in the MOM Administrator console and find the computers on which you want to install agents (based on criteria that you specify) and do the installation. Be aware that the SMB and RPC ports are used for communications when the MOM server installs the agent software. If the agents are on the other side of a firewall, you’ll have to open those ports, which could create a security risk.
Note:
The File and Printer Sharing and Client for Microsoft Networks components use the SMB ports (TCP and UDP 445), and disabling those components disables the ports.
Best practice is to manually install agents outside the firewall, if possible. Once such agents are installed, TCP and UDP ports 1270 will need to be available for them to communicate with the MOM server.
Also note that you can’t use discovery-based agent deployment when the machine on which you want to install the agent software is in an IPSec domain and the MOM server isn’t. You can do discovery-based installation if the situation is reversed (MOM server in an IPSec domain and computer on which you want to install the agent isn’t) but it will require some extra configuration. To allow the client to communicate with the MOM server, the server will have to be configured with the Server policy rather than the Secure Server policy. This could open the server up to communications from other non-secure clients.
Best practice is to use IPSec or SMB packet signing to secure the files that MOM uses to deploy the agent software. These files are not secured by default. IPSec will provide mutual authentication, data encryption and a digital signature for the communications between the MOM server and agent. It is especially desirable to use IPSec if MOM is being used on a network without Active Directory or where the lack of trust relationships prevents mutual authentication.
SMB packet signing doesn’t provide data confidentiality but it signs the packets to provide data integrity, ensuring that the data isn’t modified in route. You can also use Secure Sockets Layer (SSL) to protect communications between MOM and the Reporting Console.
If agents are in workgroups or in non-trusted domains, you can’t use mutual authentication. If the MOM server is set to require mutual authentication, those agents can’t communicate with the server.
You might want to disable MOM 2005’s agent proxying feature as a best security practice. This feature lets agents forward information on behalf of other computers, but can be used as a spoofing mechanism by attackers to get malicious data to the MOM server. To disable agent proxying, mutual authentication needs to be enabled.
Note:
Some standard security measures may affect MOM’s functionality. For example, if you use the IIS Lockdown Wizard on the MOM server, ASP.NET will be disabled and this will make it impossible to use MOM’s Web console.
The Future of MOM
According to many sources, within the next year Microsoft plans to combine MOM with Systems Management Server in a bundled suite that will also contain a new solution, Systems Center Reporting Server. This is part of Microsoft’s Dynamic Systems Initiative. Look for Microsoft to make MOM more robust in the future, to compete with sophisticated third party management software packages. As with all software, as the product grows more complex, security is sure to become more important and more complicated.
