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
- 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.
- 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.
Strictly Avoid Special Characters – Do not use service account names that contain anything other than _.
|1||svcSPSetup||The Setup user account is used to
a. Install SharePoint
b. Run the following: Setup SharePoint Products Configuration Wizard
|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.||
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.|
|7||svcSPCrawl||This account is used for default content access account for Search Crawling||
|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||
|12||svcSPCacheSuperRdr||Cache Super Reader||
|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
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
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”
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:
- Add the service account to the local Administrators Groups.
In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:
- Act as part of the operating system
- Impersonate a client after authentication
- 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.