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.	Domain User Local Administrator on the SharePoint Servers Member of the following SQL Roles DB Creator Security Admin	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	Domain User Member of the following SQL Roles DB Creator Security Admin	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!	Domain User	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.	Domain User	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.	Domain User This account needs to have Read Access on all your Web Applications (given automatically)
SP_Sync	Used to synchronize profiles between AD and SharePoint Server 2016	Domain User Needs to have “Replicate Directory Changes” in the Active Directory >> Tutorial here
SP_C2WTS	Used to run the Claims to Windows Token Service	Domain User Local Administrator on all SharePoint Servers running the C2WTS 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.	Domain User Full Control on your Web Applications
SP_SR	Object cache account (Super Reader). Must not be an account that will ever be used to log in to the site.	Domain User Full Read on your Web Applicationss

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.	Domain User Local Administrator on the SQL Server	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	Domain User	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	Domain User	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.	Domain User Local Administrator on the WFM Servers Full Control to the Web Applications where Workflow Manager will be used	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	Domain User Member of the following SQL Roles DB Creator Security Admin Read/Write permission to the config cache folder located at C:\ProgramData\Microsoft\SharePoint\Config The IIS Application Pool running the Access App Services Service Application needs to have “Load User Profile” at True. Navigate to the IIS Application Pools , and from Advanced Settings, change “Load User Profile” to True.	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.	Domain User Read permissions to external data sources

General Recommendations for 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.

The post SharePoint 2016 Service Accounts Recommendations appeared first on Absolute SharePoint Blog by Vlad Catrinescu.

by Vlad Catrinescu via Absolute SharePoint Blog by Vlad Catrinescu