SharePoint Service Account Best Practices 2019/2016

In this post, we’re gonna list the SharePoint Service Account best practices in SharePoint 2019 and SharePoint 2016 by exploring the following:

You might also like to read SharePoint 2019: SQL Server Recommendations

---

SharePoint Service Accounts Best Practices

Before installing a new SharePoint 2019/2016/2013 farm, you should first plan for the required service accounts that will be used to run windows services, application services, and web application pools within the SharePoint farm.

So, here, we’ll try to list the most common SharePoint Service Accounts recommendations that you should follow to avoid any permission issue related to the SharePoint Service Accounts as well as to use the recommended least-privilege administration. Moreover, to be able to configure and maintain secure control of your farm.

SharePoint Service Accounts Recommendations

1. The service account must be a domain user, not a local user.
2. The farm account should only run
   • SharePoint Timer service.
   • IIS Application Pools for Central Administration.
   • SharePoint Web Services System used for the topology service.
   • Security Token Service Application Pool.
   • It is also the windows account that used to connect to the configuration database during configuring the configuration database settings in the SharePoint configuration wizard.

3. It’s recommended to use a minimal number of Service Pool accounts on the farm to reduce memory usage and increase performance.
4. It’s recommended to use a single account for all SharePoint Web Applications Pools except the Central Administration that should be running by farm account.
5. It’s recommended to use a single IIS Application Pool for all Web Applications except the Central Administration that should be running by farm account.
6. It’s recommended to use a single account for all Service Applications except (User Profile Sync Service).
   • This account will be used to run
     • The IIS Application Pool Service Application.
   • It should also run the below windows services.
     • SharePoint Search Host Controller.
     • SharePoint Server Search.
     • Distributed Cache.
7. It’s recommended to use a single IIS Application Pool for all Service Applications except (User Profile Sync Service).
8. Use different service account for
   • User Profile Synchronization Service Application (UPSS).
   • Search crawler.
   • Claims to Windows Token Service.

9. All Service Application Pool accounts should not be added to the Local Administrator Group in any SharePoint server.
10. All Service Application Pool accounts should not have any elevated SQL Server roles.
11. The SharePoint Farm Account shouldn’t be added to the Local Administrator Group except in certain circumstances that require local administration permissions like configuring User Profile Service.
12. The highly privileged account on the farm is the “Claims to Windows Token Service account” and it must be added to the local administrator group on any SharePoint server running “Claims to Windows Token Service” within the farm.

13. In the Local Security Policy (secpol.msc), the “Claims to Windows Token Service account” should have
    • Log on as a service.
    • Act as part of the operating system.
    • Impersonate a client after authentication.
14. In the Local Security Policy (secpol.msc), all Service Application Pool accounts (Except for the “Claims to Windows Token Service account”) should have
    • Deny log on through Remote Desktop Services.
    • Deny log on locally.
15. All SharePoint service accounts shouldn’t have the sysadmin role on the SQL Server.
16. All SharePoint service accounts shouldn’t be a local Administrator on the server that runs SQL Server.
17. SharePoint Admin Account (Setup Account) will require a “dbcreator” and “securityadmin” server roles, not a sysadmin server role only during the installation, update and upgrade.
18. After performing the SharePoint Installation and configuration, only the farm account should have a “dbcreator” and “securityadmin” server roles. and you should remove these roles from other SharePoint Service accounts even the SharePoint Admin (Setup) Account.

19. The service account names must not contain the $ symbol.
20. The service Account name must be shorter than 20 characters.
21. The below SharePoint Service accounts should be added to the “Managed Accounts” to be managed by SharePoint.
    • SharePoint Farm Account.
    • SharePoint Web Application Pool Account.
    • SharePoint Service Application Pool Account.
    • Claims to Windows Token Service Account.

22. Accounts Password used for SharePoint Services should never be changed outside the SharePoint farm.
23. It’s strongly recommended to don’t use the same service accounts for another farm.

You may also like to read SharePoint 2019: SQL Server Recommendations

---

SharePoint administrative Components?

