The OpsMgr Unleashed authors would like to thank Scott Weisler for this content and giving us the opportunity to post it.
|

|
C. Scott Weisler is a consultant specializing in Microsoft System Center, virtualization, and storage technologies. Scott is a multi-platform virtualization and storage architect, with over 7 years experience designing and implementing enterprise virtualization solutions. Scott is TS certified across the System Center suite, including Operations Manager 2007, Configuration Manager 2007, Virtual Machine Manager 2008, and Data Protection Manager 2007; as well as TS certified on Hyper-V Server Virtualization. Scott has served as a subject matter expert on System Center technologies.
|
Perhaps the most important improvement in cross-platform monitoring functionality in System Center 2012 Operations Manager is the removal of the requirement for root when discovering and monitoring Linux and UNIX systems. There has been some doubt cast on this claim in the community, suggesting root may actually be required for discovery. This posting discusses how to provide privileged access without root for discovery and agent deployment.
Microsoft Recommendations
When deploying cross-platform agents during discovery, you must use an account that has superuser privileges. If you follow recommended Operations Manager 2012 action account best practices, it means using an unprivileged account that can elevate to privileged using “sudo.” You no longer need “root” access to UNIX/Linux hosts for monitoring; in fact, “root” access is not recommended.
http://technet.microsoft.com/en-us/library/hh476947 states the requirements for the three UNIX/Linux action accounts. You can use a single local UNIX/Linux account for all three action accounts, if configured properly, as discussed at http://technet.microsoft.com/en-us/library/hh230690.
Preferred Methodology
A preferred methodology, test through trial and error, is to use two local UNIX/Linux accounts:
- opsuser: Unprivileged only. No elevation.
- Create a Monitoring Run As Account named UNIX/Linux Unprivileged Monitoring Account and assign opsuser to this Run As Account
- Assign the UNIX/Linux Unprivileged Monitoring Account to the UNIX/Linux Action Account Profile
- opspriv: Unprivileged with sudo elevation rights, as per http://technet.microsoft.com/en-us/library/hh230690.
- Create a Monitoring Run As Account named UNIX/Linux Privileged Monitoring Account and assign opspriv to this Run As Account
- Assign the UNIX/Linux Privileged Monitoring Account to the UNIX/Linux Privileged Account Profile
Next, create an Agent Maintenance Run As Account named UNIX/Linux Agent Maintenance Account and assign opspriv to this Run As Account
- Assign the UNIX/Linux Agent Maintenance Account to the UNIX/Linux Agent Maintenance Account Profile
- Generation of SSH keys for use with the UNIX/Linux Agent Maintenance Account Profile is optional, depending on the security requirements of your environment
The Key to Discovery Without Root
The key factor when deploying cross-platform agents during the discovery process is configuring the credentials:
- Whether using the SSH Key or User name and password option, use the opspriv account as the credentials to be used, and set the Does this account have privileged access? setting to This account does not have privileged access, as displayed in Figure 1.

Figure 1. Specify the opspriv account without privileged access
- Setting this option adds an extra Settings tab – Elevation. Select the Elevation tab and verify that the Use ‘sudo’ elevation option is selected. This is shown in Figure 2.

Figure 2. Verify ‘sudo’ elevation is selected
- Ensure the Discovery Type is set to All computers and discovery and installation should proceed successfully, as shown in Figure 3.

Figure 3. Discovery type set to All computers
Discovery Troubleshooting
Here are three common problems encountered with cross-platform discovery:
- Host name not matching DNS name – i.e. hostname command returning short name vs FQDN from DNS
Fix in the Networking configuration or the /etc/hosts file
- Reverse DNS not configured/not configured properly
Configure Reverse DNS records properly
- Reverse DNS results not matching host name – i.e. reverse DNS returning a generic name such as mailrelay.mydomain.com, rather than the actual hostname
Add an entry to the local c:\windows\system32\drivers\etc\hosts file for each OpsMgr management server in the resource pool that will be managing UNIX/Linux hosts for the IP address and proper DNS name of the UNIX/Linux server