SCCM 2012 and SQL Permissions

Question

I have been questioned on one my SCCM implementations, the DBA wants me to revoke sysadmin rights for the site server account (SCCM computer account) as well the the SCCM install account on the SQL server currently hosting our Configmgr database. 
1.  What are the repercussions (operations, site backups and reporting level) if I revoke these rights after implementation? 
2.  What permissions does the site server computer object require if we are to revoke sysadmin rights? 
3.  Also could I get away with revoking local admin rights on the SQL server for our SCCM Site Server account?

Answer 1

First, it's called tongue in cheek humor. DBAs take themselves entirely too seriously -- case in point :-)
Second, you are not granting "someone" sysadmin rights, you are granting sysadmin rights to a computer account which is very secure and cannot be interactively logged into. The install user account needing sysadmin rights is only temporary. Security is about
managing risk, not absolute rules. Absolute rules leave systems unuseable and typically imply that the person applying them doesn't even know why they are applying them -- they are just blindly doing it. Giving your neighbor a key to your door also violates
the security standard of not giving anyone the keys to your house but you trust your neighbor and have other security pre-cautions in place so it's an acceptable risk. Just like giving a computer account sysadmin rights -- does it violate a core principal,
perhaps, does it lower your security posture, no. Will it cause the DBAs some additional paper work, perhaps (maybe I've hit on the real reason your so perturbed?)
Next, ConfigMgr is not sending an e-mail or simply using the database -- it is also monitoring that database, re-indexing it, backing it up, and in general managing its configuration and health as well as the server hosting it. No one is asking for permissions
on every SQL Server, just the one that ConfigMgr uses so your analogy is far out of proportion.
As for DBAs screwing up every ConfigMgr install -- sorry but this is fact. As mentioned, it's happened on *every* ConfigMgr project I've ever been on and everyone I know that implements ConfigMgr says the same thing. And why does this happen? Because the
DBAs blindly follow their own guidance instead of what we've asked of them.
As for ITIL, sorry, most people "say" they practice ITIL but ITIL is in fact unpracticable in the real world -- just like Robert's Rules of order it means everyone is more concern about how to fill out the proper paperwork instead of actually getting anything
done -- it's a theoretical set of concepts that are great in theory and have a lot of practical application. Split responsibilities are also good in theory, but always cause issues when there isn't communication and the right hand decides to apply its own
standards in a vacuum of reality and ignores the requests made of it by the left hand.
As for security, you are sadly misinformed and read too many industry rags with talking heads that spew garbage so that the uninformed can feel empowered. In the last handful of years, Microsoft and its products have been oft lauded and recognized as industry
leaders in security by all reputable security sources.
As for ConfigMgr (SCCM is the Society for Critical Care Medicine so if you wish to insult them, I suggest you go to their website) being "crappy", well that just sounds like Microsoft bashing and serves no real purpose.
If you wish Microsoft to change ConfigMgr's sysadmin requirements, I suggest you file a DCR on Connect. Be prepared to justify your suggestion with real-world business impact and real technical reasons and not just "I'm a DBA and I say so" and "ConfigMgr
is crappy".
Jason | http://blog.configmgrftw.com