After understanding the general SharePoint Service Accounts recommendations and before going to explain the required permissions for each SharePoint Service Account, let us first briefly explore the built-in and commonly used components that allow you to administrate, configure and manage the SharePoint Farm.

1) SharePoint Management Shell

The SharePoint Management Shell is a Windows PowerShell Interface for SharePoint to manage directly with SharePoint Server using PowerShell command lines.

2) SharePoint Central Administration

The SharePoint Central Administration is a centralized Admin panel that used to administrate, monitor, manage and configure your SharePoint farm.

3) SharePoint Products Configuration Wizard

The SharePoint Products Configuration Wizard is a configuration wizard that used to configure and apply SharePoint Products configurations and updates.

---

Permissions levels and Security settings for SharePoint Farm

Great, we have listed the common instructions that you should follow for the SharePoint service account and also explored the three main components that used to administrate, configure and manage your SharePoint Farm.

So, in this section, we will us also try to understand the required SharePoint permissions levels and security settings based on the following levels:

1. Machine Permissions level.
2. SQL Server Roles level.
3. Database Roles level.
4. SharePoint Security Groups.
5. Farm Administrator Group.
6. Managed Accounts.

1) The Machine Permissions for SharePoint Service Accounts

To control the security setting on the machine level for SharePoint, you should be aware of the following:

1. Local Administrator Group.
2. Local Security Policy.

1) Local Administrator Group

The Local Administrator Group is a built-in windows security group that allows its members to have a complete and unrestricted access to the local machine.

SharePoint Service Account Best practices related to Local Administrator Group

As we have earlier mentioned, we should avoid granting unneeded permissions for the SharePoint Service Accounts, especially on the Machine level. Because this will definitely conflict with the organization’s security policies.

Therefore, you must follow the below SharePoint Service Accounts recommendation that mainly related to the Local Administrator Group:

1. All Service Application Pool accounts should not be added to the Local Administrator Group in any SharePoint server.
2. All SharePoint Service Accounts should not be added to the Local Administrator Group in any SharePoint server, except
   • SharePoint Setup Account.
   • Farm account (only during configuring User Profile Service or as needed).
   • Claims to Windows Token Service Account.
3. The highly privileged account on the farm is the “Claims to Windows Token Service account” and it must be added to the local administrator group on any SharePoint server running “Claims to Windows Token Service” within the farm.
4. All SharePoint service accounts shouldn’t be a local Administrator on the server that runs SQL Server.

Note: Claims To Windows Token service (C2WTS) is disabled by default,

Add an account to the Local Administrator Group

To add an account to the Local Administrator Group, you should do the following:

• Login to the Server with the Administrator Account.
• Open Server Manager > Tools > Computer Management.

• Go to Local Users and Groups > Groups > Double click on the Administrators group.
• Click “Add” to add the domain account in the Local Administrator Group.

2) Local Security Policy

The Local Security Policy is a set of security settings on a local machine. it helps you to manage and control the rights and privileges assigned to an account.

Manage User Rights in the Local Security Policy for SharePoint Farm

To allow or deny a specific right for an account, you should do the following:

• Login to the Server with the Administrator Account.
• Run “secpol.msc“.

• Go to “Security Settings” > “Local Policies” > “User Rights Assignments”.

• From the right side, double-click on the required policy, Click on “Add User or Group” to allow accounts to log on as a service.

• Run the below command to apply the policy.

gpupdate /force

If the “add a user to the local security policy” was disabled, Please check Logon failure: The user has not been granted the requested logon type at this computer.

The list of Local Security Policy Rights

In some cases, you may need to allow an account to perform a specific action on the local machine, so in such cases, Instead of adding this account to the Local Administrator Group that provides full control on this machine, you should use the Local Security Policy Rights to allow or deny an account to perform a specific action on the local machine like the following security rights:

Log on as a service

This security setting allows a security principal to log on as a service. Services can be configured to run under the Local System, Local Service, or Network Service accounts, which have a built-in right to log on as a service. Any service that runs under a separate user account must be assigned the right.

