I am concerns from my Linux team over the permissions needed for SCOM on Linux to be able to install the agent. How have others addressed these concerns?
Our Linux team have the same issues so they install the agent.
They send me a .pem certificate, which I certify in SCOM, using scxcertconfig.exe and send them back the generated cert.
Once they have installed the certificate, I search for the new machine in SCOM and manage it.
They also have to make sure that the iptables and frewall have ports 22 and 1270 open.
The linux team has an ansible playbook which installs the agent/ sets the sudo rules and iptables configuration. Afterwards we sign it using the Operations Console or using powershell.
Here’s a handy link for the sudoers file:
I talked to my Linux team and anything that requires elevated rights that are outside their control is not desirable. They would like me to see if we can set up a Ansble playbook that can do the install and sign the cert completely end to end staying with in their control and for scom to have very limited rights to Linux. Just enough to access the agent and run monitoring.
Just to update people on this since there is not much out there on this. We did get the agent installing manually by my Linux team they are working on automating the install using their tools. Once they report they installed we then go back and sign and manage the machine from the SCOM console. This allowed them to remove the install SUDO permissions. The certificate is good for 10 years so after signing they were able to remove those rights as well. This made them much happier that we had very restricted rights to their boxes.
We were using the 1807 agent and there were a few things that came up that we found no documentation for. The 1807 agent adds some local accounts to your linux machines and gives them root access with no password
These accounts are used only if you are using OMS and can safely be disabled if you are not but I would test it in your own environment. The 2019 agent does not add these accounts and we were able to use it with 1807 SCOM with no issues and it was recommended by support for RHEL 7.
Finding someone at MS support that knows basics of SCOM and Linux at MS is not hard but finding someone that knows both really well may take a little while to get some time with but it was not hard if you have time to wait. It took several hours to get to the right person and they had to ask product team a few questions for us so that also caused a delay but it was still not bad.
that sounds like what we want to do. We are looking at quite a few machines so signing the certs manually seemed a bit too much to handle practically. So can we still use the console to just sign the agent then when the agent is already installed that would be practical to do in my opinion. An ansible play book would be the ideal way to handle it.