The following covers the most common service accounts that need to be setup and their typical permissions in order for MOSS to function properly. Note that each deployment is different, so these accounts may differ based upon individual requirements. There are some additional accounts that you may need for other optional services, but they are not mentioned here.
Running MOSS Setup
On every server where MOSS is to be installed, the account you run setup with must belong to the local administrators group. In addition, this account must be a Domain User and be a member of the following SQL server security roles: Logins, Securityadmin & Dbcreator. This account is going to be doing a lot – creating new databases, and also creating new IIS sites – so make sure you have enough permission! Typically, an account such as the domain administrator is used to run the installation, which addresses all of the security requirements.
SQL Server (SQL_Service)
This account is specified when a new SQL server is being brought online or a new instance installed. It typically is used for running both the SQL Server & SQL Server Agent, however, each can have their own account. For our purposes, we will utilize one account for both SQL Server & the Agent. The account only needs to be a basic Domain Account with no specific permissions set. When SQL Server is installed, all of the other appropriate permissions will be granted to the account.
Database Access Account / Farm Account (Farm_Service)
This account serves a few roles. The first is that it is used by MOSS to access the databases… it acts as the account by which the server(s) MOSS is installed on communicates back and forth to SQL with (read/write). Additionally, it is used as the identity for the Central Administration application pool & the WSS Timer service. This account needs to be a Domain Account - but note that it is believed to have to be a local admin on every MOSS box – this is not true, as Spence points out very eloquently.
Shared Service Provider (SSP#_Service)
Each shared service provider can run under its own account, therefore, it is desirable to name the account using a number. This way, if your MOSS farm ends up having a large number of SSPs, you can map the SSPs back to their specific service accounts easily. This account is used for the SSP web services & the SSP timer jobs. The account only needs to be a basic Domain Account with no specific permissions set.
Office SharePoint Server Search (Search Service)
This account is utilized by all of the Shared Service Provider to crawl local & remote content. This account should be a Domain Account & have local administrator permissions on each MOSS server.
Default Content Access Account (SSP#ContentAccess_Service)
When a shared service provider crawls content, this is the default account used if a specific account (see below) is not specified for the content source being crawled. This account is specific for each individual SSP. This account should be a Domain Account & have read access to the content sources it needs to crawl.
Content Access Account (XXXXContent_Service)
If you have specific content sources that need to be crawled, and you do not want to allow the default content access account to crawl them, then you specify an individual content access account (specified at the time a Crawl Rule is setup). This account is a Domain Account with read permissions specifically on the content source it crawls.
Windows SharePoint Services Search Account (WSSSearch_Service)
The WSS Services Search is used only to provide search capabilities within the Help content. If this search feature is desired, then this account should be configured as a Domain Account with no specific permissions.
Application Pool Process Account (XXXXPool_Service)
When each application pool is setup, you must specify an account that will be used for that specific application pool’s identity. This account will be used to access the content databases associated with the web application. It is recommended that a new service account is created for each application pool. This should be a Domain Account with no specific permissions. When the account is specified & SharePoint creates the application pool, it automatically grants the account additional needed permissions.
Share this
