Tag Archives: Accounts

What Domain Accounts to Use For SharePoint 2010

When setting up a SharePoint farm, whether 2007 or 2010, you have the option of providing various service identities throughout the process. Indeed, every application can run with its own identity. Far too often, administrators pick a single account, and use it for everything. While this is certainly the easiest approach, it is far from the most secure, and it can be very limiting down the road if you need to get granular with your permissions. The trouble is that there are a lot of intricacies as to what account does what, and getting it right requires a pretty comprehensive understanding of the product.

We now have enough work under our belt with SharePoint 2010 that I feel comfortable sharing some of our best practices around account creation for SharePoint 2010. The product itself has gotten more complex, and so therefore have the configuration options. There is no “one size fits all” approach for all scenarios, but the list that I am providing below should work as a good starting point. There is often a trade-off between the ease of manageability and providing good security, and the approach below,I feel,find a good balance.

The chart below describes the account, its purpose, what rights it needs to the local machines in the farm (including the SQL server machine(s), the rights it needs for SQL Server directly, and the rights it needs to the Active Directory domain.

Base Set of SharePoint 2010 Service Accounts

Account Purpose Local Rights SQL Rights Domain Rights
spSetup
  • Used to login to the farm servers
  • Used to install bits on the farm servers
  • Administrator
  • Remote Desktop Login
  • DB Creator
  • Security Admin
  • Member
  • spFarm
  • Identity for all Windows Services
  • Identity for all SQL Services (optional)
  • Identity for Profile Synchronization Service
  • Identity for all code running with elevated permissions (web parts)
  • None (1)(3)
  • DB Creator
  • Security Admin
  • Member

     

  • spApps
  • Identity for all SP Application App Pools (4)
  • None None
  • Member
  • spServices
  • Identity for all SP Service Applications (4)
  • None None
  • Member
  • spUPS
  • Identity for the User Profile Service 
  • None None
  • Member
  • Replicating Directory Changes(2)
  • spCrawl
  • Used by the Indexer to crawl content
  • None None
  • Member (5)
  • spBI
  • Trusted account for Reporting Services and PerformancePoint when not using Kerberos
  • None
  • DB Access as appropriate
  • Member
  • spSuperUser
  • Used for Object Caching
  • None
  • None
  • Member
  • spSuperReader
  • Used for Object Caching
  • None
  • None
  • Member
  • (1) Needs to be a part of the Local Administrators group while the User profile service is being created. See my previous post for more details. Once created, this account can be removed.

    (2) AD Permission required by the User Profile service

    (3) Required for a specific AD container when using the incoming email service. See this post for details on how.

    (4) There may be a large number of these, one per entity

    (5) Appropriate rights will need to be granted to this account for any EXTERNAL content being crawled (file system, shared folder, Lotus Notes, etc)

    Hopefully this will help a few of you get started with a little less head scratching.