Apr 14

Claims to Windows Token Service Identity

 C2WTSClaims to Windows token Service plays a very important role in SharePoint 2010 Kerberos delegation. It is a part of .Net Windows Communication Framework. It needs to be running on SharePoint application server in order for a SharePoint service to be able to get a User Windows token in exchange for a UPN (user principal name) claim. SharePoint uses claims for inter-farm communication. To authenticate to a service outside SharePoint farm that is not claims-aware, SharePoint needs to obtain a windows token to use for authentication. In the case of Kerberos delegation this token is then used to get Service ticket to present to the target service. The diagram here is a simplification of the complete process to highlight the role of C2WTS. For full details of Kerberos protocol mechanism, please refer to a far more serious source on Microsoft Technet

When C2WTS is not working properly, no delegation is possible, all calls to external services would fail. Inside SharePoint this failure would result in errors such as the following (see Rodney Viana’s blog):

"Could not retrieve a valid windows identity for NTName='Domain\Joe.Bloggs', 
UPN='Joe.Bloggs@Domain.com'. UPN is required when Kerberos constrained delegation is used."

Widely referred to Microsoft whitepaper on configuring Kerberos for SharePoint suggests changing the identity of Claims to Windows Token Service (C2WTS) to an active directory service account. While this seems like a good idea at first it may cause problems with stability of the service. It does not actually achieve anything in terms of making the configuration more secure as the account must be a member of the host local administrator group for the C2WTS to function correctly, so my recommendation is: leave it be as Local Service. Should you wish to change the delegation properties of other attributes for the identity of the service, please use the host computer account.

I had a case of C2WTS becoming unstable after changing identity from default Local System to an active directory account when configuring Kerberos constrained delegation for a SharePoint 2010 and SQL Server 2012 installation recently. Straigt after (re)start, the service would operate correctly, duly returning a windows token for a UPN claim, but after a few minutes it would inevitably get tired and begin returning an error, as if the user does not exist.

Changing the service identity back to Local System solved this problem: the system has been working reliably for many months now. Changing the identity back to a AD account brings back to problematic behaviour. 

Please bear in mind that if you have changed the identity of Claims to Windows Token Service in SharePoint, you need to tell SharePoint of your decision to undo that change. You can do so using SharePoint PowerShell console:

Get-SPServiceInstance | Where {$_.TypeName.StartsWith("Claims")} | 
ForEach-Object {
$_.Service.ProcessIdentity.CurrentIdentityType = 0;