Share via

SharePoint 2013: Group Policy Considerations for a SharePoint Farm

  • Article

Introduction

In this posting, I discuss major group policy settings that you should attend to as the administrator of a SharePoint farm. The major group policy settings that you should engage with your network system managers involve security settings:

  • Service account security settings,
  • Network storage security settings,
  • Local security settings and
  • Firewall settings.

If you do not build your knowledge of these topics, you may encounter highly arcane and deeply perplexing performance issues and failures that appear to have no immediate cause you can quickly point to and resolve.

Your GPO is likely pushed out on a regular basis (eg, every half hour), so, it may overwrite any settings changes implemented by an installer or configuration wizard. The problem is that Microsoft has not documented these various security settings needed by SharePoint service accounts and processes down to the level discussed here. This is also one of the reasons I believe why Microsoft strongly recommends that you perform all installation and subsequent configuration using the SharePoint Setup User Administrator account (eg, spAdmin): this account is used to configure a wide variety of registry entries and folders and is granted the permission to edit these as necessary. Your administrator account will not be.

The discussion in this posting has been developed over the course of extensive searches, numerous production system troubleshooting efforts, and careful testing and monitoring. This posting integrates and compiles these sources of information. This posting is not meant to be authoritative, but has been developed empirically and in all likelihood can be improved. Therefore, critical comments and suggestions are welcome in order to improve it to the benefit of the SharePoint technical community.

Service Account Security Settings

It is best, from a least-permissions perspective, to use individual service accounts for each of the primary SharePoint farm services, such as the farm service itself, web application pools, SQL Server service, Search Service, etc. The reason being that each time a service account is used for a service, that account is granted the set of permissions it needs to run that service. These permissions may vary from service to service. If one account is used for all services, that account may run a service with more permissions than it needs, potentially creating a security vulnerability. For example, the farm service runs under significantly greater permissions than are needed to run the Search service. If the farm service account were also used for the crawl service, crawling could potentially surface content that shouldn't be.

All service accounts used in your farm should be domain service accounts.

Some of these service accounts must have the AD read permission in order to be able to read the properties of all the other service accounts. Such accounts needing this permission include:

  • Farm service account
    • Must be able to read the AD account security settings of all other SharePoint service accounts.
  • SQL server agent account (the account you assign to run your SQL server)
    • Must be able to read the AD account security settings of the account you log in as to create SQL Server maintenance plans and the service account used to run the Workflow Manager 1.0 subsystem.
  • User profile service account (the service account used to run UPA)
    • Must have the AD replicate directory changes permission.

For example, if you will be creating SQL Server backup maintenance plans, you must give the the SQL Server service account the permission to read the domain account that you logged in as to create these maintenance plans. Additionally, if you will be deploying Workflow Manager 1.0, the SQL Server agent account (eg, spSQL) must also be able to read the AD properties of the workflow service account, otherwise Workflow Manager 1.0 configuration will fail.

See the following for recommendations on service account rights:

Network Storage Folder Security Settings

The search service account needs RW permission to the network folder you use to store farm backups (the backups created either through CA or via PowerShell). If it does not have this, a backup performed through CA or via PowerShell will succeed in everything except the Search portion. This was not the case for 2010. Why the search service account now needs to touch a backup folder is completely beyond me.

Local Security Policy Settings

Inadequate local security policy settings, specifically, inadequate user rights assignments, will present extremely challenging troubleshooting problems to the SharePoint systems administrator to resolve. Their affects are subtle and the error messages that they cause are frequently unhelpful, but may yield to determined and persistent effort. For example, if the service account running your sandbox process is in adequately configured, you may see error messages repeatedly appear in the ULS log that contain what are called Privilege Constants - seeing one of these in an error messages is pretty strong evidence of inadequate user rights assignments. For another example, an inadequately configured search service account may result in performance degradation that may vary in severity depending on the number and type of user rights assignments that have been granted to it. Listed below are typical SharePoint service accounts and the user rights assignments found to be necessary to their operation.

  • Farm service account (eg, spAdmin)
    • Adjust memory quotas for a process
    • Allow log on locally
    • Impersonate a client after authentication
    • Log on as a batch job
    • Log on as a service
    • Replace a process level token
  • Application service account (web application pool servide account, eg, spApp)
    • Impersonate a client after authentication
    • Log on as a batch job
    • Log on as a service
  • Service service account (services pool, eg, spService)
    • Adjust memory quotas for a process
    • Impersonate a client after authentication
    • Log on as a batch job
    • Log on as a service
    • Replace a process level token
  • Search Service account
    • Adjust memory quotas for a process
    • Impersonate a client after authentication
    • Replace a process level token
    • Logon as a batch job
  • SQL server agent account
    • Adjust memory quotas for a process
    • Bypass traverse checking
    • Log on as a service
    • Replace a process-level token
  • workflow manager 1.0 service account
    • Impersonate a client after authentication
    • Log on as a service
    • Log on as a batch job

