Navigate Up
Sign In

SharePoint 2013 Service Accounts Best Practices Explained

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

You may also be interested in: SPTechCon 2013 - San Francisco

 

Editor's note: Contributor Vlad Catrinescu is a SharePoint Consultant. Follow him @vladcatrinescu

Several weeks ago I wrote a post about SharePoint 2013 Service accounts Best practices titled : SharePoint 2013 Service Accounts Best Practices! Is there a golden solution for all farms?. The post talked about how important Service Accounts were in the installation of SharePoint 2013 because if they are not set up correctly they can open big security holes in your organization or give you problems down the road.

The article also suggested that you cannot have only one set of Service accounts for every scenario, since not all scenarios require the same security (ex: a development environment does not require same security as the production one). So, I suggested three sets of service accounts for different deployment scenarios of SharePoint 2013, however I got some feedback that my choices and the accounts weren't explained in detail.

This post will go over all the three sets of service accounts, explaining the difference between the sets and also what every account does!

NOTE: These sets only cover the basic installation and configuration of SharePoint 2013 and SQL. Other Service accounts will be needed for some Service Applications (Ex: Excel, Visio, Performance Point, etc)

Low Security Option

Summary

The Low security option is of course the one with the least accounts possible to install SharePoint in a proper manner. It uses only one SQL account that will be the SQL administrator and also run the services, and 5 SharePoint accounts: The Farm Administrator, the Web Application pool account, the SharePoint Service Application Pool account, the Crawl account and the User Profile Synchronization account. More details under each section

For the SQL Server

Name Description Local Rights Domain Rights
SQL_Admin The SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. SQL Admin on the SQL Server Local Administrator on the SQL Server Domain User


Explanation

As Stated previously, in the Low Security Option, we only use one Service Account for our SQL Server. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. We will also run the SQL AGENT and the Database Engine services with this account. This is the account that will have the full power on your SQL server and you will use it to grant rights to your SP_Farm (more details to follow)

For the SharePoint Server

Name Description Local Rights Domain Rights
SP_Farm The server farm account is used to perform the following tasks:
-Setup
-SharePoint Products Configuration Wizard
-Configure and manage the server farm.
-Act as the application pool identity for the SharePoint Central Administration Web site.
-Run the Microsoft SharePoint Foundation Workflow Timer Service.
Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL Instance Domain User
SP_Pool The Pool account is used to run the Web Application Pools None Domain User
SP_Services The Services Account is used to run the Service Application Pool None Domain User
SP_Crawl The Default Content Access Account for the Search Service Application None Domain User
SP_UserProfiles The User Profile Synchronization Account None Replicate Directory Changes permission on the domain. Guide: http://bit.ly/TSE7xs


Explanation

The Low Security Option uses the minimum amount of accounts while also keeping a level of security. Here is the account breakdown:

SP_Farm is your main SharePoint account in this configuration. It needs to have Local Administrator rights to be able to install SharePoint Server and also the Securityadmin and DBcreator roles on the SQL Server to create the configuration and other databases. This account will be your main Farm Administrator and also run the Timer Service and the web application for Central Administration use to access the SharePoint content database

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

P_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications. It will also run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization

Medium Security Option (Sweet Spot)

Summary

The Medium Security option is the Sweet Spot of a SharePoint installation. It uses slightly more accounts than the Low Security Option however it provides a huge security improvement. By giving less rights to each account you limit the possible damage in case an account gets hacked and also follow Microsoft's recommendation of installing SharePoint 2013 with least-privilege administration. More details on the changes under every section!

For the SQL Server

Name Description Local Rights Domain Rights
SQL_Admin SQL Admin on the SQL Server. Used to Install the SQL Server. Local Administrator on the SQL Server Domain User
SQL_Services It is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. None Domain User


Explanation

The difference between the Low Security and the Medium Security option for the SQL is that we now use two different accounts :The SQL_Admin and the SQL_Services. The big security improvement is that the account running the Agent and Database Engine services is not a local administrator anymore. Here is the account breakdown:

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Services: This account does not have any local rights, it is only used to run the SQL Agent and Database Engine windows services.

For the SharePoint Server

