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
SharePoint Administrator / Install Account
SQL server loginSQL securityadmin
Local admin of each server in farm
For installlation / patchesLocal admin of each server in farm
SharePoint Farm Service
SharePoint assigns permissions automaticallyLocal admin on UPS (user profile) server
Dbcreator, securityadmin, db_owner
To be registered as “managed account”
Assigned as application pool identity
Service Application Account
To be registered as “managed account”
SharePoint Search Account
Read permissions to all SP content (automatically)
Configure SP_Crawl before creating webapps
User Profile Synchronization
“replicating directory changes” permissions on domain level
SQL Server service
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?
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)
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.
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.
This account is used for all service applications. It is registered as ‘managed account’ in the SharePoint farm. No additional permissions are necessary.
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.
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.
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.