Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

This article describes how to configure and maintain a Microsoft SharePoint Foundation 2010 farm by using least-privileged administration.

Overview

The concept of least-privileged administration assigns users the minimum permissions that are required for users to complete authorized tasks. The goal of least-privileged administration is to configure and help maintain secure control of an environment. The result is that each service is granted access to only the resources that are absolutely necessary. Implementing least-privileged administration can result in increased operational costs because additional resources might be required to maintain this level of administration. Moreover, the ability to troubleshoot security problems can also be diminished.

securitySecurity Note
Organizations implement least-privileged administration to achieve better security than would be typically recommended. Only a small percentage of organizations require this heightened level of security because of the resource costs of maintaining least-privileged administration. However, some deployments that might require this heightened level of security include governmental agencies, security organizations, and organizations in the financial services industry. The implementation of a least-privileged environment should not be confused with best practices. In a least-privileged environment, administrators implement best practices together with additional heightened levels of security is performed.

Least-privileged environment for accounts and services

To plan for least-privileged administration, you must consider several accounts, roles, and services. Some apply to SQL Server and some apply to SharePoint 2010 Products. As administrators lock down additional accounts and services, daily operational costs are likely to increase.

Microsoft SQL Server roles

In a least-privileged administration environment, we recommend that you remove the following two SQL Server server-level roles from accounts that are not SharePoint service accounts, but are used for SharePoint administration:

  • dbcreator- Members of the dbcreator fixed server role can create, alter, drop, and restore any database.

  • securityadmin- Members of the securityadmin fixed server role manage logins and their properties. They can GRANT, DENY, and REVOKE server-level permissions. They can also GRANT, DENY, and REVOKE database-level permissions if they have access to a database. Additionally, they can reset passwords for SQL Server logins.

    securitySecurity Note
    The ability to grant access to the Database Engine and to configure user permissions allows the security admin to assign most server permissions. The securityadmin role should be treated as equal to the sysadmin role.

For additional information about SQL Server server-level roles, see Server Level Roles (https://go.microsoft.com/fwlink/p/?LinkId=213450)

The removal of one or more of these SQL Server roles might cause “Unexpected” error messages that will be displayed in the Central Administration Web site. In addition, you may receive the following message in the Unified Logging Service (ULS) log file:

System.Data.SqlClient.SqlException… <operation type> permission denied in database <database>.  Table <table>

Along with an error message that may be displayed, the user may be unable to perform any of the following tasks:

  • Restore a backup of a farm due to the inability to write to a database

  • Provision a service instance or Web application

  • Configure managed accounts

  • Change managed accounts for Web applications

  • Any database, managed account, or services operation that requires the use of the Central Administration Web site

In certain situations, database administrators (DBAs) may want to operate independently from SharePoint administrators and create and manage all the databases. For information about how DBAs create and manage all databases, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

SharePoint Foundation 2010 roles and services

In general, the ability to create new databases should be removed from SharePoint service accounts. No SharePoint service account should have the sysadmin role on the Microsoft SQL Serverinstance and no SharePoint service account should be a local Administrator on the server that runs Microsoft SQL Server.

However, you could lock down several other SharePoint Foundation 2010 services and accounts:

  • SharePoint_Shell_Access role

    When this Microsoft SQL Server role is removed, the ability to write entries to the configuration and content database is removed. For additional information about this role, see Add-SPShellAdmin.

  • SharePoint Timer service (SPTimerV4)

    By default, this service is installed and maintains configuration cache information. If the service type is set to disabled the following behavior may occur:

    • No timer jobs will run

    • Health analyzer rules will not run

    • Maintenance and farm configuration will be out of date

  • SharePoint Administration service (SPAdminV4)

    This service performs automated changes that require local administrator permission on the server. When the service is not running, you must manually process server-level administrative changes. If the service type is set to disabled, the following behavior may occur:

    • Administrative timer jobs will not run

    • Web configuration files will not be updated

    • Security and local groups will not be updated

    • Registry values and keys will not be written

    • Services may be unable to be started or restarted

    • Provisioning of services may be unable to be completed

  • SPUserCodeV4 Service

    This service lets a site collection administrator upload sandboxed solutions to the Solutions gallery. For additional information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

For more information services, see SharePoint Administration service is disabled (SharePoint 2010 Products).

Depending on an organization's business requirements, if any SharePoint Foundation 2010 services or roles are implemented, the behavior to the following features may occur:

  • Backup and restore

    The ability to perform a restore from a backup may fail if database permissions have been removed.

  • Upgrade

    The upgrade process will start correctly, but then fail as you do not have suitable permissions to databases. If your organization is already in a least-privileged environment, the workaround is move to a best practices environment to complete the upgrade, and then move back to a least-privileged environment.

  • Update

    The ability to apply a software update to a farm will succeed for the schema of the configuration database, but fail on the content database and services.

Additional requirements to consider

In addition to the preceding considerations, you might have to consider more operations. The following list is not complete. Selectively use the items at your own discretion:

  • Setup user administrator account- This account is used to set up each server in a farm. The account must be a member of the Administrators group on each server in the Microsoft SharePoint Server 2010 farm. For additional information about this account, see Administrative accounts

  • My Site host application pool account- This is the account under which the My Site application pool runs. To configure this account, you need to be a member in the Farms Administrators group.

  • Built-in user group- Removing the built-in user security group or changing the permissions may have unanticipated consequences.

  • Group permissions-By default the WSS_ADMIN_WPG SharePoint group has read and write access to local resources. The following WSS_ADMIN_WPG file system locations, %WINDIR%\System32\drivers\etc\HOSTS and %WINDIR%\Tasks are needed for Microsoft SharePoint Foundation to work properly. If other services or applications are running on a server, you may consider how they access the Tasks or HOSTS folder locations. For additional information about account settings, see Account permissions and security settings (SharePoint Server 2010)

  • Change permission of a service- A change of a permission of a service may have unanticipated consequences. For example, if the following registry key, HKLM\System\CurrentControlSet\Services\PerfProc\Performance\Disable Performance Counters, has the value of 0, the User Code Host service would be disabled which would cause sandboxed solutions to stop working. For additional information about the User Code service not working, see The SharePoint 2010 User Code Host service fails to start (https://go.microsoft.com/fwlink/p/?LinkId=225642)