Name Description Local Rights Domain Rights
SP_Farm The server farm account is used to perform the following tasks:
-Configure and manage the server farm.
-Act as the application pool identity for the SharePoint Central Administration Web site.
-Run the Microsoft SharePoint Foundation Workflow Timer Service.
SecurityAdmin and DB_Creator rights on the SQL Instance Domain User
SP_Admin The server farm account is used to perform the following tasks:
-Setup
-SharePoint Products Configuration Wizard
Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL Instance Domain User
SP_Pool The Pool account is used to run the Web Application Pools None Domain User
SP_Services The Services Account is used to run the Service Application Pool None Domain User
SP_Crawl The Default Content Access Account for the Search Service Application None Domain User
SP_Search Service Account to run the SharePoint Search “Windows Service” None Domain User
SP_UserProfiles The User Profile Synchronization Account None Replicate Directory Changes permission on the domain. Guide: http://bit.ly/TSE7xs


Explanation

In the Medium Security option we increase the security by adding two new accounts: The SP_Admin and the SP_Search. Instead of giving all the Farm Administration power to the SP_Farm account, the SP_Admin will be the one that installs and configures SharePoint 2013 and have the local administrator rights, while the SP_Farm will only run the services and connect to the database. Furthermore, instead of letting the SP_Crawl account run both the Windows Service and have FULL-READ rights on all the web applications, the SP_Search will now run the Windows Service. Here is the breakdown of the accounts:

SP_Farm is a domain account that the SharePoint Timer service and the web application for Central Administration use to access the SharePoint content database. This account does not need to be a local administrator. The SharePoint configuration wizard grants the proper minimal privilege in the back-end SQL Server database.The minimum SQL Server privilege configuration is membership in the roles securityadmin and dbcreator.

SP_admin is a domain account you use to install and configure the farm. It is the account used to run the SharePoint Configuration Wizard for SharePoint 2013.The SPAdmin account is the only account that requires local Administrator rights. To configure the SPAdmin account in a minimum privilege scenario, it should be a member of the roles securityadmin and dbcreator on the SQL server.

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

SP_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications.

SP_Search Is used to run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization.

High Security Option

Summary

The High Security Option is the ones that provides the best security and of course the most Service Accounts. This only ads a small amount of extra security to the farm, however that extra security might be needed in some scenarios

For the SQL Server

Name Description Local Rights Domain Rights
SQL_Admin SQL Admin on the SQL Server. Used to Install the SQL Server. Local Administrator on the SQL Server Domain User
SQL_AGENT It is the service account for the following SQL Server services: SQL SERVER AGENT. None Domain User
SQL_ENGINE It is the service account for the following SQL Server services: Database Engine. None Domain User


Explanation

The difference between the Medium Security and High Security Option is that we now have a separate account for each of the two base services: SQL_Agent and Database Engine. Nothing changes for the SQL_Admin

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Agent: This account does not have any local rights, it is only used to run the SQL Agent Windows Service

SQL_Engine: This account does not have any local rights, it is only used to run the Database Engine windows service.

For the SharePoint Server

Name Description Local Rights Domain Rights
SP_Farm The server farm account is used to perform the following tasks:
-Configure and manage the server farm.
-Act as the application pool identity for the SharePoint Central Administration Web site.
-Run the Microsoft SharePoint Foundation Workflow Timer Service.
SecurityAdmin and DB_Creator rights on the SQL Instance Domain User
SP_Admin The server farm account is used to perform the following tasks:
-Setup
-SharePoint Products Configuration Wizard
Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL Instance Domain User
SP_Pool The Pool account is used to run the Web Application Pools None Domain User
SP_Services The Services Account is used to run the Service Application Pool None Domain User
SP_Crawl The Default Content Access Account for the Search Service Application None Domain User
SP_Search Service Account to run the SharePoint Search “Windows Service” None Domain User
Sp_MySitePool Used for the My Sites Web Application None Domain User
SP_UserProfiles The User Profile Synchronization Account None Replicate Directory Changes permission on the domain. Guide: http://bit.ly/TSE7xs


Explanation

The only difference between the Medium security and the High Security option is that we now have a separate account for the Web Application Pool hosting the 'My Sites' since it has a different security policy than the other Web Applications . I will only give the details for the new account in the breakdown:

SP_MySitePool is a domain account used for the My Sites Web Application Pool Identity. It's very similar to the SP_Pool, however it is only used for the My Sites Web Application.

Sources

http://technet.microsoft.com/en-us/library/ee662513.aspx
http://technet.microsoft.com/en-us/library/cc678863.aspx

Download

You can download all the information here in PDF format on my SkyDrive here: http://sdrv.ms/U6hvuU

I think that this post gives all the information necessary for SharePoint 2013 Service Accounts for the years to come, and don't forget that this post only covers the basic Service Accounts needed for SharePoint 2013 and that other Service Accounts will be needed for some Service Application (ex: Excel Unattended Service, Visio, etc )

