theme-sticky-logo-alt
theme-logo-alt

SharePoint 2013 Service Accounts Best Practices Explained

January 7, 2013
by Vlad Catrinescu
126 Comments

Several weeks ago I did 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: This 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)

NOTE: For SharePoint 2016, check out this blog post: https://vladtalkstech.com/2017/03/sharepoint-2016-service-accounts-recommendations.html 

SharePoint 2013 Service Accounts – 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 1 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

NameDescriptionLocal RightsDomain Rights
SQL_AdminThe 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 ServerLocal Administrator on the SQL ServerDomain 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 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

NameDescriptionLocal RightsDomain Rights
SP_FarmThe 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 InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate 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!

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

SharePoint 2013 Service Accounts – 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

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_ServicesIt is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT.NoneDomain 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

NameDescriptionLocal RightsDomain Rights
SP_FarmThe 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 InstanceDomain User
SP_AdminThe 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 InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate 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.

SharePoint 2013 Service Accounts – 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

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_AGENTIt is the service account for the following SQL Server services: SQL SERVER AGENT.NoneDomain User
SQL_ENGINEIt is the service account for the following SQL Server services: Database Engine.NoneDomain 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

NameDescriptionLocal RightsDomain Rights
SP_FarmThe 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 InstanceDomain User
SP_AdminThe 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 InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
Sp_MySitePoolUsed for the My Sites Web ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate 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/cc678863.aspx

Edit (19/08/2013):

The SP_Farm account needs to be in the Local Administrators during, and only during the User Profile Provisioning!

Also, you can create those Service Accounts automatically with PowerShell using the SharePoint 2013 Service Account Creator project on CodePlex: https://sp2013serviceaccount.codeplex.com/

Download

You can download all the information here in PDF format on my SkyDrive here: http://1drv.ms/1p6tLcv 

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!

Leave a comment and don’t forget to like the Vlad Talks Tech 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.
SharePoint Server
Previous Post
Some Interesting Events this week
Next Post
Free SharePoint Server 2013 Resources Part 3

