SharePoint 2013 Service Accounts Best Practices Explained

SharePoint 2013 Service Accounts Best Practices Explained

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://absolute-sharepoint.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

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

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

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.

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

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/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 Absolute SharePoint Blog 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.
4.94/5 (33)

Please rate this

 
Comments

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.

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?

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!

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

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?

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

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”

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.

SharePoint Perth

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

Thanks! I am glad you liked it!

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.

This comment has been removed by a blog administrator.

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?

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 ?

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!

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

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

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

This comment has been removed by a blog administrator.

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

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

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

I have the same question as jbwdevos and Ian Addis.

Can You provide us some more explaination?

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

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?

That is a good idea, I will try to get a V2 out this weekend. I already had a few changes in mind! I will include this

Hello, I have just updated the SharePoint 2013 Service Account Creator, and now you can create the SQL accounts under their own OU! Go check it out! https://sp2013serviceaccount.codeplex.com/

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

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

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.

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

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

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

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?

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,

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?

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

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

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.

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

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!

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?

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!

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?

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

Thanks!

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

John.

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

Hello,

The Farm account, Application Pool accounts (both Web Application & Services) as well as the account who will run the Windows Search Service need to be in managed accounts!

My question was not as I wanted it to be. What I wanted to ask about was Best Practices for which managed accounts can have Automatic Password Changes?

-Arnstein

Hi Vlad, it would be great if you would indicate which of the listed accounts would make sense as managed accounts, along the lines of what Gary Lapointe did for SP2010 in his post http://blog.falchionconsulting.com/index.php/2010/10/service-accounts-and-managed-service-accounts-in-sharepoint-2010/. Cheers

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?

Yes but only in Active Directory!

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.

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.

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?

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

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

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)

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!

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?

You need to use Central Admin.

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.

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.

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.

I’m trying to post the error:

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:

Tarcísio Corte

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

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.

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!

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

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.

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?

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

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

Thanks!

Excellent Post. Thank you very much.

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.

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!

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?

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!

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!

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.

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

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?

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!

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!

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!

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

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

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.

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!

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!

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

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

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!

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

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?

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!

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.

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.

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!

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.

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.

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

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

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.

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.

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

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

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

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.

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

Hi All,

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

Thanks
Mayur

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.

Hi,

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

There is only one farm account per farm!

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.

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

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

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?

You should use SP_Services for the Search Service App Pool!

Leave a Reply