~ Brian McDermott
When you are setting up your Run As Accounts for Linux monitoring in OpsMgr 2012 and linking them to your Linux Run As Profiles, you need to ensure that you are differentiating between the two different kinds of Linux accounts.
You have to use a Monitoring account in the monitoring Run As Profiles and the Agent maintenance account for the Agent maintenance Run As Profile.
The reason for this is that the mechanisms we use for our monitoring and our maintenance tasks are different and so support different methods of elevation.
An Agent maintenance account, used to do push installs/updates/etc., is typically carrying out tasks that require super user privileges. So if the account you are specifying for this is not a super user (i.e. root), then you will be asked which method of escalation you would like to use, su or sudo. You get the option to use su for these accounts since our SSH module supports the use of two separate passwords, and we are using SSH to carry out these tasks.
This account type should only be associated with the UNIX/Linux Agent Maintenance Account Run As Profile.
The Monitoring account, however only supports the use of sudo for elevation as we are using the WS-Man protocol for our monitoring rules, and WS-Man does not allow for the use of multiple passwords therefore ruling out su as a possibility.
This account type is to be used with either the Unix/Linux Action Account Run As Profile, an account which typically does not require any elevation as it carries out low level monitoring duties, or the UNIX/Linux Privileged Account Run As Profile.
As its name would suggest, the UNIX/Linux Privileged Account Run As Profile does require some levels of access not typically granted to a standard UNIX/Linux user account. The rules it will run out of the box are those that monitor the /var/log/secure log files.
SU Command Failure alert rule
Root Password SSH Authentication alert rule
SU Command Success alert rule
SSH Authentication Failure alert rule
So you will typically have to set up an account that is configured to use sudo to get these rules to complete successfully.
So what happens if I set it up incorrectly and attempt to use a UNIX/Linux maintenance account in a monitoring profile?
Well that brings me to my inspiration to write this article. We had a customer recently open a case because they were seeing the memory usage on two of their Management Servers growing rapidly until it exhausted all memory on the server. The server would then restart and the process would begin all over again.
Investigating this behavior, we saw that the memory leak was increasing in a monitoringhost process that had the SCXLogModules.dll loaded, and that it was hitting an error when it found that an account configured to run the monitoring rules was requesting to use su for elevation.
This then led our code down a bad code path which leaked memory and used considerable CPU.
So please, do not do this, and if you do see a memory leak in monitoringhost.exe on a Management Server that is doing UNIX/Linux monitoring, be sure to check that your accounts are correctly configured.
Brian McDermott | Escalation Engineer | Microsoft GBS Management and Security Division
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/