126 Comments

  • January 11, 2013 at 8:26 pm
    Sean O’Leary

    Security is a huge thing to consider in your SharePoint environment. It’s necessary that each user have the proper amount of access. Too much or too little can cause frustration, headaches, and errors.

    Reply
  • February 4, 2013 at 7:46 pm
    Anonymous

    Good post

    Reply
  • March 1, 2013 at 3:55 pm
    Derek Wildstar

    In Medium and High Security options, SP_Farm does not have local Admin permissions, yet runs the SP Timer service. If not a local Admin, what permissions does it need to run SP Timer service?

    Reply
    • March 1, 2013 at 7:10 pm
      Vlad Catrinescu

      Hi Derek,

      That is a very good question a lot of people don’t know the answer!. The SP_Farm account does not need Local Administrator Permissions to run the Sp Timer service. When you set it up as the “database connection account” he gets all the rights he needs. It is further documented here: http://technet.microsoft.com/en-ca/library/ee662513.aspx You can see that the Setup User Account is a member of the Local Administrator Group, but not the Farm Account.

      If you have any other questions, don’t hesitate!

      Reply
    • March 1, 2013 at 7:50 pm
      Vlad Catrinescu

      However, I will have to add that it’s strongly recommended to add the sp_farm account in local admins during UPS provisioning!

      Reply
  • March 7, 2013 at 9:48 am
    Stephen

    Hi Vlad, great post thanks. I’m having an odd issue though. I have the SP_Admin account as a member of the admin group on all servers which is fine, I access CA with the SP_Farm account and all is good until i try to look at the services on server section of CA in which case i get permission denied error. The only way i can view these sections as SP_Farm is if i add that account as a member of the admin group ONLY on the server that CA is installed.

    This doesn’t seems like normal behavior, have you seen this before?

    Reply
    • March 12, 2013 at 12:52 am
      Vlad Catrinescu

      Hi, no this is not really normal!. I did some tests but it worked, however I will do more tests these days. Hopefully I can replicate it

      Reply
    • March 12, 2013 at 12:54 am
      Vlad Catrinescu

      Have an idea!, how to you get to the central administration? do you go trough the Central Admin shortcut, or trough IE directly? You might have this problem because if your Internet Explorer is not “run as admin”

      Reply
    • March 13, 2013 at 12:21 pm
      Stephen

      Hey Vlad, thanks for getting back to me. I access CA through a host header on my own machine to the server. I’m using chrome at the moment too, I’ve tried in IE but I get the same results if the Farm account is not in the local administrator group. For some reason though I can’t login into CA on the server using the farm account, i have to login using the Admin account if the farm account is not in the local admin group.

      Reply
  • March 8, 2013 at 10:27 am
    SharePoint Perth

    Well Written Post..Thanks for sharing..!!

    Reply
  • March 16, 2013 at 11:12 am
    Francis Navarro

    There are mainly two accounts available that is administrative and service accounts on servers running SharePoint 2013 and SQL Server which used to to modify and maintain the environment.

    Reply
  • March 20, 2013 at 5:39 pm
    Suresh Pydi

    This comment has been removed by a blog administrator.

    Reply
  • March 20, 2013 at 11:33 pm
    Kaigh Taylor

    If I have a sharepoint.config db how do I add the SP_Service to the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. If I didn’t set it up that way initially?

    Reply
  • March 28, 2013 at 12:16 pm
    Remco

    Thanks, but i just read a whitepaper about SQL Server 2012 Security best practices from Microsoft and they say Best Practices for SQL Server service accounts: On Windows 2008 R2 use managed Services Service accounts and virtual server accounts. Virtual accounts are default during installation and i think there is not a reason to not use them. They are even able to access the network, at least the Virtual account can. You don’t have to create them yourself, they don’t have a manageable/abusive-able password so to me that seems a win-win. Although i really appreciate your posting because I am a new to Sharepoint and SQL. Could someone please tell me if i am right ?

    Reply
  • April 4, 2013 at 9:18 am
    Ian Addis

    Please can you expand your very useful article to include recommendations for the following service accounts:
    * Windows Service – Claims to Windows Token Service
    * Windows Service – Distributed Cache
    * Windows Service – Microsoft SharePoint Foundation Sandboxed Code Service
    * Service Application Pool – Security Token Service Application Pool
    * Service Application Pool – SharePoint Web Services System

    I’ve found no instructions on the net to explain what credentials they should use. Some say not C2WTS MUST run as Local System, yet SharePoint complains if you do so. MS article explains that Distributed Cache runs as the farm account, yet SharePoint complains if it does!

    Reply
    • April 30, 2013 at 2:19 pm
      Vlad Catrinescu

      Claims to Windows Token Service > SP_Services or Dedicated account for it.
      Distributed Cache > Sp_Services
      Microsoft SharePoint Foundation Sandboxed Code Service > SP_Farm
      Security Token Service Application Pool> Sp_Farm
      Service Application Pool – SharePoint Web Services System > Sp_Farm

      Reply
      • May 7, 2015 at 6:50 am
        Brian Christie

        Vlad,

        I think your article is great however I would like to see more detail on the individual accounts’ database permissions and accounts used to run Windows services. For instance having just moved a content database from a SQL Express instance on the SharePoint server to a dedicated production SQL Server I am finding it hard to determine which accounts should be given access to things like SPDataAccess, SPSearchDBAdmin, SharePoint_Shell_Access and WSS_Content_Application_Pools schema objects.

        Would it be possible for you to create a table containing all user mappings? Also a small table with Windows Service accounts – I am trying to determine which service account the SharePoint Administration service should run as.

        Many thanks for the great article – saved my bacon!

        Brian

      • July 14, 2015 at 2:59 pm
        Vlad Catrinescu

        Creating that table is a lot of work, I will try to do it before end of summer :). Usually when you migrate databases, your DBA should also migrate individual permissions. The SP Administration should run as SP_Farm :).

  • April 18, 2013 at 7:34 am
    Sebastian James Harani

    This comment has been removed by a blog administrator.

    Reply
  • April 26, 2013 at 8:25 am
    jbwdevos

    I have the same question as +Ian Addis. Can you please explain?

    Reply
    • April 30, 2013 at 2:18 pm
      Vlad Catrinescu

      Claims to Windows Token Service > SP_Services or Dedicated account for it.
      Distributed Cache > Sp_Services
      Microsoft SharePoint Foundation Sandboxed Code Service > SP_Farm
      Security Token Service Application Pool> Sp_Farm
      Service Application Pool – SharePoint Web Services System > Sp_Farm

      Reply
  • April 27, 2013 at 3:22 am
    sharepoint

    Hello Vlad, great blog article. there is one small deteail missing an that is the KERBEROS and claims connection to the service account like the SQL service account and its delegation settings. this piece like its kin in the sharepoint side, is very important to a well configured sharepoint farm.

    all in all a great article, thank you for sharing

    LCR

    Reply
  • April 28, 2013 at 9:47 am
    Osama Mosleh Mohamad

    I have the same question as jbwdevos and Ian Addis.

    Can You provide us some more explaination?

    Reply
    • April 30, 2013 at 2:18 pm
      Vlad Catrinescu

      Claims to Windows Token Service > SP_Services or Dedicated account for it.
      Distributed Cache > Sp_Services
      Microsoft SharePoint Foundation Sandboxed Code Service > SP_Farm
      Security Token Service Application Pool> Sp_Farm
      Service Application Pool – SharePoint Web Services System > Sp_Farm

      Reply
  • May 2, 2013 at 12:18 pm
    Anonymous

    Great post and informative article. After reviewing the PowerShell script files, all accounts are created under one OU. Is there a way via the script to separate the SQL Accounts created into a separate OU container from the SP Accounts?

    Reply
  • May 2, 2013 at 1:53 pm
    Gary Hagan

    OK, everything makes sense so far. Are all these local computer accounts, or Domain accounts?

    Reply
    • May 2, 2013 at 2:01 pm
      Vlad Catrinescu

      SharePoint should only be installed in a domain, so they are all domain accounts!

      Reply
  • May 7, 2013 at 8:14 pm
    Chris

    Great Post. Wish I saw it earlier. I have been trying to figure out why the SharePoint Health Analyzer was complaining about “Accounts used by application pools or service identities are in the local machine Administrators group” now I know. neded up with a medium low security level.

    Reply
  • May 28, 2013 at 6:16 am
    Andrew

    Vlad, thank you very much for the information! I found it very usefull

    Reply
  • June 18, 2013 at 11:51 am
    YardleyBarnett

    Nice posting. The Low protection choice is of course the one with the least records possible to set up SharePoint in a appropriate way. It uses only 1 S Q L consideration that will be the S Q L manager and also run the solutions, and 5 SharePoint accounts

    Reply
  • June 21, 2013 at 12:47 pm
    Joseph Stokes

    All of this security option all explained perfectly in this post, And works wonder for any SharePoint development work.

    Reply
  • July 14, 2013 at 3:18 pm
    Hayden

    Thank you for this article. However, I’ve noticed that I couldn’t start the User Profile Synchronization Service unless the SP_Farm was a member of the local administrators group. This doesn’t sound like a best practice to me. What is the easiest way to fix this?

    Reply
    • July 14, 2013 at 3:21 pm
      Vlad Catrinescu

      Hello,

      You are completely right and I will update my article. The SP_Farm will need to be local admin ONLY during the provisioning of the User Profile Synchronization Service.

      Thanks,

      Reply
  • July 26, 2013 at 12:32 pm
    Thomas Case

    You separate out Mysites to seperate App Pool account, but not other content. I would think it would be more important to seperate out Internet sites content from Intranet sites content. What would be the rationale for not having a seperate App Pool for Internet content running under different user?

    Reply
    • July 27, 2013 at 2:23 pm
      Vlad Catrinescu

      Hello Thomas,

      Of course you can run every Web Application with a different service account, however I don’t really see it as being worth in terms of Efforts vs Security enhanced.

      The reason I have put MySites and the Content AppPools with different accounts is to follow the Microsoft Requirements. http://technet.microsoft.com/en-us/library/cc678863.aspx

      Reply
  • July 29, 2013 at 10:09 am
    Vince

    Thanks for the article. It all seems straight forward, but I think I’m missing a point somewhere.
    For example, I created the sp_farm account in AD and gave it Domain User rights. From SP Security> Service Accounts, selecting Farm Account and selecting the Service Account sp_farm is accepted, but then the Admin Web site does not start or stay started. It appears that the site collections are functional.

    The problem might be that the “sp_farm” account must be a Domain Users account and “Local Admin”. I added added sp_farm to local admins account, but I’m unsure what else to do. Any suggestions?

    Thanks

    Vince

    Reply
    • August 19, 2013 at 10:53 pm
      Vlad Catrinescu

      Once you installed SharePoint it’s a bit of a mess changing the timer account. I would say add it as Local Admin when doing the switch and do an IISRESET right after. Furthermore, make sure you change the FIM and FIM synchronization service aswell.

      Honestly, if your UserProfile is synchronized, it might be a real mess changing the farm account.

      Reply
      • March 4, 2014 at 12:06 pm
        Benjamin

        Hi @all,

        pls don’t change the Service account for the FIM service. When doing this, the services won’t start anymore.
        After running the config wizard, the farm account is hardly used for the user profile sync services and can’t be changed afterwards.

        Kind regards,
        Benjamin

      • December 22, 2014 at 1:57 pm
        RIch

        Hi Benjamin,
        You say “After running the config wizard, the farm account is hardly used for the user profile sync services and can’t be changed afterwards.” Are you saying that the Farm Account should not be added to the local administrators group on the box running the synch service when configuring the synch service? It appears that folks are saying this is the only way they get it working. I just want to be sure I understand this since UPS in 2010 was such a difficult service to get right.
        Thanks!

  • August 9, 2013 at 8:39 am
    Valdas

    Hi,
    I have a question about User profile synchronization account. In this blog you mention that this account does not need any local permissions. Yet here (http://blogs.technet.com/b/meamcs/archive/2013/02/18/sharepoint-2010-2013-user-profile-synchronization.aspx) it says that you need to have Local Administrator permissions to be able to start it. Further more it says that the account you’ll use is the same as sharepoint timer account aka sp_farm which based on your does not have Local Administrator permissions. Does that mean I have to grant those permissions to farm account, then after the service is up and running I have to change service account and remove sp_farm from Administrators group? Or is there an easier approach?

    Reply
    • August 19, 2013 at 10:54 pm
      Vlad Catrinescu

      Hello Valdas, you are completely right and I will change the blog post. SP_Farm DOES need Local Admin rights during USPS provisioning!

      After that, you can take it out of the local admin group!

      Reply
      • August 27, 2013 at 6:21 pm
        Kris Croaker

        In SharePoint 2010 the user profile synchronisation job was stopped when you did a full farm backup and then re-provisioned afterwards, If the Farm account wasn’t a local admin when you did the full farm backup the user profile sync wouldn’t re-provision properly.

        Do you know if the behaviour with the full farm backup is still the case for SharePoint 2013?

      • December 22, 2014 at 2:01 pm
        RIch

        Hi Kris,
        Have you gotten any resolution to your question? This would be handy knowing as I move into SP 2013!

        Thanks!

  • October 8, 2013 at 9:57 pm
    John

    Hi Vlad, thanks for your site. I’ve solved many problems with sp using your information.

    John.

    Reply
  • October 10, 2013 at 7:23 pm
    Arnstein Fuglemsmo

    I have a question regarding service accounts and best practices about which of this can be a “Managed Account” with “Automatic Password Change” in SharePoint 2013 ?
    My best practice have been to not make the “Farm Account/System Account” a Managed Account because I sometime need to use this account for spesific tasks, for example in some situations i need to logon to the server for provision User Profile Sync Service.

    -Arnstein

    Reply
  • October 26, 2013 at 7:17 pm
    Edwin

    Hi, just to clarify things. Are the names indicated in the first column are users that must be created in the local machines and Active Directory?

    Reply
  • November 1, 2013 at 10:23 am
    Step

    Vlad, is there a reason to create a dedicated SP_Admin account, or can the setup and config be done by regular accounts of IT staff (they have local admin permissions for all servers)? Specifically – could anything bad happen if the account who did original setup is deleted later? Thanks Step.

    Reply
    • November 7, 2013 at 10:14 am
      Vlad Catrinescu

      Hey,

      It’s always good to have a dedicated account just in case people leave…. . Nothing will happen if you delete the install account later on.

      Reply
    • February 20, 2014 at 10:44 am
      Steve

      I had the same thought about the SP_Admin account. If someone leaves the company, the password for the account would have to be changed immediately (since all admins would know it). I think I would prefer a security group with all the admins in it. Is that a viable option?

      Reply
      • February 28, 2014 at 1:29 am
        Vlad Catrinescu

        Yes it’s a viable option, however you will have to make sure you add-spshelladmin with every new user in the group!

  • November 25, 2013 at 9:39 am
    Anthony DiFranco

    Great material. I will add this to my blog for reference.

    Reply
  • January 14, 2014 at 11:04 am
    Marlene

    Great article, but I cannot seem to find any information about fixing a security mess after the fact. I have a single service farm account which is being used for other services. I would like to change this, but can I do it without breaking things?
    Here is the error i am getting from the health checker:
    the account used for the SharePoint timer service and the central administration site, is highly privileged and should not be used for any other services on any machines in the server farm. The following services were found to use this account: SharePoint – 5000 (Application Pool)
    SharePoint – 80 (Application Pool)
    OSearch15(Windows Service)
    Distributed Cache Service(Windows Service)
    SPSearchHostController(Windows Service)

    Reply
    • February 6, 2014 at 1:12 pm
      Vlad Catrinescu

      You would mostly have to do it in Central Admin > Security > Configure Service accounts and change them there! Don’t forget to add them as managed accounts before!

      Reply
    • October 31, 2014 at 4:58 pm
      gregory davis

      I have the same problem. Can I use your script to fix my accounts after the fact or do i have to use central admin?

      Reply
      • November 22, 2014 at 10:25 am
        Vlad Catrinescu

        You need to use Central Admin.

      • December 22, 2014 at 3:37 pm
        gregory davis

        I went in and configured all the accounts in CA but now I get an application error when I try to access my site collections.

      • December 28, 2014 at 10:28 am
        gregory davis

        1. I am configuring sharepoint Foundations on WHS2011. I know that WHS is unsupported, but it works for me and I have been able to get sharepoint 2013 working fine except for app installation which seems to be a problem with the service account setup. I was able to configure all of the service accounts in CA except the SQL_Admin and SQL_Services accounts. Also, how is the use of your method impacted by the fact that Foundations does not have the user privilege subscription service? Please give me some help with this.

        2. here is the error I am getting when I try to access my host-named site collections after configuring the service accounts:

        Server Error in ‘/’ Application.

        Runtime Error
        Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

        Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a “web.config” configuration file located in the root directory of the current web application. This tag should then have its “mode” attribute set to “Off”.

        Notes: The current error page you are seeing can be replaced by a custom error page by modifying the “defaultRedirect” attribute of the application’s configuration tag to point to a custom error page URL.

      • December 28, 2014 at 10:32 am
        gregory davis

        Notes: The current error page you are seeing can be replaced by a custom error page by modifying the “defaultRedirect” attribute of the application’s configuration tag to point to a custom error page URL.

      • December 28, 2014 at 10:36 am
        gregory davis

        I’m trying to post the error:

      • December 29, 2014 at 7:03 pm
        gregory davis

        Here is the error. Please help. I have tried everything but can’t recover my site collections. I am at the point of reinstalling sharepoint foundations and starting over:

  • February 1, 2014 at 7:38 am
    Tarcísio Corte

    I made a great SharePoint 2013 with this tips….and It was very cool.
    Thanks!!!

    Reply
  • February 7, 2014 at 4:27 am
    Vamsi

    Hi Vlad,

    I have a conceren about the user profile synchronization service – as you mentioned that, the account doesn’t required local system admin rights & which is absolutely worng. Because, as per the article http://www.harbar.net/archive/2010/10/30/avoiding-the-default-schema-issue-when-creating-the-user-profile.aspx the account should be a part of local admin group. Otherwise, we can’t start user profile synchronization service.

    Reply
    • February 7, 2014 at 3:17 pm
      Vlad Catrinescu

      Hello,

      The user profile synchronization account does not require local administration rights. The only account that needs local admin rights is the “Farm Account” and only during provisioning. And that’s in the article: “The SP_Farm account needs to be in the Local Administrators during, and only during the User Profile Provisioning!”

      So, it’s absolutely right!

      Reply
  • March 4, 2014 at 12:26 pm
    Tracy

    Excellent, realistic presentation. I teach SharePoint administration and give my students a link to this blog.

    Reply
  • March 11, 2014 at 12:10 pm
    Kameron

    Great post!

    Reply
  • March 13, 2014 at 2:21 am
    Skrel

    Great article!
    A question that suddenly pops into my mind is whether SharePoint 2013 could properly work on a SQL Server 2012 with the contained database option enabled?
    Any thoughts?

    Thanks.

    Reply
  • April 7, 2014 at 7:16 am
    Assos

    This is really a GREAT POST!
    I would like to ask you to make another post on the available ways that an administrator have to change the service accounts after SPS Installation.
    Ex. During installation SQL Server runs with “DOMAIN\SQL_User” and by mistake I also set as farm administrator the same user “DOMAIN\SQL_User”.

    In general how easy is to change the services accounts? What are the possible dangers?

    Reply
  • June 29, 2014 at 11:56 am
    Devin McMahon

    Great post, helped me immensely, however I am noticing that for the configuration you describe, where the Farm account is used to run Central Admin and Timer service, the Health Analyzer continues to complain that you are using a highly privileged account to run those services, even though if you change them to any other account, things begin failing.. Is this a bug in the Health Analyzer? I would like to have a clean Health Check for this brand new farm. Will I have to shut this check off? Thanks

    Reply
    • July 21, 2014 at 9:54 pm
      Vlad Catrinescu

      Can you copy the exact error code and I will be able to better help you!

      Thanks!

      Reply
  • August 6, 2014 at 6:11 am
    Hemant

    Excellent Post. Thank you very much.

    Reply
  • August 29, 2014 at 7:18 pm
    Anon

    When do you provision the services / service applications? While running the configuration wizard (under SP Admin account) or after changing the farm account from SP Admin to SP Farm? We are noticing that when you change the account from SP Admin to SP farm using the ‘configure service accounts’ under CA, the SP Farm account doesn’t get access to Search Service Databases.

    Reply
    • September 25, 2014 at 12:54 am
      Vlad Catrinescu

      I always provision the Service Applications with the SP_Admin account. You’re not suppose to change “farm admin accounts”! You configure everything while logged in as admin, but you tell SP to use the SP_Farm as the timer job account!

      Reply
      • October 25, 2014 at 8:57 pm
        greg davis

        I have a standalone install of SP2013. When I log in with my account to my web site, it displays as “System Account” which is a problem with app deployment. I believe I’m having this problem because I used my account as a managed account to setup all the services required for apps (application service, subscription service, sharepoint store, etc.). I want to use your “medium” option to redo my account configuration to fix this problem. A couple of questions:

        1. I assume I can redo everything in central admin. Do I use the exect account names in the table?

        2. I don’t believe I have active directory. I am installed on Windows Home Server 2011. If these must be domain accounts I have to create them there. Is that a problem?

      • January 26, 2015 at 7:07 pm
        Vlad Catrinescu

        1- You don’t have to use the same names, you have to create them according to your company naming policy!
        2 – Honestly no idea… I didn’t even knew Home Server 2011 was supported , so can’t help you on this one.
        Thanks!

      • December 22, 2014 at 2:07 pm
        RIch

        HI Vlad,

        Thanks for putting this piece together. It really helps you wrap your head around a detailed process! Can you provide some guidance on what managed accounts should use the automatic password change feature? My thought is only the Setup account should be a manual password change since this would need to be used when an admin logs in to configure services.

        Thank you!

      • December 29, 2014 at 10:46 am
        Vlad Catrinescu

        Hello,

        The password change policy will depend on your business policies. Some business change them every 30 days while some never change them. Be careful as only the “managed accounts” (App Pool, Service App Pool, Farm) are required in managed accounts and will automatically change passwords. The crawl account for example is “hard coded” and you have to change the password manually.

      • December 31, 2014 at 10:28 am
        RIch

        Thanks Vlad! I hadn’t known that about the Crawl account. Good lookin’ out yo!

  • October 27, 2014 at 8:20 pm
    Greg Davis

    I have a standalone install of SP Foundations 2013 on WHS2011. I want to use your “mediaum” method to reconfigure my service accounts. A couple of questions:

    1. My sharepoint install is fully installed and working. I am using your method because I have had some problems that point to incorrect account setup. Is it ok to ru the script after the fact? I don’t want to start from scratch becuas eit took me a long tim eto ge to this point

    2. Does the script create the domain user accounts or do I have to do that separately? If separately, do I do it before or after running the script

    3. How does your method change for Foundations? Do I need to run the SQL setup also since I only have SQL express?

    Reply
    • January 26, 2015 at 7:05 pm
      Vlad Catrinescu

      Heym quite a lot of questions.
      1- The script on codeplex only creates the accounts on the active directory. you still need to modify them in the SharePoint managed accounts.
      2 – ^
      3- Foundation = less accounts! for SQL it will depend if you need to go for full.. if you need the full version you will have to reinstall + migrate databases!

      Reply
  • December 8, 2014 at 3:51 pm
    sara lawson

    I know how to make a service account a Local Administrator on all the SharePoint Servers.
    But how do I give that same account SecurityAdmin and DB_Creator rights on the SQL Instance if I am not the DBA? What do I need to do or tell the DBA to do?

    Great article, by the way!

    Thanks!

    Reply
    • December 29, 2014 at 10:50 am
      Vlad Catrinescu

      Hello, Yes it’s a DBA job to do this if you don’t have the rights.

      Tell the DBA the account and the roles it needs, and they should know what to do!

      Reply
  • December 29, 2014 at 7:47 am
    Mickey

    Excellent guide!!!
    Can you please post a new link to the PDF version?

    Reply
    • December 29, 2014 at 10:43 am
      Vlad Catrinescu

      Hey, Just updated the post! > http://1drv.ms/1p6tLcv

      Reply
      • December 31, 2014 at 12:12 am
        gregory davis

        OK. I give up. I am going to a clean re-install of sharepoint foundations 2013. A couple of questions:

        1. At what point in the install do I use the service account script? when I installed the 1st time, using the set up program I didn’t see a place to setup accounts or do I have to use powershell to do the install?

        2. Still need to know how and where to setup the SQL Server accounts?

        Thanks

      • December 31, 2014 at 10:26 am
        RIch

        Gregory – You can create the accounts first, before running any of the SharePoint Stuff. Think about it. If you have a new employee coming in your admins can create an account in AD for them months before they get there and it won’t effect anything. In order to start using the accounts you will obviously have to have software on hand to be installed. Install SQL when you are logged in as the SQL_Install account, apply the permissions to SQL Server that are required for the SP_Install Account and any other that requires specific permissions in SQL and then logoff and log back on with the SP_Install account in order to start installing the SharePoint bits.

        As for question 2, there are several thousand websites that show how to add accounts to SQL Server. Start here for instance: http://databases.about.com/od/sqlserver/a/Creating-Sql-Server-2012-User-Accounts.htm but there are a lot in TechNet and MSDN as well.

      • January 1, 2015 at 9:31 am
        gregory davis

        Thanks Rich,

        I’ll give your suggestions a try and report back.

        BTW, just so you know, I am implementing SharePoint Foundations 2013 on Windows Home Server 2011. It is outdated and unsupported, but it does what I need and I was able to get SharePoint host-named site collections up and running. However, I ran into a problem when I tried to install SharePoint Apps. I followed all the instructions for getting the environment configured for apps but then ran into an issue with how my accounts were set up. That pointed me towards Vlad’s service account solution.

        Anyway, just wanted to get that out there just in case you or anyone else has some experience and / or suggestions about my implementation.

        Thanks and Happy New Year!

      • January 3, 2015 at 7:24 am
        gregory davis

        Thanks Rich, I’m going to try your suggestions and report back.

        BTW, I am implementing SharePoint Foundation 2013 on Windows Home Server 2011. I know it is outdated and unsupported, but I was able to get my host-named site collections up and running just fine. I ran into a problem when I tried to configure the environment for sharepoint apps. After a lot of research, I concluded that the problem is the configuration of the service accounts (I was using my own account as a managed account for all the services which I found out is not a good idea). Anyway, that is what lead me to this blog.

        I just wanted to get that out there just in case you or someone else has some experience with what I’m doing

        Thanks and Happy New Year!

      • January 13, 2015 at 11:00 am
        Gregory Davis

        Rich or anyone, thanks for your help. I have restored my server but have one more question. I want top use Vlad’s account creation script before installing SharePoint and SQL Express but the account creator instructions say that I must be logged on a domain controller. The instructions for sharepoint foundation 2013 say that it can’t be installed on a domain controller. I’m doing a single server install. Any suggestions?

        Thanks

      • January 26, 2015 at 2:55 pm
        Rich

        Greg,
        I believe it says installation is not supported on a domain controller. It is ok for a dev box.

      • January 26, 2015 at 6:57 pm
        Vlad Catrinescu

        Nope, installation is not supported on domain controller, but works for most of the stuff. However some stuff like Apps, sandbox code etc don’t work! Only do it for a dev machine!

      • January 31, 2015 at 7:12 pm
        greg davis

        Having a strange problem with the Host Named Site Collection (HNCS) creator. I successfully created 2 HNSC using the creator. However, the strange thing is the new site collections are accessible everywhere but on the server where they are being hosted. On the server, the sites just keep asking for the username and password which are the same ones that work successfully everywhere else. Is this a loopback problem? Thanks

  • January 18, 2015 at 4:45 pm
    Robin Thakur

    Thanks for the guide Vlad. Is it worth using seperate domain accounts per service application (ie seperate app pools) or is that not done these days?

    Reply
    • January 18, 2015 at 5:11 pm
      Vlad Catrinescu

      Hey, the security is increased however it’s not worth the big performance hit and a lot of possible problems. So I would say one for all service apps!

      Reply
      • January 18, 2015 at 5:35 pm
        Robin Thakur

        Cheers Vlad, do you know anywhere MS recommends that as best practice? Having scanned Technet for a few days there’s a load of contradictory information on the subject.

  • January 22, 2015 at 8:18 pm
    Peter

    Is it possible not to give Security_Admin and DB_Creator rights to SP_Farm and SP_Admin? We want to enforce that any database/server level activities to be done with the presence of a DBA. We want to restrict SharePoint administrators to table level activities only.

    Reply
    • January 23, 2015 at 2:43 pm
      Vlad Catrinescu

      Hello,

      Unfortunately you need to leave it for the farm account & Admin account . Because the farm account will create a lot of DB’s whenever you do a new contentdb, search service application or whatever. The account will be DBO on a bunch of databases and you cannot take that away.

      I would just say education on the SP Admins to not touch SQL is key!

      Reply
      • January 26, 2015 at 2:20 pm
        Peter

        I agree with the education but there is no guarantee that they will follow. It is acceptable for them to be DBO but don’t want them to have the ability to create database. Will SharePoint prompt for credential when it needs to create a new db or other tasks if SP_Farm and SP_Admin is not a member of the dbcreateor and securityadmin roles? Definitely, without those roles, it will be inconvenience for SP_Farm and SP_Admin to do certain tasks. The question mark I have is whether SharePoint will just error out and/or will not run properly if those roles are not given or ask for credential interactively.

      • January 26, 2015 at 6:59 pm
        Vlad Catrinescu

        SP will not work at all if you don’t give those rights, it won’t ask for credentials interactively since it expects to have those rights in the minimum requirements.

  • February 2, 2015 at 5:06 pm
    Grig

    Hi Vlad,
    Sp_Install account you don`t need it?
    Thanks
    Grig
    P.S. banuiesc ca vorbesti si romaneste?

    Reply
    • February 2, 2015 at 7:48 pm
      Vlad Catrinescu

      You can have a separate account only for Installs if you want, but I usually do it with the SP_Admin account.

      Reply
  • March 30, 2015 at 5:19 am
    Alexander P

    Hello, I assume an update came out for SharePoint at some point that added a new service account

    Windows Service – Search Host Controller Service

    Does it also use the SP_Services account? I am really impressed with all the work that went into compiling this, thanks. I am brand new to working with the SharePoint platform and detailed articles like this that make it all very easy to configure and learn what is happening on the process are invaluable.

    Reply
  • April 14, 2015 at 1:42 pm
    greg davis

    Got my site collections working. Now I am working on solving a problem with large files. Can’t seem to import files larger than 1 gig. I’ve done everything that has been suggested on this site and others. I am going to try and implement Filestream RBS.

    Reply
  • May 26, 2015 at 12:36 pm
    KTNN

    In autospinstaller, in the section Object Cache Accounts, it’s required to add 2 different accounts: CacheSuperUser and CacheSuperReader. What is your recommendation? Thanks.

    Reply
    • July 14, 2015 at 3:05 pm
      Vlad Catrinescu

      two different accounts, one of them has Full Read and the other Full Control in the Web App policy!

      Reply
  • June 23, 2015 at 10:35 am
    Vas

    Hi Vlad,
    Great Post, but i need some education here..:))
    I understand the concept, but in general when do you use which service accounts? I am confused.
    For example for sql installation, for pre-requite installation, for SP installation, working around SP, configuring services and web applications, creating sites, giving permissions, etc, etc, etc. A post for that would be awesome. Thanks in advance!!

    Reply
  • August 19, 2015 at 5:16 am
    Dinos

    You should know that this article has become a reference for many people, we cannot thank you enough!
    I recently came up with this issue (https://support.microsoft.com/en-us/kb/2463865) that I believe should be included in your article. Apparently all managed accounts need the “READ permission” in the AD.

    Thanks again,
    d.

    Reply
  • December 3, 2015 at 8:52 am
    raghu

    Great article thanks for posting i really appreciate all of what you told. excellent guide thanks for sharing .

    Reply
  • February 25, 2016 at 11:47 am
    Mayur

    Hi All,

    Can anyone tell me what credentials is required to access share point webservice. Like get lists and user groups.

    Thanks
    Mayur

    Reply
  • March 2, 2016 at 1:22 am
    Abhay

    Hello Vlad,

    Thanks for this update, i am using it for my refence.
    I have two doubts 1. A/C for SharePoint Search 2. A/C for Search Host Controller Service
    What should be we use on the basis of low security model.

    Reply
  • March 3, 2016 at 1:07 am
    Manisha

    Hi,

    I am new to sharepoint. Can anyone tell me, Are there more than one farm account in sharepoint 2013 farm?

    Reply
  • April 12, 2016 at 10:08 am
    MSIH LLC

    Account that will be running windows service need “log on as service” local permission. Account that will be running app pools need “logon as batch” local permission. Out of the box windows allows the SharePoint installer to grant these local permission but servers locked down using GPO (which most companies are not doing) usually restrict membership to these local permissions. The key takeaway local permission none is technically not correct.

    Reply
  • May 17, 2016 at 12:26 pm
    Gregory

    Is it required to use the exact names like spAdmin for the accounts? my company assigns service account names i.e. $brtd001

    Reply
    • May 17, 2016 at 12:31 pm
      Vlad Catrinescu

      You can name them as you want per your naming policy! Just make sure they’re under 20 characters including domain name.

      Reply
  • September 9, 2016 at 6:11 pm
    Dan

    When creating a new Search Service Application the page asks for a Search Service Account as well as an Application Pool managed account.

    I’m following your Medium Security Option, but wondering if your intent is that we would use SP_Crawl for both the Search Service Account and Application Pool managed account, or would we use SP_Crawl only for the Search Service Account and SP_Pool for the Application Pool account?

    Reply
    • June 28, 2017 at 10:07 am
      Vlad Catrinescu

      You should use SP_Services for the Search Service App Pool!

      Reply

Leave a Reply

Top Learning Resources

15 49.0138 8.38624 1 0 4000 1 https://vladtalkstech.com 300 1