Act as part of the operating system

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. If your organization only uses servers that are members of the Windows Server 2003 family, you do not need to assign this privilege to your users. However, if your organization uses servers running Windows 2000 or Windows NT 4.0, you might need to assign this privilege to use applications that exchange passwords in plaintext.

Assigning this user right can be a security risk. Only assign this user right to trusted users.

Impersonate a client after authentication

Assigning this privilege to a user allows programs running on behalf of that user to impersonate a client.

Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user’s permissions to administrative or system levels.

Assigning this user right can be a security risk. Only assign this user right to trusted users.

Log on as a batch job

This security setting allows a user to be logged on by means of a batch-queue facility and is provided only for compatibility with older versions of Windows.

For example, when a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user.

Deny log on through Remote Desktop Services

This security setting determines which users and groups are prohibited from logging on as a Remote Desktop Services client.

Deny log on locally

This security setting determines which users are prevented from logging on at the computer. This policy setting supersedes the Allow log on locally policy setting if an account is subject to both policies.

If you apply this security policy to the Everyone group, no one will be able to log on locally.

---

2) Required SQL Server Roles for SharePoint Service Accounts

In SQL Server, there are two main SQL Server roles that must be assigned to specific SharePoint Service Accounts to can configure and maintain your SharePoint farm as the following:

1. dbcreator.
2. securityadmin.

Dbcreator

It’s a fixed server role to can create, alter, drop, and restore any database.

Securityadmin

It’s a fixed server role to fully manage SQL Server logins and their permissions on the server and database level.

SharePoint Service Account best practices related to SQL Server

It’s strongly recommended to install SharePoint Server by using least-privilege on the SQL Server as the following:

1. SharePoint Admin (Setup) Account will require a “dbcreator” and “securityadmin” server roles, not a sysadmin server role ONLY during the installation, update and upgrade.
2. After the SharePoint Installation and configuration process is done. Remove the assigned server roles from the SharePoint Admin (Setup) Account.
3. Only the Farm Account must have a “dbcreator” and “securityadmin” server roles.
4. Make sure that all service accounts don’t have “dbcreator” and “securityadmin” server roles except the Farm Account.
5. All SharePoint service accounts shouldn’t have the “sysadmin” role on the SQL Server even the Farm Account.
6. All SharePoint service accounts shouldn’t be a local Administrator on the server that runs SQL Server.

You may also like to read SharePoint 2019: SQL Server Recommendations

---

3) Database Roles Created by SharePoint

Besides the SQL Server roles, there’re database roles that created by SharePoint and may be assigned automatically to specific SharePoint Service Accounts.
In this section, we will briefly explore these database roles to understand its usage:

SharePoint Database Roles

1. SPDataAccess database role.
2. SharePoint_Sell_Access database role.
3. Wss_Content_Application_Pools database role.
4. SPReadOnly database role.
5. db_owner database role.

SPDataAccess

• It’s the default role for database access and it’s a replacement for the db_owner database role in SharePoint Server 2019/2016.
• You should make sure that the Application Pool accounts have the SPDataAccess role during the upgrade.

SharePoint_Sell_Access

• This role assigned to the SharePoint Setup account by default to get execute permission for all stored procedures for the database as well as read and write permissions on all of the database tables.
• If you are planning to use an account to run PowerShell cmdlets on a database, so it must have a db_owner database role or SharePoint_SHELL_ACCESS database role.
• There is no need to assign a db_owner database role for an account if it already has a SharePoint_SHELL_ACCESS database role.

You can assign a service account to SharePoint_SHELL_ACCESS using PowerShell as mentioned at The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered in SharePoint

Wss_Content_Application_Pools

• It applies to the application pool account for each web application within the farm to query and update the site map and has read-only access to other items in the configuration database.
• This role assigned automatically to the admin account for the below databases:
  • SharePoint Configuration database.
  • SharePoint Central Administration content database.
• It also used to
  • Execute permission for a subset of the stored procedures for the database.
  • Read permission to the Versions table in the SharePoint_AdminContent database.

SPReadOnly

• This role should be used to
  • Set the database as a read-only
  • Set only read access to specific data.

