A while back I had a question about why/what specifically the NT AUTHORITY\SYSTEM (Local System) account would need to be a sysadmin in SQL Server 2008. It is after all configured this way by default setup, even when using domain user accounts to run the services. This blog post isn’t about whether or not SQL Server should have Local System as a sysadmin or not. For that discussion see my previous blog post on the topic.
One of the comments I received back from Dave Levy (Blog/Twitter) when all this was going on was:
@SQLSarg Watch out for SCOM. There is a doc out there somewhere that says best practice is to run as local system.
I have configured SCOM 2007 R2 for monitoring SQL Server twice now, and in neither case did I have to rely on Local System to monitor my servers. I am a firm believer in building least privilege security environments, to include the access provided to monitoring tools where possible. At the time I wasn’t able to lookup the reference, I was after all doing my real job and only popped in for some quick clarification of my initial thoughts about whether or not the Local System account was necessary to be a sysadmin inside of SQL Server. However, later on I jumped online and was reminded that I wanted to pull the reference for configuring SCOM to run with lower privileges than the Operating System for monitoring SQL Server.
The Low Privilege Environments section of the SQL Server Management Pack Guide contains all of the specifics that are necessary to setup a Run As Profile to monitor SQL Server using least privileges necessary. If you look real close, its not really that much, it is actually less than your SQL Service Account requires. I have used the Service Account as the monitoring Run As Profile account and it has worked perfectly, but it isn’t applying the principle of least privilege. A separate account should be created for monitoring that only has the necessary rights required, if least privilege is the goal.