If you have any questions or comments please do not hesitate to post a comment, because your opinions will only make this post better!

Categories: SPF 2013; SQL; Security

Comments

Vardhaman Deshpande

Sandbox Service

Hello Vlad, Great post with lots of details! I have almost the same setup as you mentioned in the Medium Level Security configuration. However, the Sandbox service always ends up giving me trouble. Looks like the Sandbox Service Account requires to have db_creator rights on the SQL instance as well. Otherwise, sandbox visual web parts stop working entirely. The ULS logs also confirm this. Have you had any experience configuring the sandbox service? Could you advice on this issue please?

Posted 19-Jan-2013 by Vardhaman Deshpande
Vlad Catrinescu

Sandbox Service

Hi, By default, the Sandbox Service runs with the farm account, therefore having full permissions. I already had some strange behaviors with SharePoint (who didn't ?) and with the Sandbox service. The problem I had was that when I was activating some solutions, I had the famous "unknown error" and I fixed it by giving the Sandbox Service account full control on the Web App and taking it off right away. Can you tell me what error you get in the ULS? I will try and replicate it!

Posted 23-Jan-2013 by Vlad Catrinescu
Vardhaman Deshpande

Possible Fix

Looks like I have a possible fix for this. I ran the Sandbox service with a dedicated account (sp_sandbox) and added that account the Domain Admins AD group. The process started working fine after that. Note: If you are using SP 2013, you cannot have code in your sandbox solution if you have a Domain Controller on the same machine as your SharePoint. The workaround for this is to setup a different machine to act as a Domain Controller.

Posted 21-Feb-2013 by Vardhaman Deshpande
Derek WIldstar

Use sp_farm for SP install?

When using the High Security Option, would you use the SP_Farm account during SP install on the step to create a configuration database in a new server farm?

Posted 27-Feb-2013 by Derek WIldstar
Senthamil

Senthamil

Ultimate article, very clear very useful. I just copy paste into my Org user creation request and it worked. Great.

Posted 15-Apr-2013 by Senthamil
Unkz

Not the complete picture

Although this article is good general guidance, there are few things missing in my opinion.
1. Object cache super reader and object cache super user accounts. Worth to consider in some scenarios.
2. Workflow service account – if you deploy new workflow service bus and workflow manager. You can also consider to use one of the existing accounts.
3. Distributed Cache service account – by default this service run on farm account which I think is not the best option in High Security Option (I assume, that we don’t want services to run on farm account if possible).
4. Claims to Windows token service (C2WTS) account – if you plan to use and deploy this service. I guess can be worth to consider in High Security Option.
5. Secure Store service account – useful at least in High Security Option.
6. And last, but not least – Access Services account which have to be farm account if you don’t want to manually set couple of access privileges to SharePoint’s databases – especially farm configuration database. It impacts also assigning high access privileges to SQL Server instance storing Access Services databases.
Obviously this is not the end of story if you consider integration of SQL Server Reporting Services, SQL Server Analysis services etc.

Posted 15-May-2013 by Unkz
Reuben

Setting SP_Farm

I haven't has much luck in setting SP_Farm as being the Farm Account, with or without it being a member of the local administrators group.

Posted 29-May-2013 by Reuben
Trevor

Why does nobody use these accounts for install demonstrations?

1) Not your fault: but it is really irritating to have "best practice" guides and then have step-by-step install demos that violate all the "best practices". Where is there an install guide for the 3-Tier Farm that actually sets up the accounts properly?
 
2) It is not clear in any way how these accounts get used. A Best practice would be the Wizard having all the account names right at step 1 and actually have SharePoint use them.
 
3) You mention things like "The Application Service Pool" account. There is not just one. There is the security token service pool, the web services default, and the Web services system pools.
 
4) Again, you are just helping, its not your fault, but seriously... this would be NOTHING if the demoes followed best practice guides and if the installation process didn't violate best practices on the very first click.
 
It is way to easy to accidentally use the wrong account and/or just simply be a victim of following one the many step-by-step guides. I really do want a guide that follows best practice to setup SharePoint "right" and have the correct account be used properly. Is there a good guide anywhere?

Posted 14-Jun-2013 by Trevor
Steve

farm account

My only comment is MS recommends a separate account for installing (with basically full admin rights to everything) and that the farm account should only be a server admin during UPS provisioning.

Posted 19-Feb-2014 by Steve
steve

farm account

Never mind my comment about the separate account for installing, I see you have it in there (SP_Admin)

Posted 19-Feb-2014 by steve

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: