Wednesday, May 7, 2014

SharePoint 2013: Service Account Configurations and Permissions


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.  Bolding 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

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

  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.