Partager via

Most common issue with SharePoint installations – service account misuse

  • Article

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