You can discover many of these settings yourself, by simply performing exports of Local User Rights Assignments immediately after performing a fresh new deployment to a server, inc.uding running the configuration wizard (or doing this via PowerShell). The configuration wizard sets these for SharePoint and they will be visible until your next GPO refresh.

Firewall Settings

You need to make sure that the Windows Firewall on your SQL Server instance(s), and really on all servers for that matter, has appropriate rules configured to allow inbound and outbound traffic.

Notes

  • The SQL Server Agent service account needs to be able to ready the AD properties of the Workflow Manager 1.0 service account for the successful deployment of SharePoint Server 2013 Workflow Manager. This permission should be granted to whatever account you have running the SQL Server Service, be it Local Service or what not. If you do not grant this permission, your Workflow Manager configuration will fail on the first step with error message:

    Could not obtain information about Windows NT group/user '{your workflow service account}', error code 0x5.

    When you then look at the log file for the workflow deployment, you see this conclusive message:

    ...System.Data.SqlClient.SqlException: Could not obtain information about Windows NT group/user '{your workflow service account}', error code 0x5...

  • SQL Server Maintenance Plans: The account that you used to login to SQL Server and create the scheduled farm database maintenance plans seems to be what actually runs the maintenance plan. For example, if you logged into SQL Server Management Studio as the farm service account, and then created the farm database scheduled maintenance plans while logged in as this account, you would grant the SQL Server service account (eg, spSQL) AD Read permission to the farm service account. If you do not grant the AD Read permission, you will experience the following SQL Server error when attempting to execute a maintenance plan:

    [date] [time],,Error,[298] SQLServer Error: 15404<c/> Could not obtain 
information about Windows NT group/user [Account you are logged in as
]<c/> error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

  • AD Read. This Service Permission grants the ability to the farm service account to be able to read critical account security informaton, such as account restrictions. Note that this permission is actually composed of a number of sub-permissions, including the Read account restrictions permission, which is critical. I'm not presently sure which other specific read subpermissions are necessary, so, simply selecting Read covers all the bases.

  • SharePoint Service Account User Rights Assignments: I have not been able to find any definitive, office Microsoft presentation of Local Security Policy user rights assignments for SharePoint 2007, 2010 or 2013. I did find them for SharePoint Portal Server 2003. Microsoft's TechNet pages for account permissions and security setting for SharePoint 2007, 2010 and 2013 do not discuss user rights assignments at all. On the other hand, Microsoft does provide these critical settings for another flagship application, SQL Server, doing so from SQL Server 2000 through 2012. Thus, obivously, Microsoft recognizes the importance of these settings to its applications. It's thus very unclear why Microsoft has failed to disclose these critical settings for SharePoint, as these settings play just as critical a role in the successful deployment and performance of SharePoint as they do for SQL Server.

  • Determining User Rights Assignments: If you're not sure what user rights assignments are being configured, you can determine them by: 1) performing a configuration change and then 2) opening the local Security Policy on the local machine (most likely the Application or Batch server), and then viewing User Rights Assignments - do an export to save these for reference. Repeat this after every new application and service instantiation and you will build up a pretty good understanding of what is being configured here. NOTE: if you have GPO pushed out regularly, you will need to view and export these assignments quickly - before the GPO is pushed out again, as this will overwrite these assignments.

  • If your AD environment doesn't control user rights assignments via GPO, you don't need to configure these yourself as they are done automatically for you by the SharePoint Products Configuration Wizard.