db_owner

• Members in this role will be able to perform all configuration and maintenance activities on the database, as well as they have permission to drop the database in SQL Server.

4) SharePoint Security Groups Created by SharePoint

In this section, we will briefly explore the Windows Security Groups created by SharePoint.

1. WSS_ADMIN_WPG.
2. WSS_WPG.
3. WSS_RESTRICTED_WPG.

WSS_ADMIN_WPG

• This group is created automatically by SharePoint to allow read and write access to the local resources like file system paths and registry keys.
• The farm account is automatically added to this security group.

WSS_WPG

• This group is also created automatically by SharePoint to allow read access to the local resources like file system paths and registry keys.
• All application pool and services accounts are automatically added to this security group.

WSS_RESTRICTED_WPG

• This group is only used for encryption and decryption of passwords that are stored in the configuration database.
• The farm account is automatically added to this security group.

5) SharePoint Farm Administrator Group

• By default, the Members of the Local Administrator Group added to the Farm Administrators Group (BUILTIN\Administrators).
• You should add an account to the Farm Administrators Group when you want to allow this account to manage the farm with lower privilege than the Farm Account.
• Members of the Farm Administrators Group don’t have the same privilege as the Farm Account.
• Members of the Farm Administrators Group have full access to all settings on the farm. however, they can’t perform all operations which require access to the SharePoint Server’s Infrastructure like Farm Account.
• Once you add an account to the SharePoint Administrators Group will be added to the local WSS_ADMIN_WPG security group on each server in the SharePoint farm.
• To allow an account in SharePoint Administrators Group control and do all operational tasks from central administration as well as from the PowerShell, you will need to add it also to:
  • Local Administrator Group.
  • Grant SharePoint_Shell_Access database role on the SharePoint configuration database and SharePoint Admin Content Database.
  • Grant db_owner database role on all content databases that hold the resources that you want to manage.

You might also like to read Local administrator privilege is required to update the Farm Administrators’ group.

6) Managed Accounts

A Managed Account is an effective domain user account whose credentials are managed by SharePoint.

The below SharePoint Service accounts should be registered as “Managed Accounts” to be managed by SharePoint.

1. SharePoint Farm Account.
2. SharePoint Web Application Pool Account.
3. SharePoint Service Application Pool Account.
4. Claims to Windows Token Service Account.

You may also like to know the non-managed account list at SharePoint 2019: Register Managed Account using PowerShell

---

Required Permissions and Roles for SharePoint Service Accounts

As we earlier mentioned, before deciding to install SharePoint Server 2019/2016/2013, you should first prepare the appropriate administrative and service accounts on SharePoint servers and SQL Server with least-privileges and each service account is granted access to only the resources that are absolutely necessary.

In this section, we’ll mainly explain the usage and the minimum required permissions that are required for the below SharePoint Service Accounts to complete authorized tasks.

1. SharePoint Setup Account.
2. SharePoint Farm Account.
3. SharePoint Farm Administrator Account.
4. Web Application Pool account.
5. SharePoint Service Application Pool account.

1) SharePoint Setup Account

The SharePoint Setup account is a domain user account that used to run the following:

• SharePoint Setup.
• SharePoint Products Configuration Wizard.

Required Permissions for SharePoint Setup account

Machine Level Permissions for SharePoint Setup Account

• It must be a domain user account.
• It must be a member of the Local Administrators Group on each SharePoint server within the farm.
• After running the SharePoint Configuration Wizard, the account will be added automatically to
  • The WSS_ADMIN_WPG windows security group.
  • Farm Administrators Group.

SQL Server Permissions for SharePoint Setup Account

• It must have access to the SharePoint databases.
• It must have the below SQL server roles during setup, configuration, and upgrade:
  • securityadmin.
  • dbcreator.
• After running the SharePoint Configuration Wizard, the db_owner database role is assigned automatically to the following databases:
  • SharePoint Configuration database.
  • SharePoint Central Administration content database.
• If you are planning to use this account to run PowerShell cmdlets on a database, so it must have a db_owner database role or SharePoint_SHELL_ACCESS database role.

