I’m going to offer the approach I take on this task. I’ll highlight all of the different accounts I typically create, where/how to assign them in the farm, and even a few that are often overlooked due to their almost hidden nature. I’ve been applying this same approach to most farms I’ve configured recently, even my own development images.
As a side-note, I used to run with very little separation in my development virtual machines… it’s a development virtual, it doesn’t need a high level of security separation right? But lately I’ve been applying the same level of service account separation to my development images as I would for any production system. I do this because I both want to catch security related bugs in my custom solutions early in the development process, and I just plain hate seeing that red Health Analyzer bar telling me my farm has issues every time I visit Central Admin :)
These are the accounts I recommend creating in AD:
- sp_Install
- sp_Farm
- sp_Admin
- sp_Sites
- sp_UserProfile
- sp_UserCode
- sp_Service
- sp_Search
- sp_SearchCrawler
- sp_Cache (If SharePoint 2013)
- sp_SuperUser
- sp_SuperReader
Vary the naming on these to suit you or your organizations likes, policies, etc. on naming convention. I’ve often gone with more descriptive naming, such as sp_DistributedCache instead of just sp_Cache. I’ve also sometimes name them for the environment, such as SP2010_Farm or SP2013_Farm (which you may notice in some of my screenshots). Can be important if you’re in an organization that has multiple SharePoint rollouts and you want, or don’t want, to do any credential sharing. You get the idea.
The first account, sp_Install, is going to be your super privileged account that will perform the SharePoint installation and run the Products and Technology Wizard. This account will need local administrator rights on every server in the farm, plus securityadmin and dbcreator rights to the SQL server.
Chances are, if you’re already looking at a prebuilt SharePoint farm prior to reading this article, it’s too late to do this one. Not a biggie. A lot of farms start off with the sp_Farm account serving this dual purpose of also being the installation account. The thing to remember under that circumstance, however, is there’s a good chance this means that your existing sp_Farm account could still be in the local administrators group… something the Health Analyzer will gripe about. As a best practice the farm account should not be a part of the local administrators group. This is where having a separate install account is nice, as it keeps you from having to put the farm account back into the local administrator group again later if you’re going to install any SharePoint service packs or cumulative updates, then removing it again when done. It also keeps you from the temptation of just leaving the farm account in the local administrator group all the time.
Assuming this is a fresh install, and you just performed your installation using sp_Install, the next thing you’re going to want to do is set sp_Farm as your Farm Account. First step is that this account will need to be registered as a Managed Account. There are a number of other service accounts that also must be Managed Accounts, so we can just set them all at the same time.
A special note about the account sp_UserCode, which is for the Sandbox Code Service. This account must also be added to the Performance Log Users and Performance Monitor Users groups on each machine that will be running the Sandbox Code Service. Without these permissions the service won’t run. The SharePoint Central Administration site will report that it’s running, but if you take a look at the actual Windows Service “SharePoint User Code Host” it will be in a stopped state, and will immediately stop every time you try to manually start it.
These following accounts need to be setup as Managed Accounts in SharePoint:
- sp_Farm
- sp_Sites
- sp_UserProfile
- sp_UserCode
- sp_Service
- sp_Search
- sp_Cache (if SharePoint 2013)
Managed Accounts can be registered via Central Administration -> Security -> “Configure managed accounts”:
They can also be added using the PowerShell cmdlet Set-SPManagedAccount.
Managed Accounts are accounts that can be configured to have passwords reset on a set schedule, automatically by SharePoint, if desired. There are a number of services in the farm that only accept picking a Managed Account from a dropdown. So, whether you plan to utilize the password resetting feature or not, these particular accounts will need to be registered with the system prior to them being available for selection in the aforementioned dropdowns.
After setting up the Managed Accounts lets go and start assigning some services. Head to Central Administration -> Security -> “Configure service accounts”:
From this page you can perform a large amount of the security separation:
Using the dropdown, select Farm Account and let the page refresh. Then, from the dropdown below, select the sp_Farm account and hit OK. This may take some time as this is a big reassignment. If you happened to use sp_Farm as your installation account, this will already be set with no need for any reassignment.
Continue on using this page to reassign all of the other accounts as well:
Assign sp_UserProfile to the User Profile Syncronization Service
Assign sp_UserCode to the Sandbox Code Service
Assign sp_Service to:
Assign sp_UserCode to the Sandbox Code Service
Assign sp_Service to:
- all Service Application Pools
- the Web Analytics Service
- the Claims to Windows Token Service
Assign sp_Cache to the Distributed Cache Service (if SharePoint 2013)
Assign sp_Search to:
Assign sp_Search to:
- SharePoint Server Search
- SharePoint Foundation Search
Assign sp_Sites to all Web Application Pools
Next, let’s assign the Search Crawler account. For the sp_SearchCrawler assignment you have to go into the Search Application Management page and click on the account next to “Default content access account”:
After this assignment double check User Policy for all of the web app(s) to make sure that sp_SearchCrawler has Full Read. This should have automatically been applied when making the assignment back in Search Administration, but it never hurts to double check. Plus, there is another task we need to perform while we’re in User Policy. For each web application, assign sp_SuperUser Full Control and sp_SuperRead Full Read via User Policy. These two accounts are used for the Web Object Cache as highlighted by this article: http://technet.microsoft.com/en-us/library/ff758656(v=office.15).aspx
To finish configuring the Web Object Cache you then need to crack open SharePoint Management Shell on one of the servers and enter the following:
$wa = Get-SPWebApplication -Identity “Your Web App URL here”
$wa.Properties["portalsuperuseraccount"] = “YOURDOMAIN\sp_SuperUser”
$wa.Properties["portalsuperreaderaccount"] = “YOURDOMAIN\sp_SuperReader”
$wa.Update()
The Web Object Cache is something that a lot of farms don’t have setup, and the only hint SharePoint gives you about it not being configured is an error message that shows up every so often in the Event Viewer on the servers.
Jumping back to search, make sure that the sp_SearchCrawler account has permissions to search user profiles. Select the User Profile Service Application (highlight the row, don’t click the link), click Administrators ribbon button, and add the crawler account with the “Retrieve People Data for Search Crawls” permission:
And that should do it!
Go back to site 
