SharePoint Services and App Pool Account Permissions

  • Article

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:

1.
2. Account(s) which the SPS services will run as i.e. service accounts

  1. Database configuration account

  2. Content crawler access account

  3. Application pool account

Service Accounts:

In order to understand the permissions required for service accounts, it is important to understand what the services actually do.

  1. SharePointPSSearch (mssearch.exe) - Microsoft SharePoint Portal Server Search service provides indexing and searching over the portal and external content. Servers that run the Search Service will parse through the indexed data and return results to the users. It is also responsible for gathering and indexing all of the searchable portal content both internal and external. This service account should be a member of the “Power Users” group on all machines running Portal Server. SPS uses SMB to propagate the Indexes (from Index to Search server), the reason the service account needs the power user role will have to do with the fact that it needs to maintain a “share” for the copying.
  2. SPSAlert (SPSNotificationService.exe) - The purpose of the SharePoint Portal Alert service is to notify a user, when the user requests it, that there is a change to a designated item, document, list, or document library on the website. Alerts are managed by the job server. This service account should be a member of the “Power Users” group on all machines running Portal Server.
  3. SPSAdmin (Spsadmin.exe) - SharePoint portal administration - SPSAdmin is a service that was written to maintain the configuration of each server in a SharePoint Portal Server deployment. Essentially, this service runs on each server in the farm and is responsible for checking the configuration database every 30 seconds to ensure that the local server is performing its assigned roles. E.g. SPSAdmin can stop and start services that SharePoint Portal Server needs, including SPSSearch. It can also add or delete catalogs and can add or delete search applications as needed. In the SharePoint Portal Server Central Administration/Component Selection area, each server in the farm must be assigned at least one role to perform in the farm. When a role is assigned to a server in the farm, it is recorded in the configuration database. The SharePoint Portal Administration service checks this database every 30 seconds to ensure that the server is performing its assigned role or roles. If the service discovers that there is a modification in the server’s roles, the service will “turn on” or “turn off” those portions of the server’s code to either stop performing a role or to start performing a role. Should run as an account that is a SharePoint Portal Server administrator i.e. member of “Power Users” group on all machines running Portal Server. There is a SQL Server database restore scenario (which can be found in the “Disaster Recovery in SharePoint Products and Technologies” chapter in the SPS resource kit) that in order to work dictates that the spsadmin service account must either be a member of the Administrator’s group on the Web front-end server or be a Windows SharePoint Services administrator. According to recommended security practices, you should not grant the spsadmin account administrator rights; on the server, the spsadmin account should be granted as few privileges as possible. By default, the content access account is granted Windows SharePoint Services administrator rights. You should 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.
  4. SSOSRV - Single sign on service - Provides single sign-on services for line of business applications. This service should run as an account that is a member of the “Power Users” group on all machines running Portal Server.
  5. SPTimer (OWSTIMER.EXE) – This is not actually a SPS service, but rather a WSS service. The SharePoint Timer Service sends notifications and performs scheduled tasks for Windows SharePoint Services. This service account should be a member of the “Power Users” group on all machines running Portal Server.

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

  1. Must be a Db_owner on these databases; portal site _SITE database, _SERV database, _PROF database, and for the configuration database (by default, this is SPS01_Config_db)

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.

  1. During SPS install specify the Domain\ServiceAcc as the database configuration account
  2. Just after SPS installation, during SPS configuration specify the Domain\ContentCrawlUserAcc as the content crawler account and Domain\PortalAppPoolUser as the application pool identity for the default portal application pool
  3. Create custom “SharePoint Administrators” group
  4. Add “Domain\ContentCrawlUserAcc” to the custom “SharePoint Administrators” Group
  5. Add “Domain\ServiceAcc” to the custom “SharePoint Administrators” Group
  6. Using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to the custom “SharePoint Administrators” group
  7. Ensure that user cannot change password and password never expires are selected for these user accounts in AD.
  8. A good practice is to ensure that "user user cannot change password" and "password never expires" are selected for these user accounts in AD

Comments

  • Anonymous
    June 14, 2005
    Was good to chat to Michael again, though now that he is English, it will be better once “The...

  • Anonymous
    May 09, 2006
    Aprés lecture du post de Fabrice (qui décidemment commence à prendre à son interim SharePoint   ) sur...

  • Anonymous
    November 06, 2006
    PingBack from http://www.malcolmgin.com/msblog/?p=33

  • Anonymous
    May 08, 2008
    In Internet Information Server 6.0 there is a new user group IIS_WPG which basically gives a minimum

  • Anonymous
    June 20, 2008
    PingBack from http://viviana.meinvoll.com/pooledaccounts.html

  • Anonymous
    July 11, 2008
    PingBack from http://rickenberg.net/blog/?p=45

  • Anonymous
    September 14, 2008
    This is a keeper, so I'm bookmarking it. http://blogs.msdn.com/modonovan/archive/2005/06/14/428862.aspx Don't mind me....

  • Anonymous
    December 05, 2008
    A great article, so useful to find all this info in one place!

  • Anonymous
    January 16, 2009
    I can't find anything on any blogs or KBs or articles that are specific to my current issue.  But I think that they deal with the subject matter here. After upgrading to MOSS SP1... all of my workflows stopped working.  Built-in workflows on the MS Application Templates, just stopped.  Some say "Failed on Start" some just don't do anything.  After a bit of poking around, I see that SP1 implemented a new security policy that disallows "System" accounts from being the account that runs the Application Pool.  So now, I'm stuck trying to change the user that the Application Pool runs as away from "Network Service" to a local or domain account.  Everytime I do this, the whole MOSS server becomes unaccessible... HELP!!!

  • Anonymous
    June 16, 2009
    PingBack from http://fixmycrediteasily.info/story.php?id=487

  • Anonymous
    July 29, 2009
    be careful!! this blog refers to WSS 2.0 and SPS 2003, not MOSS 2007 or WSS 3.0!!!

  • Anonymous
    December 09, 2012
    i also had a better option for the pool owner that is of Above ground swimming pools. Above ground swimming pools help you in many ways and also to save your many also..<a href="www.southsidepool.com.au/">pool supplies perth</a>