For example: if you would like to perform administrative tasks on the configuration database, the account must have the SharePoint_Shell_Access role on the configuration database. again, to perform administrative tasks on a specific site collection, it must have the SharePoint_Shell_Access role on the content database that holds this site collection.)

2) SharePoint Farm Account

The farm account is a domain user account, also referred to as a database access account.

The farm account should only used to run the below services and pools:

• SharePoint Timer service.
• IIS Application Pools for Central Administration.
• SharePoint Web Services System used for the topology service.
• Security Token Service Application Pool.

The farm account is the windows account that used to connect to the configuration database during configuring the configuration database settings in the SharePoint configuration wizard.

Required Permission for Farm Account

Machine Level Permissions for Farm Account

• It must be a domain user account.
• It must not be a member of the Local Administrators Group on SharePoint servers within the farm except for some cases like starting User Profile Synchronization Service.
• After running the SharePoint Configuration Wizard, the account added automatically to
  • WSS_ADMIN_WPG Windows security group for the SharePoint Timer Service.
  • WSS_RESTRICTED_WPG for the Central Administration and Timer service application pools.
  • WSS_WPG for the Central Administration application pool.
• By default, it’s added to the SharePoint Farm Administrator Group.
• In the Local Security Policy\User Rights Assignment, it should have
  • Allow log on locally. (Optional if it will not conflict with your organization security policies)
  • Log on as a batch job.
  • Log on as a service.

SQL Server Permissions for Farm Account

• It must have the below server roles:
  • securityadmin.
  • dbcreator.
• It must have a db_owner database role on all SharePoint databases.
• It must have a SharePoint_Shell_Access role on SharePoint Configuration Database and SharePoint Admin Content Database.
• After running the SharePoint Configuration Wizard, the WSS_CONTENT_APPLICATION_POOLS role assigned automatically for this account to the SharePoint Configuration database and SharePoint Central Administration content database.

3) SharePoint Farm Administrator Account

The SharePoint Farm Administrator Account is a domain account which is a member of the Farm Administrators Group.

• By default, the Members of the Local Administrator Group added to the Farm Administrators Group (BUILTIN\Administrators).
• Once you add an account to the SharePoint Administrators Group will be added to the local WSS_ADMIN_WPG security group on each server in the SharePoint farm.
• You should add an account to the Farm Administrators Group when you want to allow this account to manage the farm with lower privilege than the Farm Account.
• Members of the Farm Administrators Group don’t have the same privilege as the Farm Account.
• Members of the Farm Administrators Group have full access to all settings on the farm. however, they can’t perform all operations which require access to the SharePoint Server’s Infrastructure like Farm Account.
• To allow an account in SharePoint Administrators Group control and do all operational tasks from central administration as well as from the PowerShell, you will need to add it also to:
  • Local Administrator Group.
  • Grant SharePoint_Shell_Access database role on the SharePoint configuration database and SharePoint Admin Content Database.
  • Grant db_owner database role on all content databases that hold the resources that you want to manage.

4) SharePoint Web Application Pool account

The SharePoint Web Application Pool account should be used for all Web Applications except for the Central Administration Application Pool that should be run by the Farm Account.

Required Permission for SharePoint Web Application Pool account

Machine Level Permissions

• It must be a domain user account.
• It must not be a member of the Farm Administrators group.
• Added automatically to the WSS_WPG security group.

SQL Server Permission

• Assigned automatically to the WSS_CONTENT_APPLICATION_POOLS for the below databases:
  • SharePoint Configuration database.
  • SharePoint Central Administration content database.
• Assigned automatically to the SPDataAccess role for the web application related content databases.

5) SharePoint Service Application Pool account

The SharePoint Service Application Pool account should be used to run all Service Applications Pool expect for the User Profile Synchronization Service.

Required Permission for SharePoint Service Application Pool account

Machine Level Permissions

• It must be a domain user account.
• It must not be a member of the Administrators group on SharePoint servers within the farm.
• Added automatically to the WSS_WPG security group.

SQL Server Permission

