In part 4, I showed you how to install SharePoint 2016 and we stopped at running Products & Configuration wizard. And before we complete our configuration, we need to ensure the following service accounts are created for using against various service applications. Some of the best practices of creating SharePoint Service Accounts are

  1. Use Password Never Expires – All service accounts should be set to “Password never expires” in Active Directory because if they expire in future after installation of SP2016 it would be an issue for the continued operations of SharePoint.
  2. Place all Service Accounts in single OU – This placement allows system administrators to easily locate and view service accounts, group them in one Active Directory OU.
  3. Strictly Avoid Special Characters – Do not use service account names that contain anything other than _.
#

Account

Description

Access Level

1 svcSPSetup The Setup user account is used to

a. Install SharePoint

b. Run the following: Setup SharePoint Products Configuration Wizard

  1. Member of the Administrators group on each server on which SharePoint Setup is run.
  2. SQL Server login on the computer that runs SQL Server.
  3. Member of the following SQL Server roles:
    1. securityadmin fixed server role
    2. dbcreator fixed server role
  4. If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
2 svcSPFarm The Server farm account or database access account. The server farm account is used to configure and manage the server farm. And acts as the application pool identity for the SharePoint Central Administration Web site.
  1. Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
  2. The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:
    1. dbcreator fixed server role
    2. securityadmin fixed server role
    3. db_owner fixed database role

for all SharePoint databases in the server farm

3 svcSPApp This account is used for Content Web Application. None unless using Office Web Apps. Then must give access to content databases manually.
4 svcSPService This account is used for Service Application Pool. Must be a member of the Farm Administrators group.
5 svcSPMySite This account is used for My Site Application Pool. This account must not be a member of the Administrators group on any computer in the server farm.
6 svcSPSearch
7 svcSPCrawl This account is used for default content access account for Search Crawling
  1. The default content access account must be a domain user account that has read access to external or secure content sources that you want to crawl by using this account.
  2. For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.
  3. This account must not be a member of the Farm Administrators group.
8 svcSPWorkFlow This account is used for SharePoint Workflow Manager Service
9 svcSPC2WTS This account is used for Claims to Windows Token Service Must be a member of the Farm Administrators group.
10 svcSPUPSync User Profile Synchronization Connection Service Account Member of the Administrators group on each server on which SharePoint Setup is run.
11 svcSPCacheSuperUsr Cache Super User
  • The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  • These accounts should not have any special Active Directory privileges other than Domain User membership
12 svcSPCacheSuperRdr Cache Super Reader
  1. The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  2. These accounts should not have any special Active Directory privileges other than Domain User membership
13 svcSPSSRS SQL Server Reporting Services Service Application Account
14 svcSPPPS Performance Point Services Service Application Account

In addition to the above configuration, there are some special configuration changes required for claims to windows token service account to be done on each SharePoint server. The Claims to Windows Token Service (C2WTS) is a component of the Windows Identity Foundation (WIF) which is responsible for converting user claim tokens to windows tokens. Excel services uses the C2WTS to convert the user’s claims token into a windows token when the services needs to delegate credentials to a back-end system which uses Integrated Windows authentication.

Each SharePoint service application must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity

As a best practice you should run the C2WTS using a dedicated service account and not as Local System (the default configuration). But Local System will work if you configure the Kerberos constrained delegation to use the machine name account. The C2WTS service account requires special local permissions on each server the service runs on so be sure to configure these permissions each time the service is started on a server. Optimally you should configure the service account’s permissions on the local server before starting the C2WTS, but if done after the fact you can restart the C2WTS from the Windows services management console (services.msc).

To start the C2WTS using Domain Account

  1. Add an arbitrary Service Principal Name (SPN) to the service account to expose the delegation options for this account in Active Directory Users and Computers. The SPN can be any format because we do not authenticate to the C2WTS using Kerberos authentication. It is recommended to not use an HTTP SPN to avoid potentially creating duplicate SPNs in your environment. In our example, we will have registered ‘SP/C2WTS’ to the ‘infrafusion\svcspC2WTS’ using the following command:

    SetSPN -S SP/C2WTS infrafusion\svcspC2WTS

  2. Configure Kerberos constrained delegation on the C2WTS services account. In his scenario we will delegate credentials to the SQL service running with the ‘MSSQLSVC/NACDB02.infrafusion.xyz:1433’ service principal name.

    Key configuration options on the delegation tab are the following:

    a) Select “Trust this user for delegation to specified services only”

    b) Select “Use any authentication protocol”

  3. Next, configure the required local server permissions that the C2WTS requires. You will need to configure these permissions on each server the C2WTS runs on. In our example this is VMSP10APP01. Log onto the server and give the C2WTS the following permissions:
    1. Add the service account to the local Administrators Groups.
    2. In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:
      1. Act as part of the operating system
      2. Impersonate a client after authentication
      3. Log on as a service

This will prepare Claims to Windows Service Account to be used with SharePoint 2016 after the configuration is completed.

In this post, we configured service accounts with their appropriate access. In the next post, we will run the product & services configuration wizard and configure each Service Application to use their designated service account. Till then, keep watching this space.