In case anyone has noticed, it has been over a month since my last post.  I didn’t do this on purpose, but have been on the road pretty extensively lately.  As it turns out, I have witnessed some very cool things (MOSS 2007 is really growing on me) and some not so cool things.  As I see the latter, I try to temper my gut reaction with the understanding of what it can be like to be an administrator in a world where corporate logic and funding are not always moving in positive directions.  My mama (probably like most everyone else’s) told me once not to jump to conclusions about a person until I have walked awhile in their shoes.  Well mom (I don’t think she reads my blog), I have been there and walked that walk, so now I am gonna talk that talk.

A couple of weeks ago I visited a customer site and spoke with an admin who was probably a bit overwhelmed to be doing the job that she should have been better trained for.  A little downsizing had placed a SPS 2003 server farm in her hands with very little documentation.  So the powers that be in her organization called us in and we took a drive out to see them.  Once onsite we found that while there were several issues.  One of the issues was the separation of job responsibilities between departments who don’t communicate.  I will save this particular issue for my next post.

The main issue I wanted to talk about is security.  Once we started diving into the issues at hand, we determined that we needed administration rights to run some of the tools that would provide us with a prognosis of the health of the farm.  We found several things upon asking for this level of access. 

First, everything was running under a single service account.  While this is not always a bad thing, someone (preferably the server admin) should at least know the password to the account.  Within SharePoint, this account is what has access to the database, runs the application pools, manages the content, runs search and indexing and performs all of the scheduled jobs within the farm (if you are only using one account).  Our administrator’s personal account did not have the permissions we needed either.  Even though she was a server admin, she didn’t have the appropriate permissions the tools needed to access the database.

Second, their only Active Directory administrator was out of the office for another week.  I am sure that I shouldn’t have to lecture anyone on the need for redundancy.  There should never be just one domain admin who can create AD accounts.  Risk mitigation (aka Disaster Recovery) always tells us to have a backup.

Third, we were unable to get a hold of the DBA(s) in order to get the necessary permissions.  They seemed to be unavailable or uncommunicative.  This is one of the communications issues I alluded to earlier.

To make a long story shorter, we were able to get around the whole security issue by adding our commands to a scheduled script file they were using to perform backups of their sites.  It took us exploiting their security to make our tools work.  This should not happen this way.  I strongly encourage anyone reading this blog to take a good look at how you manage the knowledge/storage of service account passwords.  At my last job, we had them printed and placed in a sealed envelope in a safe that only a select few had access to.  If someone left the company who had access, we went through the process of changing the password and updating the stored version. 

If you don’t already know what all it would take to update WSS/SPS with a new service account password, please take a look at the link below.  Together we can not only ensure our SharePoint environments stay secure, but also that we can get to the data we need when we need it.  Cheers.

http://support.microsoft.com/kb/837813/en-us