All in the name of "security"…

Send to Kindle

Here is a recent little story about when, in the name of "security", a really dumb thing was done, and the response that said a lot about the security posture of those behind the response.

A client of mine has 4 servers (2 for an Active Directory domain, and two for SharePoint/SQL server) hosted with an external provider. I was commissioned to perform a fairly standard install of MOSS 2007 enterprise.

My former life in security still influences me to this day, and thus I always build SharePoint in a fairly locked down fashion. So, apart from some strict naming conventions among components, I used a bunch of user accounts to run the various SharePoint services. I made sure that none of which have any privileges over and above what they absolutely require for SharePoint to work.

The install was fairly flawless and was over in a couple of hours, however my client called me half a day later to let me know that search was broken.

Upon further investigation, I determined that the search account had lost its "log-on as a service" right. In fact, all of my service accounts had lost the right to log on as a service, so the next reboot would have rendered SharePoint completely hosed.

I knew the root cause straight away. The only explanation for user accounts "spontaneously" losing their rights to perform certain tasks is that Active Directory policies have overridden the local machine settings. Policies refresh on a machine by default every two hours, which explains why it was all working sweet when I left it.

So I checked the local security policy, as well as the output of the applied Active Directory policies using GPRESULT. Sure enough, a domain level policy had overridden the "Log in as a Service" right so that only the AD Group called "Service Accounts" had the right to log in as a service. I was a bit annoyed that the "Default Domain Policy" had been edited, rather than a separate policy, but that was just a personal preference thing and more my own AD dogma than anything else.

"Okay", I say. "I can understand that. I can see the sense to restrict what accounts can run services".

But then next fact made me seriously consider the thought process behind this decision. The "Service Accounts" group was a member of the Domain Administrators group!

What the…

Yes, you heard right. This hosting provider effectively *forced* all service accounts to run with domain administrator credentials.

In case you are asking yourself "So what?", then let me state right now that no SharePoint service requires domain administrative privileges. In fact, none of them need local administrator privileges either. (Although Microsoft’s own documentation – at the time of writing this post – suggests the search account does when it really does not).

So, let’s consider the implications of this ill-conceived AD setting.

  • If I granted my SharePoint service accounts the right to log-on as a service again, the AD policy would once again remove that right within a few hours. Back to a hosed install that won’t start.
  • If I added the SharePoint service accounts to the "Service Accounts" group, they suddenly are granted full domain-wide administrative rights!

So naturally, I asked for this policy to be removed from the Active Directory, because it was simply a bad idea.

The response I got back staggered me. I was told that if I do not make a service account an administrator account, "then you must assign all of the rights it might need individually". Well… yeah! I mean I installed SharePoint using an administrative account and it sets up those rights during the install. So what’s the issue there?

The absolute clincher, though, was this quote.

"After all is said and done, the accounts end up with near-backdoor admin level access anyway."

So, it seems that this hosting provider was advocating running everything with domain administrator privilege because all service accounts require so much privilege on a box anyhow! Even if a service did need administrative access on the box, it invariably does *not* require it on the entire domain!

That sort of logic is like telling your wife "Sweety! Great news! I’m going to a strip club tonight so that you can spend some quality time with the kids".

It might sound plausible to you, but everybody else knows that it’s going to come back and bite you in the butt!

Anybody else have similar stories?

Paul

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle
Bookmark the permalink.

4 Responses to All in the name of "security"…

  1. Pingback: SharePoint Daily for August 25, 2008 - SharePoint Daily

  2. Jeremy Thake says:

    I’m glad I’m not the only one in Perth dealing with Group Policy changes in Active Directory causing havoc in a SharePoint Farm! I feel happier now!

  3. admin says:

    Yeah another client nailed me 2 days later – same sort of thing…

  4. Pingback: Recent Links Tagged With "activedirectory" - JabberTags

Leave a Reply

Your email address will not be published. Required fields are marked *