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 http://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