SharePoint 2016 Service Accounts Recommendations
Service Accounts are a very big part of installing every version of SharePoint, however everyone has a different way of setting them up. And once you install your SharePoint with a set of service accounts, it’s not always easy to change them. Let’s take a look at the SharePoint 2016 Service Accounts that I reccomend.
Every SharePoint administrator you ask, will have a different opinion on how many service accounts you need and whether you should have dedicated service accounts for some Service Applications or certain administration tasks. Even if all SharePoint Administrators have different opinions, it doesn’t mean some are wrong and some are right, there is no real “golden” solution that will be good for every SharePoint farm out there. From my experience with SharePoint, here are the Service Accounts that I recommend for your SharePoint 2016 implementation.
SharePoint 2016 Service Accounts
The following Service Accounts can be named according to your companies naming convention. Local Security Policies only need to be configured if you have Group Policies that will take those away.
| Account | Description | Local / Application Permissions | Local Security Policy |
| SP_Admin | This account will be used to Install and configure the SharePoint farm initially. After the initial setup, you can grant the farm administrator rights to your SharePoint Administrators account so they can log in and manage SharePoint with their own account. |
| Back up files and directories Debug Programs Manage auditing and Security log Restore files and directories Take ownership of files or other objects |
| SP_Farm | Runs the SharePoint Timer and Administration Service |
| 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 |
| SP_Services | Runs the Application Pool for most of your Service Applications. There are some service applications that require more rights and a dedicated Service Account is recommended. We’re converting those a bit lower in this blog post! |
| Adjust memory quotas for a process Log on as a batch job Log on as a service Replace a process level token Impersonate a client after authentication |
| SP_Pool | Runs the Application Pool for your Web Applications. |
| Impersonate a client after authentication Log on as a batch job Lon as a service |
| SP_Crawl | The Default Content Access Account for the Search Service Application. This account is sued to crawl the content of your SharePoint Web Applications. |
| |
| SP_Sync | Used to synchronize profiles between AD and SharePoint Server 2016 |
| |
| SP_C2WTS | Used to run the Claims to Windows Token Service |
| Act as part of the operating system Impersonate a client after authentication Log on as a service |
| SP_SU | Object cache account (Super User). Must not be an account that will ever be used to log in to the site. |
| |
| SP_SR | Object cache account (Super Reader). Must not be an account that will ever be used to log in to the site. |
|
SQL Service Accounts
The following Service Accounts are recommended for your dedicated SQL Server hosting SharePoint databases and can be named according to your companies naming convention. Local Security Policies only need to be configured if you have Group Policies that will take those away.
Account | Description | Local / Application Permissions | Local Security Policy |
SP_SQLAdmin | This account will be used to Install and configure the SQL Server initially. After the initial setup, you can grant the SQL Admin rights to your SQL Administrators account so they can log in and manage SQL with their own account. |
| Back up files and directories Debug Programs Manage auditing and Security log Restore files and directories Take ownership of files or other objects |
SP_SQLEngine | This account will run the Database Engine service |
| Log on as a service Replace a process-level token Bypass traverse checking Adjust memory quotas for a process Perform Volume Maintenance Tasks (Only If you want to enable Instant File Initialization) |
SP_SQLAgent | This account will run the SQL Server Agent Service |
| Log on as a service Replace a process-level token Bypass traverse checking Adjust memory quotas for a process |
Other Accounts Depending on your Scenario
Depending on what features you plan to use in your SharePoint 2016 implementation, here are some other Service Accounts that I recommend:
Account | Description | Local / Application Permissions | Local Security Policy |
SP_WFM | This account would be used as the RunAs account for the Workflow Manager and Service Bus Farms. If you want, you could create a dedicated account for each. |
| Impersonate a client after authentication Log on as a service Log on as a batch job |
SP_Access | This account would be used to run the Service Application Pool for the Access Apps for SharePoint Service Application. The reason of a dedicated service account is that this account requires special permissions in SQL as well as special settings on the Access App Services Service Application |
| Adjust memory quotas for a process Log on as a batch job Log on as a service Replace a process level token Impersonate a client after authentication |
SP_PowerPivot | The PowerPivot unattended data refresh account is a designated account for running PowerPivot data refresh jobs in a SharePoint farm. |
|
General Recommendations for SharePoint 2016 Service Accounts
Whatever accounts you choose, here are some recommendations that you need to follow for your SharePoint 2016 service accounts.
First of all, the length of your Service Accounts Username should be less than 20 (including domain name). This is due to the SAM-Account-Name attribute (also known as the pre–Windows 2000 user logon name) which is limited to 20 characters in the AD Schema. For example, CORP\SP16Prod_SuperReader is 25 characters and would be too long.
My second recommendation is to use different service accounts for each environment. For example, your production might have a SP_Services, while your QA account would be SPQ_Services. This makes sure that nothing in a farm can affect the other one, and if you ever want to test for example changing the password of the managed account, or giving the password of the QA account to someone else, you will not compromise the security and stability of your production SharePoint farm.
Follow me on Social Media and Share this article with your friends!
|
| Leave a comment and don’t forget to like the Absolute SharePoint Blog Page on Facebook and to follow me on Twitter here for the latest news and technical articles on SharePoint. I am also a Pluralsight author, and you can view all the courses I created on my author page. |
