SharePoint 2013 Deployment - Critical Security Issue: Server Farm Account Should Not be Used for Other Services

Deploying SharePoint 2013 is not overly difficult when setting up a demonstration environment or a test environment, especially when you’re following all the default steps.  However, it is certainly a more involved and complex task when deploying a Production or hardened environment.  

One of the post deployment steps we typically need to perform, which is not immediately obvious, is to resolve a critical security issue which is reported by the SharePoint Health immediately following the default SharePoint 2013 deployment steps.

One of the critical steps in deploying SharePoint 2013 is to specify the Farm Administrator account.  This is the account that will be used by an administrator of the entire farm to access SharePoint Central Admin and modify farm level features and settings.  This account has access to absolutely all features and settings in SharePoint.  In the SharePoint installation/configuration wizards this is referred to as the Database Access Account.  Our best practices tell us that, before installing the SharePoint server, we should create a managed domain account to use as the Farm Administrator account, and not use a personal account.  As well, best practices tell us to create separate managed domain accounts for our setup user account (to use when installing SharePoint and deploying service packs or updates) and to create a separate managed domain account for our SQL Server Service account.  This is certainly a sound best practice that I recommend following in order to deploy SharePoint using a least privilege approach.

However, even when following this best practice and running the SharePoint 2013 installation/configuration wizards, this process will create an issue that appears in the SharePoint Health Analyzer in Central Admin immediately after the deployment is complete.  Immediately after the installation and configuration process, the first time you login to SharePoint Central Admin you’ll see the following critical security issue reported in the Health Analyzer:

If we click on this issue and look at the details reported we see:

The details describe that the farm account specified as part of the initial installation is used as the service account for the Distributed Cache Service.  It goes on to say that the Farm Administrator account is a highly privileged account, and as such it should not be used as the service account for any other services on any servers in the SharePoint farm.  Fair enough – this fits with our best practice of using least privileged accounts when deploying and running SharePoint.  I do find it odd that the SharePoint installation/configuration wizards made this configuration by default and therefore created this critical security issue.  However, this health analyzer report gives us a handy link where we can immediately go modify the service account used for this service and resolve this issue.

However, trying to do so will not work!

Following this link will take us to the Service Accounts page in Central Admin where we can select the Distributed Cache Service and change the account used for this component, as the Health Analyzer report suggested:

However, when we do this we get the following error:

If we then follow the correlation ID into the ULS log to see what happened, we see the following error reported:

Application error when access /_admin/FarmCredentialManagement.aspx, Error=Distributed Cache Service does not support this operation from Central Administration. Please use Sharepoint Powershell commandlets.   at Microsoft.SharePoint.ApplicationPages.FarmCredentialManagementPage.ProcessSubmit()     at Microsoft.SharePoint.ApplicationPages.FarmCredentialManagementPage.BtnSubmit_Click(Object sender, EventArgs args)     at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)          a1d8b19c-44e2-d0c1-1dc7-c032ea61f186


So, even though the Health Analyzer gives us this handy link where we can modify this critical security issue that was caused by default for us by the SharePoint installation/configuration wizards  ;-)  the page does not allow us to make this change.  We need to use PowerShell to change the associated service account. 

As well, there is another much less obvious issue here because the issue ultimately is not with the Distributed Cache Service.  The Distributed Cache Service depends on the App Fabric Caching Service and when the farm is deployed using the SharePoint installation/configuration wizards the Farm Administrator account is set as the service account for the AppFabric Caching Service.  It is the service account assigned to the AppFabric Caching Service that needs to be modified to resolve this issue and the only way to do that is through PowerShell.

To modify the service account assigned to the AppFabric Caching Service you can follow these steps:

1.       Create a managed account to use either specifically for the AppFabric Caching Service or generally for all SharePoint services.

2.       Set the Managed account as the service account on the AppFabric Caching service by launching the SharePoint Management Shell command prompt and running the following commands:

$farm = Get-SPFarm

$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}

$accnt = Get-SPManagedAccount -Identity domain_name\user_name

$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"

$cacheService.ProcessIdentity.ManagedAccount = $accnt

$cacheService.ProcessIdentity.Update()

$cacheService.ProcessIdentity.Deploy()

 

Ensure that you substitute domain_name\user_name with the domain name and user name of the managed account

This post deployment step will help us to follow our best practice of using least privileged accounts when deploying and running SharePoint by ensuring that a SharePoint service is not using the highly privileged Farm Administrator account.  As well, it will resolve the reported Health Analyzer’s critical security issue.  You will need to wait until the Health Analyzer rules run again in order to clear the reported issue.

   -Antonio