SCCM 2012 and SQL Permissions

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?

October 10th, 2012 7:37pm

The install account itself doesn't need permissions after installation although if you install service packs or cumulative updates, you will probably need those permissions back.

The site server account requires sysadmin in the SQL instance and local admin in the Windows OS hosting the SQL instance. Nothing less. That is the only thing that is supported. So, no you cannot get away with anything else. Basically, tell your DBA to "suck eggs" and deal with it. :-) Sorry, you can ignore that attempt at humor if you wish, but the end result is the same.

In general, tell your DBA to not touch *anything*. I kid you not when I say every single time I've been involved with an organization that had a DBA responsible for the ConfigMgr DB (and every single person I know that implements ConfigMgr echoes this) the DBA invariably screwed something up because they refuse to listen.

Free Windows Admin Tool Kit Click here and download it now
October 10th, 2012 9:01pm

Thanks for the validation Jason. Is there any official literature in response to your original statement about this being the only supported configuration?
October 10th, 2012 10:41pm

Here's a link that may have information your looking for: http://technet.microsoft.com/en-us/library/bb680604.aspx

Do not modify the SQL Server roles and permissions created by Configuration Manager 2007

Free Windows Admin Tool Kit Click here and download it now
October 11th, 2012 1:09am

Therefore I have to say something here! I'm a DBA and I really hate to grant anyone sysadmin rights, not even Microsoft products. On the one hand, Microsoft is telling something and training something about SQL servers and on the other hand they are not able to follow even their own rules. Then there is probably only one answer to that. Programmers of SCCM, SCOM and other products are pigs. They have been probably developing these applications on servers where they were sysadmins not respecting any restriction and causing long nights and headaches to dbas . Those SCCM admins should probably visit one of Microsoft SQL server trainings first themselves and listen carefully. Because they will surely hear Microsoft certified lectors telling something like this : "do not grant sysadmin rights to anyone, if you don't want to get fired" ... Now I can see why is Microsoft having so vulnerable products. And if someone with MCC, MVP is answering like "suck eggs" then it is even worse. I guess you should really rething what you said here and apology all dbas. Or Microsoft should rethink their strategy and give dbas tools which allow them to handle such crappy aps like SCCM, or they should really follow their own rules for SCCM & DB security with less privileged accounts. Why? Because I do not really need to be "Domain Administrator" to be able to send an email, do I? And if you need to upgrade or patch your databases you should anyway contact your dba team. That's called split of responsibilities and that's why most companies are using ITiL!!!! Probably Microsoft is not.
February 1st, 2013 4:18pm

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".

Free Windows Admin Tool Kit Click here and download it now
February 1st, 2013 9:04pm

I'm really pleased to show your answer to my management. Many thanks, this will help them to understand SCCM as autonomous application which is doing everything without any intervention from DBAs. You can't imagine how much you helped ... Not even to me, thx.
February 2nd, 2013 12:02am

I'm a little late to this conversation.  But, this is something that I, too, face quite frequently.  DBAs have a hard time with the permissions that ConfigMgr requires.  Some are more forgiving than others.  I always try to get my clients to install SQL locally on the ConfigMgr server (if it has the resources).  Sometimes, management of the DB is then given to the ConfigMgr Admins.  IMO, that's the way it should be unless the DBAs are trained on ConfigMgr.  I have had DBAs screw something up quite a few times.   

At my previous company, the DBA took away sysadmin privs and he also limited the DB growth to a very unreasonable limit.  He did this without telling anyone.  Why?  Simply because he didn't understand what the DB was being used for.  So, why let the DB grow?  We were in the middle of a Windows 7 deployment!  So, of course the DB needs room to grow!   

Free Windows Admin Tool Kit Click here and download it now
July 12th, 2013 8:38pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:29 PM
  • Unproposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
January 27th, 2014 6:29pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:29 PM
  • Unproposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
Free Windows Admin Tool Kit Click here and download it now
January 27th, 2014 6:29pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:29 PM
  • Unproposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
January 27th, 2014 6:29pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx

Found the specifics regarding the computer account at the same link but under "To create a Secondary site".
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
Free Windows Admin Tool Kit Click here and download it now
January 27th, 2014 6:40pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx

Found the specifics regarding the computer account at the same link but under "To create a Secondary site".
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
January 27th, 2014 6:40pm

Here is the "Official" documentation regarding the required Sysadmin access. You'll find the reference under "Install a Central Administration Site". It took me a while to find this too.

http://technet.microsoft.com/en-us/library/gg712320.aspx

Found the specifics regarding the computer account at the same link but under "To create a Secondary site".
  • Proposed as answer by Jeff Pollock Monday, January 27, 2014 6:48 PM
Free Windows Admin Tool Kit Click here and download it now
January 27th, 2014 6:40pm

Hi, Jason, I guess you are too young to remember Enron collapse. The reason that over-privileges is not to be given is to make sure checks and balances. Unfortunately people don't learn from history. If Microsoft puts in a little work, they would be able to spell out the permission required for their apps. Unfortunately they don't, instead just uses a blanket approach. It sounds like you are young and inmature enough to use emotion only in the public discussion.
August 18th, 2014 8:44pm

This comment shows you do not really understand database. It is not just datbase growth that can be set. It is also the available space. If you don't provide a good estimate of space requirement for the next few X time. You are bound to run out of space (for rapid growth). It does not matter database limit is set. It will run out of space somewhere (sooner or later). So please look at the mirror and ask yourself first how much space does my SCCM really need? and work with your DBAs.
Free Windows Admin Tool Kit Click here and download it now
August 18th, 2014 8:53pm

hehehe, I found it rather funny, is there a Microsoft app that does not require sysadmin as in their documentation? I guess it is written by the same person.
August 18th, 2014 8:54pm

Does Microsoft documentation writers really know which privileges under sysadmin is not being used by SCCM? I guess not and I cannot motivate them.
Free Windows Admin Tool Kit Click here and download it now
August 18th, 2014 8:56pm

Hi, Jason, I am sorry you did not have a good DBA to help you out in your organization. Maybe the issue with your scenario/environment is that your company needs to find a good DBA. It is like one medical doctor screwed you up, you think all doctors are bad.
August 18th, 2014 9:04pm

https://technet.microsoft.com/en-us/library/gg712320.aspx#BKMK_InstallPrimarySite

Sysadmin rights on the instance of SQL Server that hosts the site database. After setup completes, both the user account that runs setup and the site server computer account must retain sysadmin rights to SQL Server. It is not supported to remove the sysadmin rights from these accounts.

It doesnt say anything about local admin (OS) for computername$ only sysadmin role membership in the SQL Server hosting the site DB. It says the user installing it must be a local admin (OS) on the SQL Server.

I could be wrong the documentation is deep but I did read it.

  • Proposed as answer by DiddelyDogg 11 hours 52 minutes ago
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2015 11:28am

https://technet.microsoft.com/en-us/library/gg712320.aspx#BKMK_InstallPrimarySite

Sysadmin rights on the instance of SQL Server that hosts the site database. After setup completes, both the user account that runs setup and the site server computer account must retain sysadmin rights to SQL Server. It is not supported to remove the sysadmin rights from these accounts.

It doesnt say anything about local admin (OS) for computername$ only sysadmin role membership in the SQL Server hosting the site DB. It says the user installing it must be a local admin (OS) on the SQL Server.

I could be wrong the documentation is deep but I did read it.

  • Proposed as answer by DiddelyDogg Wednesday, May 13, 2015 7:55 PM
May 13th, 2015 3:25pm

https://technet.microsoft.com/en-us/library/gg712320.aspx#BKMK_InstallPrimarySite

Sysadmin rights on the instance of SQL Server that hosts the site database. After setup completes, both the user account that runs setup and the site server computer account must retain sysadmin rights to SQL Server. It is not supported to remove the sysadmin rights from these accounts.

It doesnt say anything about local admin (OS) for computername$ only sysadmin role membership in the SQL Server hosting the site DB. It says the user installing it must be a local admin (OS) on the SQL Server.

I could be wrong the documentation is deep but I did read it.

  • Proposed as answer by DiddelyDogg Wednesday, May 13, 2015 7:55 PM
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2015 3:25pm

