SharePoint 2013 Service Accounts Best Practices! Is there a golden solution for all farms?


Service Accounts are a very big part of installing almost every version of SharePoint, however everyone has a different way of setting them up. And once you install your SharePoint with a set of service accounts, it’s easier to do a clean install than to change them all.

Every SharePoint admin you ask will probably have a different view of how many service accounts you need, how you should name them , and what permissions you need to give each one of them. Depending on the level of security you want to achieve in your SharePoint Farm, you can install everything with only one account (please don’t) , and you can make as many as 10 to 15 accounts.   Even if all the SharePoint administrators have different views and different ways , it doesn’t mean one of them is wrong and one of them has the golden solution for every SharePoint farm.

To get to the subject, which is Service Accounts for the newly released version of SharePoint, SharePoint 2013, I recently read an article on TechNet that suggests a set of “best practices” service accounts. I read the accounts and the permissions multiple times, and although they weren’t wrong.. I didn’t think it was right. You can read the original article here, however I will do a little summary. Here are the proposed accounts:

  • SQL_Service, for the SQL Server service.
  • SQL_Admin, for the SQL Server administrator.
  • SP_Admin, for the SharePoint administrator and setup user.
  • SP_Farm, for the SharePoint farm service.
  • SP_WebApps, for the user-facing web application app pool.
  • SP_ServiceApps, for the service application app pool.
  • SP_Crawl, default content access account.
  • SP_UserSync, user profile synchronization account.
  • SP_EnterpriseAdmin, powerful account for handling all kinds of high privileg operations.
  • Farm administrators, normal admin user accounts are used as SharePoint Farm Administrators.

Here is my opinion on this:

Although this set of service accounts isn’t wrong, I think that it isn’t well balanced. Let me explain:

I think there is a lot of security on the “farm admin” (SP_Admin, SP_Farm, SP_EnterpriseAdmin, Farm administrators), and there is some pretty basic stuff missing ex: Having an account for the windows search service, and a different one for the crawl.

Then, I asked myself what would I do to make it better. How could we define a real set of service accounts that could fit any scenario, from a small development farm to a huge multi-tier farm.  The answer is simply, you can’t! There is not one single set of Service Accounts that could be used because the security requirements for each scenario are different. But how can we define a set of Service account that while it keeps a certain standard of security, it also doesn’t use too many  service accounts for what we need and respects the requirements of the client?

Some clients and companies will ask you explicitly to install and configure their  SharePoint infrastructure according to Best Practices without even knowing what they are!

So this is what I came out with: I made three different sets of Service Accounts that can be used for reference. Every set is for a level of security, Low Security, Medium Security and High Security. As you probably guessed, as you go higher on the security chart, you add more accounts and each of them has less privileges on the farm.

I made this PDF (doing tables with Blogger is a real mess) and embedded it into the page (if you can’t see it, scroll to the end of the post, there is a download link). Please read it, and tell me what you think. I am really open to suggestions and want to hear your opinions on this delicate matter.

[scribd id=117074973 key=key-10r9talgbbfxh0z6xp4t mode=scroll]

If you don’t see the document, or want to download it, you can get it from my SkyDrive  here:  Download

Please spread the word about this post using the buttons at the end  so we can get the most visibility and most opinions on the very delicate subject of Service Accounts in SharePoint 2013.

Please leave a comment to let me know what you think about this  and don’t forget to like us on Facebook here and to follow me on Google+ here and on Twitter here  for the latest news and technical articles on SharePoint.


Give Me +K on Klout

Previous Post
Step By Step Guide to configure the “Replicating directory changes” for SharePoint 2010 and 2013
Next Post
Some Interesting Events this week


  • December 18, 2012 at 8:01 pm


    You are right that this is a very delicate matter. The service accounts should be planned carefully. The Technet site has just given the recommendations as the best practice, but the actual implementation would depend upon the requirements. Planning for the service accounts should be done after a through discussion with the client as to what kind of security they are looking forward to and how do they plan to layout their farm.

    As far as you have segragated the service accounts on the security complexity level, I would suggest a few things:

    1. In the Low Security Option, we can rename the application pool from SP_FARM to SP_ADMIN.

    2. For each of the security options, each web application should be running on individual application pool, rather than using the same application pool, as each app pool account might be given different permissions to act differently on different applications (in case we have multiple applications on the same server).

    Please do let me know if I am thinking in a wrong direction. You can mail me at

    • December 18, 2012 at 9:48 pm

      Hi Neeraj and thanks for your opinions!

      for #1 , I think you mean the “Farm Account” , and yes I do agree we can call him SP_Admin since he is the “Farm Administrator” as well as running the farm services.

      for #2, I am not sure what you mean exactly. I do agree that every Web Application needs it’s own Pool, however I think one service account that runs all the service application pools is enough.

  • January 17, 2013 at 8:35 am

    Hi Vlad,

    I can’t see your PDF. There is an error:
    “This page can’t be displayed”.


    • January 17, 2013 at 8:36 am

      Oh sorry – the first link is OK.

  • March 14, 2013 at 8:00 am

    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.

    • March 20, 2013 at 6:39 pm

      that would be the minimum… but you can run them all under the Enterprise Admin account if you want 🙂

  • March 20, 2013 at 5:33 pm

    Nice post. Here is one more post explaining Sharepoint 2010 service accounts

    • March 20, 2013 at 6:38 pm

      Shared Service Provider (SSP#_Service)

      That’s 2007 no?

  • November 1, 2013 at 4:13 pm

    Hi Vlad.
    Very good article !
    Tell me what do you think about creating seperate service accounts for each Service Application running in SharePoint Farm i.e Excel Services, Search, Secure Token Service, Performance Point Service, BCS, etc.
    I can see you put them all under the SP_Services account, but I think every accunt needs different set of permissions to run the Service Application.



    • November 7, 2013 at 10:16 am

      I don’t think the Security Benefit outweighs the performance hit you will get by doing this. It’s very recommended to only have 1 Service Applications App Pool in order to increase performance! The only one I might put in a different app pool is Search.. but you can put them all with 1 account!

  • September 16, 2014 at 12:10 am
    Ioannis G

    Hello Vlad,

    I really like the article. The link to download the table is broken can you please fix it?

    Thank you!

  • December 22, 2016 at 9:39 am
    Jen Hays

    I’m coming to this article a little late in the game, but we are trying to use a separate service account for our MySite config in SP2016 and I can not get it to work. Only account that can run the my site app is the farm account. Any ideas?


Leave a Reply

15 49.0138 8.38624 1 0 4000 1 300 1