This is taken from
Todd Klindt's excellent blog, and I especially like the
Domain Right and
SQL rights needed columns.
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_userprofile1
|
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_superuser2
|
Cache account
|
Domain User
|
Web application Policy Full Control
Web application super account setting
|
None
|
sp_superreader2
|
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 |
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_workflow3
| The RunAs account for the Workflow Manager service |
Domain User
|
None
|
None
|
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!