https://technet.microsoft.com/en-us/library/gg712320.aspx#BKMK_InstallPrimarySite

Sysadmin rights on the instance of SQL Server that hosts the site database. After setup completes, both the user account that runs setup and the site server computer account must retain sysadmin rights to SQL Server. It is not supported to remove the sysadmin rights from these accounts.

It doesnt say anything about local admin (OS) for computername$ only sysadmin role membership in the SQL Server hosting the site DB. It says the user installing it must be a local admin (OS) on the SQL Server.

I could be wrong the documentation is deep but I did read it.

  • Proposed as answer by DiddelyDogg Wednesday, May 13, 2015 7:55 PM
May 13th, 2015 3:25pm

That section lists requirements for the account used to install the site -- it also happens to mention the sysadmins rights required by the computer account but that's simply an added point and not an all-encompassing statement about the rights needed by the computer account. The computer account requires local admin on *all* site systems hosting roles in the site including the DB.
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2015 4:08pm

..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.

Jason,

  I'm trying to make sure I understand this part correctly.  FWIW, I'm a sysadmin not at a dba but I am getting push-back from one.

On the first point, if the computer account has sysadmin access to SQL then isn't it just a stepping stone to any data on that SQL cluster?  So yes, that account isn't interactive but anyone with access to the machine now has access to everything on the SQL cluster.

On the second point I'm just confused.  You say it's temporary for the installing user account but the documentation linked elsewhere in this thread seems to says that it's permanent.  Am I misunderstanding something here?

August 14th, 2015 10:16am

..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.

Jason,

  I'm trying to make sure I understand this part correctly.  FWIW, I'm a sysadmin not at a dba but I am getting push-back from one.

On the first point, if the computer account has sysadmin access to SQL then isn't it just a stepping stone to any data on that SQL cluster?  So yes, that account isn't interactive but anyone with access to the machine now has access to everything on the SQL cluster.

On the second point I'm just confused.  You say it's temporary for the installing user account but the documentation linked elsewhere in this thread seems to says that it's permanent.  Am I misunderstanding something here?

Free Windows Admin Tool Kit Click here and download it now
August 14th, 2015 10:16am

On the first point, if the computer account has sysadmin access to SQL then isn't it just a stepping stone to any data on that SQL cluster?  So yes, that account isn't interactive but anyone with access to the machine now has access to everything on the SQL cluster.

Yes, it is a stepping stone away for the computer account itself and not for any user on the system. Just like any other account, you must log in as or impersonate that account to use its privileges. To do this for the local System account and thus the system's computer account, you must be a local admin which means you are already trusted on the system. Ultimately though, this is just another reason why you shouldn't use a clustered SQL instance for ConfigMgr or a remote SQL server at all.

On the second point I'm just confused.  You say it's temporary for the installing user account but the documentation linked elsewhere in this thread seems to says that it's permanent.  Am I misunderstanding something here?

It's permanent for the computer account, not for the installation account. I generally recommend using a dedicated account for installation though and then disable it at the end of installation because the same permissions will be needed when installing service packs and cumulative updates (as well as some hotfixes). 
August 14th, 2015 12:00pm

On the first point, if the computer account has sysadmin access to SQL then isn't it just a stepping stone to any data on that SQL cluster?  So yes, that account isn't interactive but anyone with access to the machine now has access to everything on the SQL cluster.

Yes, it is a stepping stone away for the computer account itself and not for any user on the system. Just like any other account, you must log in as or impersonate that account to use its privileges. To do this for the local System account and thus the system's computer account, you must be a local admin which means you are already trusted on the system. Ultimately though, this is just another reason why you shouldn't use a clustered SQL instance for ConfigMgr or a remote SQL server at all.

On the second point I'm just confused.  You say it's temporary for the installing user account but the documentation linked elsewhere in this thread seems to says that it's permanent.  Am I misunderstanding something here?

It's permanent for the computer account, not for the installation account. I generally recommend using a dedicated account for installation though and then disable it at the end of installation because the same permissions will be needed when installing service packs and cumulative updates (as well as some hotfixes). 
Free Windows Admin Tool Kit Click here and download it now
August 14th, 2015 12:00pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics