The Realm of the Verbal Processor

Jarvis's Ramblings

New Blog on Hackers and End of Life Products

I just posted a new blog to the CDW Solutions Blog titled “Why Hackers Love End of Life”. I have to say that it was fun to start a technology post with the phrase “The smell of potato chips and a few too many energy drinks wafts through the air.”

You can see all of my CDW blog posts here: http://blog.cdw.com/author/jarvis/

January 22, 2015 Posted by | Security | , | Leave a comment

Trust Google? No Thanks.

Here’s another example of why I simply don’t trust Google. The issue is that it is trivial to view the passwords saved in Chrome or Firefox…just open up chrome://settings/passwords and click the “Show” button. ZDNet has a good writeup here. Chrome doesn’t even have an option for protecting those saved passwords behind a master password…Firefox does, but it isn’t enabled by default. (Personally I use Internet Explorer which does require you to enter the logged on user’s password to view the saved passwords.) While this issue has existed in Chrome (and Firefox) for a while, it has recently gotten some public exposure.

What is really comical and sad is the excuse given by the “Chrome browser security tech lead” who stated that the only security that matters is the OS password…that a master password protecting the saved password cache is a “false sense of security”. While I agree that the OS password is the most important security step…it should not be the ONLY step. It seems that the only security breach they are concerned about is the malicious attacker…and seem to care less about giving away the farm to opportunistic or mischievous family/friends/co-workers. Just because I either intentionally or accidentally left my computer logged in and not locked should not give someone unfettered access to all my saved passwords…someone who just happens to be in my house or near my computer. The rest of the comments on that thread are also pretty entertaining. Dude got ripped pretty hard for his original post…then responded with what came across as an arrogant “we know better than you” response that certainly didn’t gain him any friends or allay any of the concerns people addressed in the thread. He just doesn’t appear to “get it” that this is a real problem for regular users.

August 8, 2013 Posted by | Security | 1 Comment

Shared SQL with Configuration Manager?

Over time I have talked with numerous people about where the SQL database should be for the Configuration Manager database. Where this conversation typically comes up is when a company has a DBA team that is demanding that all SQL databases be hosted on dedicated (and super powerful) database servers. These servers predominantly will host numerous SQL databases for a variety of applications. The reasoning typically falls into the following arguments:

  1. Licensing – We don’t want to have to pay for another SQL license, so all DBs will be on our dedicated SQL servers.
  2. Performance – Our crazy powerful DB servers will give better performance than what you would install locally.
  3. Security – We need to maintain control over the content of the DB, and the DB integrity in general. Having them on a dedicated SQL server allows us to do that in the best way.

Sounds like some good arguments right? Well…not so much. Let’s take a look at each of the three.

  1. Licensing – Not an issue at all. Configuration Manager 2012 licensing includes the ability to install SQL Standard…at no additional charge.
  2. Performance – There have been arguments for years about whether Configuration Manager performed better with remote or on-box SQL. I’ve seen people give great arguments both ways…but haven’t really seen anything definitive either direction. With Configuration Manager 2012, the recommendation from Microsoft is that SQL be local unless you hit certain size limitations. Unless you are over 50,000 clients, then on-box SQL Standard will work just fine for you. If more than 50,000 clients, then a remote SQL Standard will take you to 100,000 clients. SQL Enterprise is only necessary on a Central Administration Site supporting more than 50,000 clients. (For more info.)
  3. Security – THIS IS THE BIG ONE! It generally takes about a three minute conversation with a DBA before they run away from this argument. Consider the following facts and implications in a remote SQL scenario:
    1. The Configuration Manager site server must be a member of the local administrators group on the remote SQL server. (See the Configuration Manager documentation.)
    2. Several people who are not SQL admins will be administrators on the Configuration Manager site server.
    3. It is trivial for an admin on the Configuration manager site server to run any application (such as a CMD prompt or SQL Server Management Studio) as Local System. (See this post.)
    4. Since the Configuration Manager server (Local System) has admin rights on the remote SQL server…the non SQL Admin can VERY easily obtain admin rights on the SQL server.
    5. The DBA has now started sweating, twitching and begging you to keep your weird database away from his/her server. :-)

So, really the only reason to consider doing remote SQL at all is a performance issue…but you have to be a pretty big organization for that one to come into play. And even if you do need to do remote SQL…it should be a SQL server that is dedicated to Configuration Manager.

Note (12/4/2012): I was talking with a friend late in the day yesterday about this blog post. He reminded me that I had already posted about this issue last April. Thanks Phil…I’m a little scatterbrained sometimes! I’m leaving this post up anyway because it is better than the original in my opinion.

December 3, 2012 Posted by | ConfigMgr, ConfigMgr 2012, Security, SQL | Leave a comment

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.

  1. 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.
  2. 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.
  3. Commonly there will be a number of Configuration Manager administrators that have admin rights on the Configuration Manager server.
  4. 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…

  1. Joe Admin is an admin on the Configuration Manager server…but is not an admin on the SQL server.
  2. The Configuration Manager server’s computer account is an admin on the SQL server.
  3. Joe Admin has read my article on how to run a command prompt as local system. Uh oh.
  4. 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.
  5. Joe Admin then connects that app (running in the “user” context of the Configuration Manager server’s computer account) to the SQL server.
  6. 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!!!
  7. 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.

April 27, 2012 Posted by | ConfigMgr, ConfigMgr 2012, Security, SQL | 4 Comments

   

%d bloggers like this: