Todd Klindt's Office 365 Admin Blog

Quick Launch

All Site Content

Todd Klindt's home page > Todd Klindt's Office 365 Admin Blog > Posts > Service Account Suggestions for SharePoint 2013

February 15

Service Account Suggestions for SharePoint 2013

by Todd O. Klindt

on 2/15/2013 5:08 PM

Category: SharePoint 2013

Now that SharePoint 2013 is out, I’ve gotten a few questions about what service accounts I recommend for a new SharePoint 2013 farm. Here are my suggestions. They are not hard guidelines, just a good place to start.

Account name	Role	Domain rights	Local SharePoint Server rights needed	SQL rights needed
sp_install	Used to install SharePoint binaries.	Domain User	Local administrator on all SharePoint boxes	public, dbcreator, and securityadmin SQL roles. Need to be SysAdmin on SQL when installing the Workflow Manager
sp_farm	Farm account. Used for Windows Timer Service, Central Admin and User Profile service	Domain User	Local Admin during UPS provisioning, log on locally right	None
sp_webapp	App pool id for content web apps	Domain User	None	None
sp_serviceapps	Service app pool id	Domain User	None	None
sp_content	Default account used by Search Service Application to crawl content	Domain User	None	None
sp_userprofile¹	Account used by the User Profile services to access Active Directory	Must have Replicating Change permissions to AD. Must be given in BOTH ADUC and ADSIEDIT. If domain is Windows 2003 or early, must also be a member of the "Pre-Windows 2000" built-in group.	None	None
sp_superuser²	Cache account	Domain User	Web application Policy Full Control Web application super account setting	None
sp_superreader²	Cache account	Domain User	Web application Policy Full read Web application super reader account setting	None
sqlinstall	Account SQL is installed with	Domain User	None	Local Administrator on the SQL box
sqluser	Account the SQL Instance is running as.	Domain User	None	Will be given necessary permissions when SQL Server is installed by a local administrator on the SQL box

1) See http://technet.microsoft.com/en-us/library/ee721049.aspx and http://www.harbar.net/articles/sp2010ups.aspx

2) http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx

Those are the accounts needed for a base install of a SharePoint 2013 farm. However, there are other optional features that require their own accounts too. Here’s a list of accounts to use if you install the optional components.

Account name	Role	Domain rights	Local SharePoint Server rights needed	SQL rights needed
sql_ssas	Account that we run the SQL Server Analysis Service services as	Domain User	None	db_datareader on databases
sp_excel	Excel services unattended account.	Domain User	None	None
sp_pps	PerformancePoint Unattended account	Domain User	None	None
sp_accsvc	Access Services. Used to create all Access databases in SQL and the service account running the service app pool for the Access Service Application	Domain User	None	db_owner, public, and securityadmin
sp_workflow³	The RunAs account for the Workflow Manager service	Domain User	None	None

3) Further Workflow Manager requirements are outline here, http://technet.microsoft.com/en-us/library/jj193451.aspx

These are just suggestions, they are not written in stone, just guidelines. For instance, every SharePoint farm should have its own set of accounts. Production SharePoint 2013 should be a different accounts than a dev SharePoint 2013 farm. And a production SharePoint 2013 farm should have different set of accounts than the production SharePoint 2010 farm that’s being upgraded. You don’t want any cross-contamination. You don’t want an errant dev process jumping the stream and breaking production.

Also, make sure to keep your account names to 20 characters or shorter. Some places in SharePoint use the Pre-Windows 2000 version of the account name, and that can only be 20 characters. If your account name is longer than 20 characters you’ll get weird “account doesn’t exist” message when you know damned well it does.

While you’re creating accounts, you should also create an admin account or two so you aren’t tempted to log in as sp_farm. Bad! Bad!

Here's a blog post with a PowerShell script that will create all of these users for you. It does not give them any permissions, that's all on you. :)

ShortURL: http://www.toddklindt.com/SP2013ServiceAccounts

Edited 2/17/2013: Added Public role to sp_install and fixed some account names.

Edited 2/20/2013: Fixed a typo in sql_ssas account description.

Edited 11/11/205: Added a link to PowerShell script

23 Comment(s)

Comments

I think that we will need two for (sp_serviceapps_stander - sp_serviceapps_admin)

Hi todd,

according to this TechNet article:
http://technet.microsoft.com/en-us/library/cc263445.aspx

