SharePoint 2013: Service Account Configurations and Permissions

Status: Final

Introduction

Below are my notes in tabular form for SharePoint Server 2013 service account configurations and permissions. The data presented here is drawn from:

1. Cited references,
2. Microsoft documentation,
3. Blog postings,
4. Local security policy settings data exports,
5. SharePoint ULS log messages and
6. Trial and error.

Such settings as these are normally configured by the SharePoint 2013 Products Configuration Wizard on the local machine. However, in locked down environments, these settings will be overwritten by GPO. Therefore, in locked down environments, you will need to have these settings added to the GPO. Bolded settings are absolutely essential and deployment will fail without them. The non-bolded settings will not stop deployment or operations, but will affect performance and have other affects.

Service Account Configurations and Settings

Listed below are my recommendations for service account permissions and user rights.

Service Account	Suggested Name	Domain Permissions	Local Permissions [see notes 1,2,3]
User administrator	spAdmin	User	Local Admin
Farm service	spFarm	User AD Read for all service accounts [see note 5]	Local Admin [see note 4] Allow log on locally Adjust memory quotas for a process Impersonate a client after authentication Log on as a batch job Log on as a service Replace a process level token
Web Application Pool	spApp	User	Impersonate a client after authentication Log on as a batch job Log on as a service
Services Pool	spService	User	Adjust memory quotas for a process Log on as a batch job Log on as a service Replace a process level token [see note 9]
Search	spSearch	User [see note 8]	Adjust memory quotas for a process Impersonate a client after authentication Replace a process level token
SQL Server	spSQL	User AD Read for workflow service account [see note 6] and SQL backup service account [see note 7]	Adjust memory quotas for a process Bypass traverse checking Log on as a service Replace a process-level token
Workflow	spWorkfl	User [see note 10]	Log on as a service Impersonate a client after authentication Allow logon locally Logon as a batch job
Super User	spSuperU	User	None
Super Reader	spSuperR	User	None
AD profile access	spProfile	User Replicate Directory Changes	None

References

• Account permissions and security settings in SharePoint 2013
• SharePoint Portal Server 2003: Changing Access Accounts and Passwords
• SQL Server 2000: Changing Access Accounts and Passwords
• SQL Server 2012: Configure Windows Service Accounts and Permissions
• Privilege Constants
• User Rights Assignment
• Services permissions
• Grant User Rights to a Service Account
• Plan for administrative and service accounts in SharePoint 2013
• SharePoint 2013: Processing this item failed because of an unknown error when trying to parse its contents
• SharePoint 2013: - Failed to launch sandbox process, SE_ASSIGNPRIMARYTOKEN_NAME and SE_INCREASE_QUOTA_NAME privileges are require
• SharePoint 2013: An exception occurred when trying to establish endpoint for context: Could not load file or assembly...
• How to setup SharePoint 2010 user profile synchronization and MySites; search for "rights"
• TechNet: User Rights: Windows Server 2008
• TechNet: User Rights Assignment: Windows Server 2012
• SharePoint 2013 Service Accounts Best Practices Explained: interesting somewhat different perspective than mine - good to get different views on this so as to more informatively craft the best policy for your own situation.
• SharePoint 2013: Group Policy Considerations for a SharePoint Farm
• Recommendations for SharePoint Setup User Account and SharePoint Farm Administrators Group
• SharePoint 2013: Service Accounts

Notes

1. If your AD environment doesn't control user rights assignments via GPO, you don't need to configure these yourself as they are done automatically for you by the SharePoint Products Configuration Wizard.

2. If you're not sure what user rights assignments are being configured, you can determine them by: 1) performing a configuration change and then 2) opening the local Security Policy on the local machine (most likely the Application or Batch server), and then viewing User Rights Assignments - do an export to save these for reference. Repeat this after every new application and service instantiation and you will build up a pretty good understanding of what is being configured here. NOTE: if you have GPO pushed out regularly, you will need to view and export these assignments quickly - before the GPO is pushed out again, as this will overwrite these assignments.

3. SharePoint Service Account User Rights Assignments: I have not been able to find any definitive, office Microsoft presentation of Local Security Policy user rights assignments for SharePoint 2007, 2010 or 2013. I did find them for SharePoint Portal Server 2003. Microsoft's TechNet pages for account permissions and security setting for SharePoint 2007, 2010 and 2013 do not discuss user rights assignments at all. On the other hand, Microsoft does provide these critical settings for another flagship application, SQL Server, doing so from SQL Server 2000 through 2012. Thus, obivously, Microsoft recognizes the importance of these settings to its applications. It's thus very unclear why Microsoft has failed to disclose these critical settings for SharePoint, as these settings play just as critical a role in the successful deployment and performance of SharePoint as they do for SQL Server.

4. The farm service account (aka, database access account) only needs to be a member of the local admin group during installation and configuration tasks.  During normal operation, the farm service account does not need to be a local administrator.

5. AD Read.  This Service Permission grants the ability to the farm service account, or any other account, to be able to read critical account security information, such as account restrictions.  Note that this permission is actually composed of a number of sub-permissions, including the Read account restrictions permission, which is critical.  I'm not presently sure which other specific read sub-permissions are necessary, so, simply selecting Read covers all the bases.  I will update this posting when I know more.

6. This permission is needed for the successful deployment of SharePoint Server 2013 Workflow Manager.  This permission should be granted to whatever account you have running the SQL Server Service, be it Local Service or what not.  If you do not grant this permission, your Workflow Manager configuration will fail on the first step with error message:

   Could not obtain information about Windows NT group/user '{your workflow service account}', error code 0x5.

   When you then look at the log file for the workflow deployment, you see this conclusive message:

   ...System.Data.SqlClient.SqlException: Could not obtain information about Windows NT group/user '{your workflow service account}', error code 0x5...

7. This is the account that you used to login to SQL Server and create the scheduled farm database maintenance plans.  For example, if you logged into SQL Server Management Studio as the farm service account, and then created the farm database scheduled maintenance plans while logged in as this account, you would grant the SQL Server service account (eg, spSQL) AD Read permission to the farm service account.  If you do not grant the AD Read permission, you will experience the following SQL Server error when attempting to execute a maintenance plan:

   [date] [time],,Error,[298] SQLServer Error: 15404<c/> Could not obtain 
   information about Windows NT group/user [Account you are logged in as
   ]<c/> error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
   

8. There are a number of postings concerning the user rights assignments necessary in order for the search service to run properly.  Read this posting to find more references on this topic.

9. Without these user rights, the application pool run by this account will not remain started.

10. Verify that the SharePoint Setup User Administrator, SQL Server and Farm Service accounts have AD Read permission to the service account that will be used to run Workflow Manager.