Sharepoint 2016 Farm Service Account SQL Permissions

Question

We have recently installed Sharepoint 2016. Our installation has followed Microsoft's recommendations (https://technet.microsoft.com/nl-nl/library/ee662513(v=office.16).aspx ) regarding Service Account least privilege and as such the farm service account and install service account are granted the DBCreator and SecurityAdmin roles on SQL server.

Once the farm installation and configuration process has been completed we have noticed that the farm service account appears to have been granted the 'Control Server' permission level in SQL server.

This must have been granted as part of the installation or PSconfig process at some point. Understandably our SQL DBA's are slightly concerned that this is an elevated privilege that is close to full Sysadmin access in SQL and presents some security concerns.

We have seen that this permission level has been granted to the farm service account on each of our Sharepoint server farms (Dev, Test, Prod) so this does not seem to be a one-off anomaly.

There does not appear to be any reference to this permission level being granted to the farm service account in any of Microsoft's documentation.

The question is, should we try and remove the permission from the service account? Would it be likely to cause any issues for us? Has anybody else noticed this on their Sharepoint farms?

Answer 1

CONTROL SERVER always granted on Timer Service creation (e.g. new SPFarm creation).
It's granted to Timer Service principal (which is Farm Account).
As far as I know, the behavior is the same in SP2013.
You can revoke it and execute below script to reproduce granting CONTROL SERVER:

$farm = Get-SPFarm
$dbService = $farm.Services | ? {$_.TypeName -like 'Microsoft SharePoint Foundation Database'}
$dbServiceInstance = $dbService.Instances | select -First 1

if ($dbServiceInstance.EnsurePermissionsOnUpdate) {
   Write-Output ("CONTROL SERVER role will be granted to '{0}' on SPDatabaseServiceInstance.Update()" -f $farm.TimerService.ProcessIdentity.Username)
}
else {
   Write-Output ("Flag to grant CONTROL SERVER on SPDatabaseServiceInstance.Update() is not set")
}

$dbServiceInstance.Update()

Answering your questions: removing CONTROL SERVER will likely cause issues with one or more timer jobs which may do some kind of SQL maintenance (maybe something related to Availability Groups). Unfortunately, I don't know the exact timer job which uses this permission.
Also this permission may be reassigned anytime on Update() method call (as shown above) as part of new CU installation.

Show your DBAs this article and especially this part:

I'd recommend you to leave this permission in place and use dedicated SQL Instance for SharePoint (which is also a best practice).