Firstly Daniel McPherson has contacted me and we seem to be talking again. Since moving to his "new" role he has become very distant, probably because he is spending so much time doing excellent work with our partners and customers. He of course has also been a big influence in the content of this blog.
For some time I have been confused about the permissions required for service accounts in SPS and application pool accounts. Most of this confusion has been based on not actually understand exactly what these things do. I have tried to summarise my findings below. I still not 100% happy as I haven't answered the "why" questions e.g. why does the SPSAlert service account need the "Power User" role, surely all it does is talk to the DB and send emails. Therefore I am very happy to accept all comments that will help in this understanding.
There are essentially 4 types of management user accounts (i.e. excluding business users) that need to be given permissions in an SPS solution. They are:
In order to understand the permissions required for service accounts, it is important to understand what the services actually do.
Note: during the installation of SPS all services mentioned above are set to run as the account specific as the database configuration account. This can be changed afterwards but I haven’t found any documentation that steps you through this and hence don’t recommend changing it.
Database configuration account:
Used for administrative operations that create, modify, or grant access to the configuration or portal site databases. The configuration database administration account is the user name and password that SharePoint Portal Server uses when connecting to the configuration database or when propagating full-text indexes from index management servers to search servers. The SharePoint Central Administration web site’s application pool identity is also configured to run as this user account by default. There is some confusion here about permissions of the account used for this. In the SPS Admin guide and the during SPS installation it states “The account must be a member of the Power Users group on this server” and explicitly states “Specifying an account that is a member of the local Administrators group on the server on which you are installing SharePoint Portal Server is not recommended”, however the Microsoft Solution for Intranets Guide suggest that this be given “Local administrator rights on search and index servers”. I recommend going for the more secure option of just Power users and if this doesn’t work upgrade to Administrators.
The account must have the Database Creators and Security Administrators server roles on this SQL Server instance. In addition, the account must be a domain account if you have more than one server in your configuration. The following user rights are granted automatically to this account (the configuration database administration account) on the local server: “Replace a process level token”, “Adjust memory quotas for a process”, and “Log on as a service.” Note: all services are also set to use this account during installation of SPS, and the SharePoint Central Administration web site’s application pool is also configured to run as this user account during installation, hence it will be added to all the local groups for an app pool account e.g. STS_WPG etc.
Content Access Crawler Account:
This account is used as the default account for crawling content sources defined for a content index. The account must have read access to the content being crawled. What is generally recommended, especially if there are several WSS virtual servers that need to be crawled, is to use a user account that has Windows SharePoint Services administrator rights. Otherwise you will need to give the account rights to every web site on every WSS virtual server that needs to be indexed. Remember; users who perform searches will only get results back that they have permissions to access. By default, the content access account is granted Windows SharePoint Services administrator rights, however as mentioned previously it is recommended that you create a new Windows security group, and add both the content access account and the spsadmin service account to this group. Then, using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to be this Windows security group.
You are prompted for the user name and password for this account immediately after SPS has been installed, during the initial configuration. This can be changed at any time by using the SPS administration web pages.
Application Pool Identity:
The application pool identity is essentially what the ASP .Net code of the portal site will be executing as. The user account used here must have the standard rights in order to run an application pool, and must obviously have rights to read and write to the SQL Server databases for the portal. When the portal is created the designated user account is given these permissions automatically, hence you shouldn’t need to change this. However, in the references section is a link to an article which describes how to change identity of existing application pool or change application on a portal site if needed. The following rights are required for the application pool identity:
Must be a member of the IIS_WPG, SPS_WPG, and STS_WPG groups on the web server
You are prompted for the user name and password for this account immediately after SPS has been installed, during the initial configuration to setup default IIS sites application pool to run as the chosen user.
In summary, a recommended scenario would be:
It may be easier to have a single user account as the service account for all SPS services, a single account for content crawling a single account for the configuration db access and then an account each for each application pool. E.g.:
Add “Domain\ServiceAcc” to “Power Users” group on all Portal Servers. This account will be used to run all SPS services, will be the database configuration account and will be the application pool identity for the SharePoint Central Administration web site. Grant this account the Database Creators and Security Administrators roles in SQL Server.