Most common issue with SharePoint installations – service account misuse

It is frightening to see how many SharePoint installations have been installed with wrong service accounts. Either people are using the default domain administrator or local machine administrator for all service accounts, or they are creating a single service account for everything and in many cases giving it WAY too many rights. SharePoint 2007 has been out for a fair amount of time and people are still getting this massively wrong. We can dissect later why that is, but for now I wanted to give my quick overview on what I suggest for service accounts in SharePoint 2007.

Few golden rules:

1. Never use domain administrator or built-in machine administrator for any SharePoint service account, and never be logged onto a server with as either of these accounts when installing SharePoint.
2. Never use the same service account for all SharePoint services
3. Never manually grant SQL Server rights to any service account (except the one you use to install SharePoint – farm service account, will come back to this later). SharePoint will give all SQL Server rights to the appropriate service accounts
4. Read the installation documentation. This is not a simple installation and configuration, so don’t treat it as such. Do you home-work before installing and configuring a SharePoint farm. Seriously, this is not a file server!

Depending which resources you read, will see suggestions anywhere from 3 to 7 service accounts required for SharePoint Server 2007. In my suggestion below, I recommend 5 service accounts. There are many arguments to be had around details, but I don't believe you will be going wrong with this.

 

Account	Purpose	Scope	Used By	When do you input this account name?	Rights Required
Farm Account / Central Admin App Pool Account	Used to run setup on each MOSS server in the farm. You must be physically logged on as this user when installing MOSS. This user account must not be the domain or local default “administrator” account, create a new account which you might call “MOSSFarmSVCAccount” and use this across all servers to install MOSS. During installation it will ask for a Farm Account, give it this user account. Used by the SharePoint Central Administration Web App’s application pool to communicate with SQL Server This account is sometimes referred to as the “database access account”	Farm	Person installing MOSS SharePoint Central Admin Application Pool WSS Administration Service	To log onto server to install MOSS During setup its asked for as the “Farm Account”	Member of the local administrators group on each MOSS server. Even though not a domain admin, this account must be a local server admin on each MOSS server. Member of SQL Server Security Administrator and Database Creator rights on SQL Server where databases will be created during setup. Before installing MOSS, make sure this user has these rights in SQL Server. Once done, you will not need to grant access to SQL objects again, SharePoint will do this for you when it get’s configured.
SSP App Pool Identity Account	Used by the SSP Web Application’s application pool to communicate with SQL Server Excel Calculation Services use this account by default to connect to data sources	App	SSP Web Application’s Application Pool Excel Services Service	During SSP creation	No rights or permissions should be explicitly given to this account. In other words, make this a standard domain user account (you might want to set password policies to prevent password expiring etc) SharePoint will automatically grant this account the correct permissions on the databases in SQL. SSP content database = DBO Content DB’s associate to SSP = Read/Write Central Admin content DB = Read Config DB = Read
SSP Service Account	User account for the SSP Web services to use for inter-server communication and for running SSP-scoped timer jobs	Farm	SSP Timer Service SSP Web Services	During SSP creation	No rights or permissions should be explicitly given to this account. In other words, make this a standard domain user account (you might want to set password policies to prevent password expiring etc)  SharePoint will automatically grant this account the correct permissions on the databases in SQL. These end up being the same rights and permissions as the SSP App Pool Identity Account
Search Content Access and Profile Import Account	Used by the MOSS search service to read content to index. It is also used by default to access AD to import user account information into the profile database. yes, you can have other accounts which you use to specifically connect to AD for profile import and and various accounts for all your content crawling, but for now I am assuming 1 account for all of these tasks.	SSP	Search Service	Supplied During SSP creation	No rights or permissions should be explicitly given to this account. In other words, make this a standard domain user account (you might want to set password policies to prevent password expiring etc)  SharePoint will automatically grant this account the correct permissions on the databases in SQL. This account must NOT be a member of the local administrators group. Well none of the accounts should be (except farm service account), but I really just wanted to call this out here explicitly because it has be known to cause issues with Search. A rule will automatically be created which grants this account read access to all MOSS content
Generic WSS Web Application Pool Identity	I generally recommend having one generic application pool identity (service account) for all the web applications (application pools) you create. Make life easier otherwise you create many accounts for all web applications (application pools). There is also a discussion to be had on how many application pools you need for your web applications, but is a discussion for another day. Used by all WSS web. This account will perform all communication between the web application and the SQL Server databases for those web applications.	App	Web Application Pools	During web application / application pool creation	No rights or permissions should be explicitly given to this account. In other words, make this a standard domain user account (you might want to set password policies to prevent password expiring etc)  SharePoint will automatically grant this account the correct permissions on the databases in SQL.

Question: How do I change my already bad deployment? Check this KB article out, which may help https://support.microsoft.com/default.aspx?scid=kb;EN-US;934838

I hope this helps in some little way next time you are tasked with this.

 

Michael

Comments

• Anonymous
  September 21, 2009
  So true Mike... I think these points can't be repeated enough times

• Anonymous
  October 28, 2009
  Micheal,   I see you suggested that the Farm Service Account be put in the local Administrators group on all the servers in the farm.  My question is "why is that?"  I have only found one reason that would require this configurations and that is that SharePoint (working under this account's context), attempts to write to the C:WindowsSystem32driversetchosts file every time you create a new web application.  In my production environment, I miticated this issue by giving WRITE access to the etc folder to the WSS_RESTRICTED_WPG.  Please let me know if I am miss understanding something or perhapse not aware of another system resource that is restricted to Administrators only that the Farm Service Account needs writes to.  

• Rashad Rivera

• Anonymous
  October 29, 2009
  The comment has been removed

• Anonymous
  November 11, 2009
  I have inherited a situation where a medium farm install, but each machine was installed with the local Dminiatrators account. This doc doesn't outline how to change this.  How can I do this?

• Anonymous
  February 28, 2011
  SharePoint 2010 complains about the Farm account being in the local administrator's group ? Example: Accounts used by application pools or service identities are in the local machine Administrators group. But you say that the farm account should be in the farm administrators group ? Has this changed in 2010 ?

• Anonymous
  March 13, 2011
  Please correct the table. With IE8 a column is missing all together. The only way to view the page is in Quirks mode and then it messes up the page.

• Anonymous
  March 15, 2011
  Yes Adrian, changed in 2010. For the official documentation for 2010 check out technet.microsoft.com/.../ee662513.aspx . In 2010 you have install / setup account which will be local admin, but farm/content access account wont  be.

• Anonymous
  December 17, 2012
  Sorry, but what exactly has this to do with Office 365? Isn't this article covering service accounts on On Premise SharePoint installations?

• Anonymous
  June 22, 2013
  Can we use only two account for SharePoint 2010 installation