• It must have read and write access to the associated service application database.
• Assigned automatically to the SPDataAccess role for
  • Content databases.
  • Search database that is associated with the web application.
• Assigned automatically to the WSS_CONTENT_APPLICATION_POOLS for the below databases:
  • SharePoint Configuration database.
  • SharePoint Central Administration content database.

---

SharePoint Service Accounts List

Let’s summarize the SharePoint Service Accounts list that should be used within the SharePoint farm categorized as the following:

• SharePoint Service Accounts.
• SQL Server Service Accounts.
• Workflow Service Accounts.
• Project Server Service Accounts.

SharePoint Service Accounts

Account	Description	Machine Rights	SQL Rights
SPAdmin	The installation account that used to install and run SharePoint Configuration wizard	A member of the local Administrators group on each SharePoint server within the farm.	securityadmin, dbcreator.
SPFarm	It’s the farm account that used to run SharePoint Timer service, IIS Application Pools for Central Administration, SharePoint Web Services System used for the topology service, Security Token Service Application Pool.	Domain User, Log on as a service, Log on as a batch job	securityadmin, dbcreator.
SPSrvPool	It should be used to run all Service Applications Pool expect for the User Profile Synchronization Service.	Domain User, Log on as a service, Log on as a batch job	All SQL rights are given automatically.
SPWebPool	It’s the identity account application pool for all Web Applications.	Domain User, Log on as a service, Log on as a batch job	All SQL rights are given automatically.
SPUPS	It’s used to run the user Profile Synchronization service	Replicate Directory Changes permission	All SQL rights are given automatically.
SPCrawl	It’s a content access account for the Search Web Service.	It must not be a member of the Farm Administrators group.	All SQL rights are given automatically.
SPSearch	It’s used to run the SharePoint Search Windows Service	Domain User	All SQL rights are given automatically.
MySitePool	it’s used to run My Site application pool.	Domain User, It must be a member of the Farm Administrators group.	All SQL rights are given automatically.

To Replicate Directory Changes permission for UPS service accounts, please check Delegate User Profile Synchronization Service Account a Replicating Directory Changes in SharePoint Server

SQL Server Service Accounts

Account	Description	Rights
SQLAdmin	It’s used to install and configure SQL Server	Local Admin on all SQL Servers
SQLSrv	It’s used to run the SQL Engine Widows Service	In the Local Security Policy, it should have Log on as a service.
SQLAgent	It’s used to run the SQL Server Agent Service	In the Local Security Policy, it should have Log on as a service.

Workflow Service Accounts

Account	Description	Rights
WFAdmin	It’s used to set up and configure Workflow Manager	A member of the local Administrators group,  “dbcreator” & “securityadmin” as a server role to can create the Workflow databases.
WFSrv	It’s used to run the Workflow Manager Service	Domain User

You may also interest to read SharePoint 2016: Configure Workflow Manager

Project Server Service Accounts

Account	Description	Rights
PSWebAppPool	It’s used to run the application pool for the web application that will host the PWA site collection.	Domain User
PSSrvAppPool	It’s used to run the associated application pool with a Project Server service application.	Domain User

You may also interest to read Install and Configure Project Server 2016

---

Conclusion

In conclusion, we have explored the SharePoint recommendations and best practices for Services Accounts.

Applies To

• SharePoint 2019.
• SharePoint 2016.
• SharePoint 2013.

Reference

• Initial deployment administrative and service accounts in SharePoint Server.
• Account permissions and security settings in SharePoint Servers.
• Plan for least-privileged administration in SharePoint Server.

You may also like to read

• SharePoint 2019 Limitations.
• SharePoint 2019: SQL Server Recommendations.
• The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered in SharePoint.
• Delegate User Profile Synchronization Service Account a Replicating Directory Changes in SharePoint Server.
• Accounts used by application pools or service identities are in the local machine Administrators group in SharePoint Health Analyzer.
• Logon failure: The user has not been granted the requested logon type at this computer.

Have a Question?

If you have any related questions, please don’t hesitate to Ask it at deBUG.to Community.