Remote SQL Security Concern
I have had a few discussions over the years about whether a Configuration Manager installation should include SQL “on box” or “remote”. The answer is generally “it depends”. This blog post is not going to dig into all of the reasons why you would choose either local or remote SQL…it is designed to highlight one particular security concern with the remote SQL option. Let’s think through several of the underlying components that are necessary for remote SQL to take place along with a few very common scenarios when this is the case.
- Generally a company will choose remote SQL because they want to have a beefy SQL box that is managed by their DBA team. This SQL box will commonly house several SQL databases…not just the Configuration Manager DB. Which means that any disruption on that SQL server has an impact on much more than just Configuration Manager.
- A requirement for remote SQL with Configuration Manager is that the Configuration Manager server’s computer account must be in the local admin group on the SQL server.
- Commonly there will be a number of Configuration Manager administrators that have admin rights on the Configuration Manager server.
- Commonly there will be a number of those same Configuration Manager administrators that do NOT have admin rights on the remote SQL server.
THAT is where the problem rears it’s head. Let’s connect all of the dots…
- Joe Admin is an admin on the Configuration Manager server…but is not an admin on the SQL server.
- The Configuration Manager server’s computer account is an admin on the SQL server.
- Joe Admin has read my article on how to run a command prompt as local system. Uh oh.
- Joe Admin uses psexec to run a command prompt (or SQL Management Studio…or regedit…or services.msc…or disk management…or whatever else) as local system on the Configuration Manager server.
- Joe Admin then connects that app (running in the “user” context of the Configuration Manager server’s computer account) to the SQL server.
- Joe Admin is now able to do anything that the Configuration Manager server’s computer account has rights to do…which is full Administrator rights…ON THE SQL SERVER!!!
- That security you thought you had…well it didn’t work so well.
Is there anything to keep Joe Admin from (either accidentally or maliciously):
- Stopping services?
- Deleting files?
- Rebooting the server?
- Jacking with the registry?
- Installing (either good or bad) software?
- Copying data off of the SQL server?
- etc (I think you get the picture.)
Now…for some people that doesn’t matter. In many smaller installations the same team is managing Configuration Manager and SQL. However…if you are that small…why take on the extra complexity of the remote SQL scenario?
For others it matters big time! I’ve had conversations with customers who cringe at the very idea that some random Configuration Manager admin could possibly gain full rights to the SQL server that other business critical databases are stored on.
SQL 2008 Install Issue
This weekend I was setting up a new demo environment on my laptop. This is a VM that I use to demonstrate ConfigMgr and OpsMgr to clients. I also use it for troubleshooting issues. The VM is running Active Directory, DNS, DHCP, WDS, SQL 2008, ConfigMgr SP2 R2, MDT 2010, SCOM R2, along with various other components.
So I’m building a new demo environment because I wanted to be using Windows Server 2008 R2 and SCOM R2. When I went to install SQL 2008, I got an error message:
Invoke or BeginInvoke cannot be called on a control until the window handle
has been created.
I did a quick Bing search on the error and found that I’m not the only one who has hit that error. At first, the most promising link appeared to be a KB article addressing that very issue. I also took a look at another link to blogs.msdn.com. That one describes the issue and states that if you restart the install it will probably work. In my case it didn’t work. In the comments section of that post, the very last comment was from someone who states that they simply created a c:\temp folder and it solved the issue.
I was skeptical, but it worked. SQL 2008 went through completely fine after creating that folder.
-
Recent Visitors
Subscribe
-
Recent Comments
-
