Corey’s Guide to SharePoint Service Accounts
Posted
Monday, May 23, 2011 8:48 AM
by
CoreyRoth
Everyone has their own take on what service accounts should exist on a given SharePoint farm. From the official documentation, you pretty much have to patch together bits of pieces of things to come up with a concrete list. The purpose of today’s post is to give you a starting point for your own account list. It also includes the permissions that need to be granted in order to make things work properly. In a lot of organizations, companies lock down a lot of the privileges accounts have via group policy. This guide will hopefully give you a list that you can start with on your next install to make the process go smoothly. Did I get something wrong? Perhaps. Leave a comment and I’ll continue to update this post so that it has the best information possible.
Let’s start with the general naming of accounts. If you read my article on naming conventions, then you know consistency is key. You also know I can’t stand abbreviations when it comes to naming anything. However, if you know Active Directory, you also know that account names (SAM Account Names) are limited to 20 characters (for backwards compatibility reasons). For this reason, you really have to abbreviate some things and you are best if you keep your account name prefix short. Ideally you want all of the SharePoint accounts to have the same prefix so that they are easily identified and found. For my accounts, I typically go with the prefix sp_. SharePoint is pretty recognizable with the sp abbreviation. I typically don’t like underscores but I tend to include them in account names. You can leave it out just as well. I also go with lowercase letters for the prefix as I find it just looks better. Of course this is just one possible prefix, you can always come up with something you prefer better. Just keep in mind the account name length limitations.
Let’s take a look at the account list.
Account | Permissions | Description |
sp_Setup | - SQL Server – dbcreator and securityadmin roles
- Local administrator on SharePoint servers
| - This account is used to perform the initial install and configuration of SharePoint.
- Technically not a service account
|
sp_Farm | - SQL Server – dbecreator and securityadmin roles
- Allow log on locally
- Log on as a service
| - SharePoint farm account specified in SharePoint Configuration Wizard
- This account also will have local administrator privileges when provisioning User Profile Synchronization
|
sp_PortalAppPool | | - Application pool account for main SharePoint web application
- Could also just be called sp_AppPool or spAppPool + <PortNumber>
|
sp_ServiceAppPool | | - Application pool account for web application hosting service applications
|
sp_MySitesAppPool | | - Application pool account for My Sites web application
|
sp_UserProfileSync | | - Account used to synchronize user profiles from Active Directory
|
sp_Search | | - Account used for running Search Service
|
sp_SearchCrawl | - Full Read on each web application
| - This account is used by search when crawling
- This account must not have local administrator permission or SharePoint administrator permissions
|
sp_FastUser | - SQL Server – dbcreator role
- Log on as a service
- Allow log on locally
| - This account is used to run the FAST Search for SharePoint services
|
No accounts should ever have domain administrator privileges. Log on a service, Log on as a batch job, and Allow log on locally are all privileges inside Local Security Policy. SharePoint usually does a pretty good job of assigning these privileges when you set up the accounts. However, if your servers are running under a tight group policy, then it is more than possible that the GPO will remove these privileges or your accounts might be in Deny groups. If your servers do run under a GPO which strips privileges, everything will more than likely work up until the point you reboot. Once you log back in, you will find that none of your services have started. At this point, you will need to work with your Active Directory administrator to get the required permissions.
This is quite a few accounts. Can you get by with less? Maybe, but I recommend against it. Some domain administrators are more concerned about the clicks required to create a new account than the actual security of your SharePoint farm. You might be able to consolidate your application pool accounts. However, some accounts have conflicting security requirements. For example, the sp_Farm account has full permissions on your SharePoint farm but the sp_SearchCrawl account must only have read permissions or bad things happen. The lesson here is don’t take shortcuts when it comes to SharePoint accounts.
What about environment specific accounts (i.e.: development, test, production)? A lot of organizations use separate accounts for test versus production. This is a pretty good practice but you have to have a naming convention to accommodate these different environments. You might be tempted to append something like dev, test, or prod to the account names. However the issue with the names I provided is that many of them use up most of the available characters. Instead, what I recommend is that you leave the production accounts as is. By default if you see an account name, you assume it’s production. For test, your best bet it to probably append or prefix a letter such as T. For example, the farm account would be sp_FarmT or tsp_Farm. Neither might be an elegant solution, but keep in mind you can always include the full word in the display name of the account (i.e.: SharePoint Farm Test). Have a better way to organize these accounts? Leave a comment.
I hope this serves as a good starting point for those of you setting up new farms. Do you have accounts that you think should be on the list? Let me know. One area in particular, I didn’t cover was the BI features such as PerformancePoint and PowerPivot. I’ll add these areas in at a later date.
Follow me on twitter @coreyroth.