the sp_serviceapps for some service accounts gust need to be a domain user and for other services need to be part of the farm admin group.

so i am suggesting that we create two sp_serviceapps_stander - sp_serviceapps_admin

What you think ??????

Regards,
Mahmoud Hamed

on 2/16/2013 12:50 AM

Search Service Account...

What you think of Search Service account? Do you need dedicated service account with all these new hostcontroller and noderunner services.. or Do you prefer search service runs under farm account?

MS is quiet on this one as well... No search service account recommended based on this.. http://technet.microsoft.com/en-us/library/cc678863.aspx

Regards,
Nik Patel

on 2/16/2013 10:06 AM

Re: I think that we will need two for (sp_serviceapps_stander - sp_serviceapps_admin)

Hi Mahmoud,
Are you referring to the account the Security Token Service runs as? If so, that runs as the farm account and is assigned as such automatically.

tk

Todd O. Klindt

on 2/16/2013 10:25 AM

Re: Search Service Account...

Hey Nik,
Good to hear from you. My SharePoint 2010 service account blog post had a dedicated Search account, but I ended up never using it. For one, it was also a pain, as no matter what you entered when you created Search, SharePoint ran it as the sp_serviceapp (or sp_farm, I forget) account. So you had to manually change it. Second, if I followed my own advice, that sp_search account had the permission to log on as a service and it had web endpoints. I like to split those up so that if a process is compromised remotely it's tough for that account to log into the box.

That's my rationale. That's also why I call these blog posts "suggestions." I might be completely wrong. :)

tk

Todd O. Klindt

on 2/16/2013 10:37 AM

I agree with you on Search Service Account..

You're not wrong. I call it practical. In fact, I had a hard time suggesting SP_Search account for my clients. I agree, even in SP2010 time frame, I ran search service (MSSearch.exe) as SP_Farm (never bothered to change with manual configuration).. I believe AutoSPInstaller configures SP_Search account if you provide and run search NT service accordingly. As far as search service application wcf end-point, I have always run under SP_ServiceApps application pool account along with all my other service applications.

I am yet to understand reasons why you would need search windows NT service as dedicated service accounts in SP2010. I haven't installed SP2013 on multi-server farms and needs to figure out under what account noderunner.exe should run. At this moment, I believe I will run under SP_Farm account and later follow best practices if there are any comes out in future...

On the side note, TechNet is very confusing in regards to sp2013 service accounts guidance - the link Mahmoud provided is extreme list of service account which I would never suggest to my client and the link I have provided missing some of the accounts you have like object cache..

Overall, almost perfect list and great post as usual..

Thank you,
Nik Patel

on 2/16/2013 11:15 AM

Re: I think that we will need two for (sp_serviceapps_stander - sp_serviceapps_admin)

Todd,

No, I am talking about for example:

Access Services, Business Data Connectivity service, Secure Store Service, Usage and Health Data Collection Service, User Profile Service, Visio Graphics Service, Word Automation services
--These services account Must be a member of the Farm Administrators group.

but in the other hand:
Excel Services, Managed Metadata Service, PerformancePoint Service.
--This account just need to be just a domain user account.

Mahmoud

on 2/16/2013 12:48 PM

Re: I think that we will need two for (sp_serviceapps_stander - sp_serviceapps_admin)

Hey Mahmoud,
In my SharePoint 2013 farms I'm running those service apps as sp_service. They seem to be running fine and that account is not in the Farm admins group in Central Admin.

I'm not sure why they're recommending that.

tk

Todd O. Klindt

on 2/16/2013 9:54 PM

sp_userprofile account

SharePoint 2013 supports both the 2007 "style" and the 2010 "style" of User profile imports. the 2007 style does not require the add AD security needs. It runs just like the 2007 configuration. Just thought you may wish to make note of that </smile>

Eric VanRoy

on 2/18/2013 8:58 AM

Typo

You certainly don't have to publish this comment. I just wanted to let you know that you had one small typo that I happened to see:

Account that we run the SQL Server Analysis Service servives as

"servives" I presume should be services

Doug Hemminger

on 2/20/2013 7:04 AM

Re: Typo

Doug,
Thanks for the heads up on the typo. I've fixed it.

tk

Todd O. Klindt

on 2/20/2013 9:05 AM

1 - 10