SharePoint Service Accounts (Sharepoint 2010)

How to deal with SharePoint service accounts? The following questions always come up at the beginning of a SharePoint project:

Which accounts are needed?
When does it make sense to use dedicated accounts for special tasks?
Which permissions are necessary?
Who does really need the right ‘logon as a service’?

I prepared a list of necessary SharePoint service accounts and permissions during my last project.
Please scroll down for further details. Each service account is described more detailles below the list.

Overview: SharePoint Service Accounts and Permissions

Summary:

Necessary Sharepoint Service Accounts

I will describe the accounts from the list a bit more in detail and try to answer the 2 main questions:

• What is the account used for?
• What persmissions are necessary?

SharePoint administrator / Installer Account

This account is used for the installation of the SharePoint farm. It can add and remove server and should be used to install patches and updates. About this issue there are many discussions which could not be answered clearly yet. There are recommendations advising to always use the same account for the SharePoint setup and the installation of patches and updates. However, this requires an anonymous, non-personalized setup-account which can log on to servers interactively and whose password is known to several persons. A lot of companies are eager to get rid of exactly such accounts. Unfortunately we could not get a clear answer from Microsoft and thus decided to use a personalized admin-account for the setup.

A regular account (domain user) with the following permissions suffices:

• Member of the farm administrators group
• SQL Security Admin
• SQL dbcreator
• Local Admin on each server of the farm
• SharePoint_Shell_Access (for the use of PowerShell)

SharePoint Farm Service

This account is for the automatic communication within the farm. Permissions for it are assigned automatically during the installation of the farm (SQL dbcreator, securityadmin und db_owner). A regular domain user is enough, too.
Important: During the installation of the service application ‘User Profile Service’ this account has to temporarily have local admin rights on the User Profile Service Application-server because the MIIS-components are installed with these credentials.

Application Pool Account

This account is deposited at the IIS application pools. The SharePoint WebApplications inherit its identity. This account can usually be used for all Application Pools but exceptions can be made for special security relevant areas.

The account is to be registered as ‘managed account’ in the SharePoint farm. No additional permissions are necessary.

Service Application Account

This account is used for all service applications. It is registered as ‘managed account’ in the SharePoint farm. No additional permissions are necessary.

SharePoint Search Account

With this account SharePoint content is searched. It needs at least LESE permissions on all data of the farm. These permissions are assigned automatically when the first WebApplications creates the Search Service Application. Important is the following distinction: the Search Service Application runs with the Service Application Account. The search however, is performed by the Search Account. A regular account (domain user) is sufficient.

User Profile Synchronization Account

This account synchronizes information of the Windows domain with the SharePoint farm. This includes i.e. users and groups. For the transfer of the information it needs special ‘replicating directory changes’ permissions in the Windows domain. Caution: There are two almost similarly named permissions: ‘replicating directory changes’ and ‘replication directory changes all’. Only the first one works.

SQL Server Service

Most SQL servers run as ‘local system’ without a Special Service Account which is also possible for SharePoint installations. In case SharePoint Backup with PowerShell should be employed, the SQL server has to run with a Service Account though. PowerShell cmdlets export the data from the SQL data base with the identity of the SQL server. In case the SQL server runs as a ‘local system’, the data cannot be transferred to a network share.