Share via

Recommendations for SharePoint Setup User Account and SharePoint Farm Administrators Group

  • Article

SharePoint Setup User Account

Per Microsoft published TechNet guidance for SharePoint 2007/2010/2013, the Setup User Account must be a generic domain account that’s granted special permissions to perform initial SharePoint farm installation and configuration.  The Setup User Account  would be used to run setup to install SharePoint software on each server.  And then, to the run SharePoint Products Configuration Wizard to create new farm and join member servers to farm.  Why is the Setup User Account needed?  In the future when performing maintenance activities on the farm, the SharePoint Farm Administrator could encounter an out-of-the-ordinary Access Denied failure, for which logging in as original Setup User Account to perform the activity might be only possible resolution.  If the SharePoint farm was initially installed and configured by a user who logged in as their own user account and then that user later leaves the company causing their account to be deleted from Active Directory… then there may be no possible way to resolve such an Access Denied problem.

However after initial setup of the SharePoint farm is complete, I recommend my customers inactivate the Setup User Account in Active Directory so interactive logon is not possible, but leave all permissions granted to account intact.  Then in future if that account is needed quickly to resolve a troublesome Access Denied issue with maintaining the farm, simply re-active the account in AD and all necessary permissions are still effective.  I also recommend following…

SharePoint Farm Administrators Group

Recommend: To perform any ongoing maintenance to the SharePoint farm, avoid routine practice where SharePoint Farm Admins need to login interactively using SharePoint Server Farm Service account (or the Setup User Account). Move toward better practice where Farm Admins login interactively using their individual user accounts to perform their day-to-day duties.  Why?

• Security best practice is to not permit service accounts to be routinely used for interactive login by any user.   One reason is service accounts typically have very high privilege, usually more than is required by the user (doesn’t follow the least privilege security model). 
 
• Security best practice is to never allow users to share accounts.   Such sharing (such as by multiple farm admins) of a service account for interactive login makes it harder to audit who actually did what after-the-fact.

Recommend:   I have suggested that my customers establish role-based global groups in AD for SharePoint Farm Admins.  I recommend they create at least 2 SharePoint Farm Administrators groups in AD, 1 for production & 1 for non-production farms (dev, QA, etc).  The individual user accounts of each Farm Admin are then added as a members into the AD group.  When a Farm Admin is no longer in the role, you simply remove that user from AD group and all inherited permissions are automatically removed.

For example, SharePoint Farm Administrators Global Groups:
CONTOSO\SP15FarmAdminDev-G   
CONTOSO\SP15FarmAdminProd-G   

Grant the AD group necessary SharePoint Farm Administrator permissions:

  • Add to SharePoint_Shell_Access role ("Add-SPShellAdmin CONTOSO\SP15FarmAdminDev-G")
  • Logon Interactive Windows user right for each SharePoint Server
  • Member of local Windows Administrators group on all SharePoint servers
  • OPTIONAL: Granted Full Control permissions for each SharePoint web application via user policy
  • Grant Logins privilege for SQL Server
  • Grant SecurityAdmin and DBCreator fixed server roles in SQL Server
  • Grant db_owner role to any existing SharePoint databases

Recommend: In future when SharePoint Farm Admins use Central Admin or PowerShell/STSADM to create a new content database, they should also submit a change request to DBA to grant the Farm Admins group the db_owner role privilege on that new DB. Otherwise, they will encounter Access Denied problems when trying to manage the content within the DB.  Plus the change request alerts the DBA that a new database has been created in SharePoint.

ADDITIONAL REFERENCES

Choose administrators and owners for the administration hierarchy in SharePoint 2013
https://technet.microsoft.com/en-us/library/cc263291.aspx

Plan for administrative and service accounts in SharePoint 2013
https://technet.microsoft.com/en-us/library/cc263445.aspx