Wednesday, 5 January 2011

Sharepoint 2010 Installation - Least Privilege Accounts

A while ago, I performed a quick farm installation of Sharepoint 2010 Standard on top of Windows 2008 R2 and SQL 2008 R2, all on the same server. I followed the instructions at http://technet.microsoft.com/en-gb/library/cc262243.aspx and http://technet.microsoft.com/en-gb/library/ee662513.aspx.  

Three accounts were used:

  • My account, which is a domain account and local admin on the server. This was used for the installation.
  • A SQL Server service domain account (let's call it SQLService).
  • A Farm service account (let's call it SharepointFarmService).
The installation completed, but the Sharepoint Health Analyzer later complained that

  • Critical: The Farm Service account is being used for Search and Web Analytics Data Processing;
  • Warning: Built-in account are being used for SPTracev4 and SPSearchv4.

So, it was time to take a harder look at the documentation to see how I could improve the installation procedure.

Dan Holme, in an article on Sharepoint Pro Connections points out that installation account should be not be my account, but a separate account. He notes that the installation account becomes the db_owner on Sharepoint farm config and Central Admin content DBs, and that the config wizards won't run if that user is removed or disabled.

Enhancement 1: Create an installation/admin account (let's call it SPAdmin). Grant dbcreator and securityadmin to the account in SQL. Make the account a Local Administrator on the server.

Connect to the server as your newly-minted installation account, and run the installer.

After the installer completes, you are launched into the Configuration Wizard, where it asks for the 'Database Access Account'. Here, give the credentials of the Farm Service account.


Enhancement 2: Use a different service account for Sharepoint services.

The Initial Farm Configuration Wizard allows a different account to be specified for a number of services:



Create a new service account (e.g. SharepointServices) and specify it in the 'Create new managed account' options. 



In the Initial Farm Configuration Wizard, choose to 'Skip' the creation of the top-level web-site. This allows you to interpret the report of the Health Analyzer knowing that issues aren't related to any web sites that you have created.





Once complete, the Health Analyzer complains that 'The server farm account should not be used for other services.'



Enhancement 3: Use a new service account for Web Analytics.

Create a new service account for Web Analytics (e.g SharepointAnalyticsService). In Central Administration -> Security -> General Security --> Configure New Managed Accounts, register the new service account as a managed account. In Central Admin -> Security -> Configure Service Accounts, associated the account with the Web Analytics Data Processing Service. 




The Health Analyzer also complains that 'Built-In Accounts are used as application pool or service identities'.



Enhancement 4: Use a different service account for the Tracing Service


SPTraceV4 is the tracing service. A new service account cannot be assigned through Central Admin. Janis Norvelis has posted a solution using Powershell here, and there is a similar solution at blog.octavie.nl

Create a new Domain account, e.g. SharepointTrace and place it in the Performance Log Users group on the (all?) Sharepoint servers. Add it as a managed account in Sharepoint (see above). Then run this Powershell script.
       # Get the tracing service.
$farm = Get-SPFarm
$tracingService = $farm.Services | where {$_.Name -eq "SPTraceV4"}  

# Get the "farm" managed account.
$managedAccount = Get-SPManagedAccount "DOMAIN\SharepointTrace"

# Set the tracing service to run under the managed account.
$tracingService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$tracingService.ProcessIdentity.ManagedAccount = $managedAccount
$tracingService.ProcessIdentity.Update()

# This actually changes the "Run As" account of the Windows service.
$tracingService.ProcessIdentity.Deploy()

$tracingService.Update() # Not sure if this line is needed, but it did not hurt.


Enhancement 5: Use a different service account for Search

SPSearch4 is the Foundation Search Service, used for indexing the help system. It is configured to run as 'Local Service'.

Create a new service account (e.g. SharepointSearch) and register as a managed account (see above).

In Central Admin -> Security -> Configure Service Accounts, associated the account with the Sharepoint Foundation Search service.

To be tidy and consistent, also change the Sharepoint Server Search Service to use the new managed account. 

Go to Central Admin -> System Settings -> Manage Services on Server to check whether 'Sharepoint Foundation Help Search' is running and start it if necessary.


If you wait a while for the Health Analyzer to re-run (or manually kick off rule processing), then the warnings and errors about accounts should now be gone!

Resources:
http://sharepointgeorge.com/2010/installing-sharepoint-2010-privilege-service-accounts/

http://www.sharepointproconnections.com/article/sharepoint/Least-Privilege-Service-Accounts-for-SharePoint-2010.aspx

http://andreasglaser.net/post/2009/11/18/Installing-SharePoint-Server-2010-on-Windows-Server-2008-R2-and-SQL-Server-2008-R2-Part-5-Administrative-and-service-accounts.aspx

1 comment:

  1. 1) So, you are saying, if I used "domain admin" account to install SP, I should go back and start over? Ouch. At least, this is TEST only! And you are right, MICROSOFT NEEDS TO *FIX* ITS OWN INSTALLATION STEPS! FIRST step is to create that installation account; log in to the server as that account, then do the install.
    2) Would be nice if you told us "HOW" to "kick off rule processing."

    ReplyDelete

Please leave a comment.