C2wts claims to windows token service

description	title	author	ms.author	ms.service	ms.topic	ms.date
Claims to Windows Token Service (c2WTS) and Reporting Services	Claims to Windows Token Service (c2WTS) and Reporting Services | Microsoft Docs	maggiesMSFT	maggies	reporting-services	conceptual	09/09/2021

Claims to Windows Token Service (C2WTS) and Reporting Services

[!INCLUDE ssrs-appliesto] [!INCLUDEssrs-appliesto-2016-and-later] [!INCLUDEssrs-appliesto-sharepoint-2013-2016i] [!INCLUDEssrs-appliesto-pbirsi]

The SharePoint Claims to Windows Token Service (C2WTS) is required if you want to view native mode reports within the SQL Server Reporting Services Report Viewer web part.

C2WTS is also required with SQL Server Reporting Services SharePoint mode if you want to use Windows authentication for data sources that are outside the SharePoint farm. C2WTS is needed even if your data source(s) are on the same computer as the shared service. However in this scenario, constrained delegation is not needed.

[!NOTE]
Reporting Services integration with SharePoint is no longer available after SQL Server 2016.

Report Viewer (Native Mode) web part configuration

The Report Viewer web part is a custom web part that can be used to view SQL Server Reporting Services (native mode) reports within your SharePoint site. You can use the web part to view, navigate, print, and export reports on a report server. The Report Viewer web part is associated with report definition (.rdl) files that are processed by a SQL Server Reporting Services report server or a Power BI Report Server. This Report Viewer web part can’t be used with Power BI reports hosted in Power BI Report Server.

SharePoint Server 2013, SharePoint Server 2016, and SharePoint Server 2019 all make use of claims authentication. As a result, C2WTS needs to be configured properly and Reporting Services needs to be configured for Kerberos authentication for reports to render correctly.

1. Configure your Reporting Services (Native Mode) instance for Kerberos Authentication by determining the SSRS Service account, setting an SPN, and updating the rsreportserver.config file to use RSWindowsNegotiate Authentication Type. Register a Service Principal Name (SPN) for a Report Server

2. Follow steps from Steps needed to configure c2WTS

SharePoint mode integration

This section only applies to SQL Server 2016 Reporting Services and earlier.

The SharePoint Claims to Windows Token Service (C2WTS) is required with SQL Server Reporting Services SharePoint mode if you want to use Windows Authentication for data sources that are outside the SharePoint farm. This is true even if the user accesses the data sources with Windows Authentication because the communication between the web front-end (WFE) and the Reporting Services shared service will always be Claims Authentication.

Steps needed to configure c2WTS

The tokens created by C2WTS will only work with constrained delegation (constrains to specific services) and the configuration option «using any authentication protocol»(Protocol Transition).

If your environment will use Kerberos constrained delegation, then the SharePoint Server service and external data sources need to reside in the same Windows domain. Any service that relies on the Claims to Windows token service (c2WTS) must use Kerberos constrained delegation to allow c2WTS to use Kerberos protocol transition to translate claims into Windows credentials. These requirements are true for all SharePoint Shared Services. For more information, see Plan for Kerberos authentication in SharePoint 2013.

1. Configure the C2WTS service domain account.

   As a best practice C2WTS should run under its own domain identity.

   • Create an Active Directory account and register the account as a managed account in SharePoint Server.

   • Configure C2WTS Service to use the managed account through SharePoint Central Administration > Security > Configure Service Accounts > Windows Service — Claims to Windows Token Service

   Add the C2WTS service account to the local Administrators group on each server that C2WTS will be used. For the Report Viewer web part, this will be the Web Front End (WFE) servers. For SharePoint integrated mode, this will be the application servers where the Reporting Services service is running.

   • Grant the C2WTS account the following permissions in the local security policy under Local Policies > User Rights Assignment:
     • Act as part of the operating system
     • Impersonate a client after authentication
     • Log on as a service

2. Configure delegation for the C2WTS service account.

   The account needs Constrained Delegation with Protocol Transitioning and permissions to delegate to the services it is required to communicate with (i.e. SQL Server Database Engine, SQL Server Analysis Services). To configure delegation you can use the Active Directory Users and Computer snap-in and will need to be a domain administrator.

   [!IMPORTANT]
   Whatever settings you configure for the C2WTS service account, on the delegation tab, needs to match the main service account being used. For the Report Viewer web part, this will be the service account for the SharePoint web application. For SharePoint integrated mode, this will be the Reporting Services service account.

   For example, if you allow the C2WTS service account to delegate to a SQL Service, you need to do the same on the Reporting Services service account for SharePoint integrated mode.

   • Right-click each service account and open the properties dialog. In the dialog click the Delegation tab.

     The delegation tab is only visible if the object has a Service Principal Name (SPN) assigned to it. C2WTS does not require an SPN on the C2WTS Account, however, without an SPN, the Delegation tab will not be visible. An alternative way to configure constrained delegation is to use a utility such as ADSIEdit.

   • Key configuration options on the delegation tab are the following:

     • Select Trust this user for delegation to specified services only
     • Select Use any authentication protocol

   • Select Add to add a service to delegate to.

   • Select Users or Computers…* and enter the account that hosts the service. For example, if a SQL Server is running under an account named sqlservice, enter sqlservice.
     For the Report Viewer web part, this will be the service account for the Reporting Services (Native Mode) Instance.

   • Select the service listing. This will show the SPNs that are available on that account. If you don’t see the service listed on that account, it may be missing or placed on a different account. you can use the SetSPN utility to adjust SPNs. For the Report Viewer web part, you will see the http SPN configured in Report Viewer web part configuration.

   • Select OK to get out of the dialogs.

3. Configure C2WTS AllowedCallers.

   C2WTS requires the ‘callers’ identities explicitly listed in the configuration file, C2WTShost.exe.config. C2WTS does not accept requests from all authenticated users in the system unless it is configured to do so. In this case the ‘caller’ is the WSS_WPG Windows group. The C2WTShost.exe.confi file is saved in the following location:

   Changing the service account within SharePoint Central Admin, for the C2WTS service, will add that account to the WSS_WPG group.

   Program FilesWindows Identity Foundationv3.5c2WTShost.exe.config

   The following is an example of the configuration file:

   <configuration>
     <windowsTokenService>
       <!--  
           By default no callers are allowed to use the Windows Identity Foundation Claims To NT Token Service.  
           Add the identities you wish to allow below.  
         -->
       <allowedCallers>
         <clear/>
         <add value="WSS_WPG" />
       </allowedCallers>
     </windowsTokenService>
   </configuration>
   

4. Start (stop and start if already started) the Claims to Windows Token Service through SharePoint Central Administration on the Manage Services on Server page. The service should be started on the server that will be performing the action. For example if you have a server that is a WFE and another server that is an Application Server that has the SQL Server Reporting Services shared service running, you only need to start C2WTS on the Application Server. C2WTS is only required on a WFE server if you are running the Report Viewer web part.

More questions? Try asking the Reporting Services forum

Posted On December 30, 2018

Update: 3/31/22 — Added a reference to a related post from my colleague Mike: Unable to start the C2WTS

Update: 8/5/19 — Made an amendment to Fact #3.

Facts:

1. The Claims to Windows Token Service (from here on denoted as “C2WTS”) is only used when SharePoint needs to get data from an external system that does not understand claims.  Examples of features that can be configured to use C2WTS include, but are not limited to:

• SQL Server Reporting Services (SSRS)
• Excel Web Services (EWS)
• PowerPivot / Power View
• Business Data Connectivity (BDC) / Business Connectivity Services (BCS) / External Content Types (ECT) / External Lists.
• Other SharePoint “BI” stuff.
• Custom Code that does user impersonation.

Normal SharePoint stuff (browsing sites, working in native lists / libraries, etc) does not use the C2WTS.

— I’ve seen many cases where we’ve spent a lot of time configuring the C2WTS to try to fix some authentication or permissions issue, when in fact, the C2WTS doesn’t even come into play in those scenarios.

2. The C2WTS can only be accessed on the local server, so when you are using it, the service must be running on all of your WFEs and any other server that will access the external data.

3. Out of the box, it only works for Windows-Claims web apps.  It does not work for Trusted Provider / SAML claims (ADFS, Ping, SiteMinder, etc).  Even if you pass UPN as one of your claims, it will not work**.

See this: https://technet.microsoft.com/en-us/library/ee806870.aspx#section2

Excerpt: “It is important to understand that these service applications can use the C2WTS only if the incoming authentication method is either Windows claims or Windows classic mode. Service applications that are accessed through web applications and that use Security Assertion Markup Language (SAML) claims or forms-based authentication claims do not use the C2WTS. Therefore, they cannot translate claims to Windows credentials.”

** I found that certain custom claim providers may also contain the custom code necessary to make C2WTS work with their SAML claims. For example, the Okta farm-level solution contains such code. In that case, you must be passing UPN as one of the claims, and you must have custom farm-level property “MapUpnToWindowsUser” set. Reference.

4. This is not necessarily an “error”:

11/09/2017 17:55:14.15 w3wp.exe (0x1A88) 0x2978 SharePoint Foundation Claims Authentication bz7l Medium SPSecurityContext: Could not retrieve a valid windows identity for username ‘CONTOSOUser1’ with UPN ‘User1@contoso.com’. UPN is required when Kerberos constrained delegation is used. Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: WTS0003: The caller is not authorized to access the service. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: WTS0003: The caller is not authorized to access the service.

at Microsoft.IdentityModel.WindowsTokenService.CallerSecurity.CheckCaller(WindowsIdentity callerIdentity)

at Microsoft.IdentityModel.WindowsTokenService.S4UServiceContract.PerformLogon(Func`1 logonOperation, Int32 pid)

at SyncInvokeUpnLogon(Object , Object[] , Object[] )

at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)

at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet))..

Many times we see the above in the SharePoint ULS logs because there is some custom code in the master page or in a web part that calls an “impersonate” method, which results in calling into the Claims to Windows Token Service (C2WTS).  But C2WTS may not be required for that code to work, so even though it throws the above error, it causes no actual problem.

Before digging into this “error”, you must ask yourself: “Does what I’m troubleshooting even use the C2WTS?” (see Fact #1 above).

Proper Permission Configuration:

Most C2WTS issues I see are a problem with configuring the service, more specifically with properly configuring permissions for the account that runs it.

Here’s a summary of how you should configure it:

Permissions Check list:
Reference here: https://technet.microsoft.com/en-us/library/hh231678(v=sql.110).aspx

Note: The end-to-end configuration for C2WTS will include setting up delegation on the C2WTS account.  These steps vary depending on what you’re trying to get C2WTS to pull data from, and therefore are beyond the scope of this post.  However, here’s an example of setting it up for SSRS.

• For Users calling the service

By “calling the service”, I mean any user browsing the SharePoint page, web part, SSRS report, Excel spreadsheet, etc that connects to some back-end service that utilizes the C2WTS. These users directly call the service and need permission to do so.
Edit c2wtshost.exe.config at C:Program FilesWindows Identity Foundationv3.5 and make sure all users have access to call the service.  — Adding “NT AUTHORITYAuthenticated Users” to the allowed callers list ought to take care of that.

<allowedCallers>
<clear/>
<add value=”NT AUTHORITYNetwork Service” />
<add value=”NT AUTHORITYLocal Service” />
<add value=”NT AUTHORITYSystem” />
<add value=”NT AUTHORITYAuthenticated Users” />
</allowedCallers>

• For the account running the C2WTS service (in services.msc):

• On the SharePoint boxes running C2WTS:

  • Add to the local Administrators group

  • Add to the local security policy (Start > Administrative Tools > Local Security Policy > Local Policies > User Rights Assignment),

    • Act as part of the operating system
    • Impersonate a client after authentication

    • Log on as a service

• On the domain(s):

  • Needs to have the “Read tokenGroupsGlobalAndUniversal” permission to all the users in the domain.

    • To give this permission, we need to add it to the “Windows Authorization Access Group” builtin domain group, which should have this permission to all domain accounts by default.
    • The account needs these permissions on every domain that contains the users that are calling the service.  So if you have a number of domain / forest trusts, and users from these other domains are browsing your SharePoint sites and using stuff that invokes the C2WTS, then you need to add your C2WTS service account to the “Windows Authorization Access Group” in every one of those domains.

Other notes for configuring C2WTS:

This service can only be accessed locally, so it needs to be running on all the machines in the farm that require it.  For example, in the case of SSRS, it needs to be running on the servers running the SSRS service.  Because it may not immediately be clear where you need the service in each scenario, you may choose to just run it on all servers in the farm.

Keep in mind that the c2wtshost.exe.config file edit, and the local security policy changes listed above need to be made on every server running C2WTS.

If you stop the C2WTS and start it again in Central Administration | Manage Services on Server, that will cause the c2wtshost.exe.config file to revert to its out-of-box version, and your users won’t be allowed access anymore. If you want to restart the service, just restart the Windows service within services.msc:

Important: If the Claims to Windows Token Service won’t start at all, you may have a problem within the c2wtshost.exe.config file. See this post from my colleague Mike Lee: Unable to start the C2WTS

Troubleshooting:

If you have configured permissions properly as described above but are still getting C2WTS errors, you can use the C2WTS tester tool:
https://rodneyviana.com/troubleshooting-claims-to-windows-nt-token-service-c2wts-in-sharepoint-2010-may-be-difficult-if-you-dont-know-where-to-start/

It’s called “c2WTSTest.zip” and you can download it here:

https://github.com/rodneyviana/blogdemos/blob/master/c2WTSTest.zip

— Here’s what the C2WTS tester tool looks like:
-By default, the tool runs as the logged-on user, but you can run it as another user by simply supplying a user name and password.
Note: This account is the user calling the service, which is different from account running the service.
-You also specify the UPN to try to convert to a Windows token.  This can be the UPN for the user running the tool, or some other UPN altogether.
-Here’s what a successful run of the tool looks like:

— As you can see, it checks that the caller has permission per the “allowedCallers” tag in the c2wtshost.exe.config file, that the user can log in, and that the service account has permission to create the Windows token.

— And here’s an example of a failure:

Error Text:
***** c2WTS could not provide a valid Windows Token. Reason: Access is denied.

Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at c2WTSTest.Form1.button2_Click(Object sender, EventArgs e)

— It can be useful to take a Netmon (Network Monitor 3.4) trace while running the tester tool.
-The C2WTS uses Kerberos calls, so if you filter like tcp.port == 88, then you will see the request.

Here’s an example of a failing sequence:

— We can see it fails with “KDC_ERR_C_PRINCIPAL_UNKNOWN” which means “Client not found in Kerberos database”.  The “client” in this case is the user we tried to generate a token for.

— See: http://support.microsoft.com/kb/2009157

As specified above, the service account running the C2WTS needs to have the “Read tokenGroupsGlobalAndUniversal” permission to all the users in the domain (or at least all users that want to be able to invoke it and render their favorite SSRS reports, or whatever you’re using C2WTS for).

To give this permission, we need to add it to the “Windows Authorization Access Group” builtin domain group.
By default, the “Windows Authorization Access Group” has the “Read tokenGroupsGlobalAndUniversal” permission to all accounts in the domain.  If that has been removed for some reason, we’ll need to add it or the equivalent permissions back. One way to check permissions in AD is to go to Active Directory Users and Computers | Properties for a user | Security | Advanced | Effective Access.  Choose the C2WTS service account and make sure it has (at least) the “Read tokenGroupsGlobalAndUniversal” permission.

Here’s an example where my service account (m1garandservice) does not have the correct permission to the User1 user account:

— In this case, I reproduced this behavior with an explicit deny on the Read tokenGroupsGlobalandUniversal permission for the User1 account, but out in the wild, you’d likely see this because the C2WTS service account is not in the “Windows Authorization Access Group” for all applicable domains. Have I mentioned that’s an important permission yet?

Full SharePoint ULS log example for the Access Denied error:

SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName=’CONTOSOUser1′, UPN=’user1@contoso.com’. UPN is required when Kerberos constrained delegation is used. Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity().Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: , Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: Cannot convert claims identity to windows token. —> System.InvalidOperationException: Could not retrieve a valid Windows identity. —> System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.IS4UService_dup.UpnLogon(String upn, Int32 pid)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.<>c__DisplayClass1.<UpnLogon>b__0(IS4UService_dup channel)
at Microsoft.IdentityModel.WindowsTokenService.S4UClient.CallService(Func`2 contractOperation)
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity()
— End of inner exception stack trace —
at Microsoft.SharePoint.SPSecurityContext.GetWindowsIdentity()
at Microsoft.ReportingServices.ServiceRuntime.WcfUserContext.GetWindowsIdentity()
— End of inner exception stack trace —;

Symptoms

Consider the following scenario:

You are running Microsoft SharePoint Server 2010 together with Windows Server 2008 or with Windows Server 2008 R2 on a computer that is not connected to the Internet.

After you apply the update that is described in Microsoft Knowledge Base article 2677070 to Windows Server 2008 or Windows Server 2008 R2, you restart the server.

In this scenario, the following services may not start on the SharePoint server immediately after you restart the server:

SharePoint 2010 Administration Service

Claims To Windows Token service (C2WTS)

Additionally, the following errors are logged in Event Viewer on the SharePoint server:

Error starting SharePoint 2010 Administration Service: Error: 1053: The service did not respond to the start or control request in a timely fashion.

Event ID 7009: A timeout was reached (30000 milliseconds) while waiting for the SharePoint 2010 Administration service to connect

You encounter similar error messages when you try to start the Claims To Windows Token service (C2WTS).

Cause

This issue occurs because of an inability to retrieve trusted and untrusted certificate trust lists (CTLs). If the system does not have access to Windows Update, either because the system is not connected to the Internet or because Windows Update is blocked by firewall rules, the network retrieval times out before the service can continue its startup procedure. In some cases, this network retrieval time-out may exceed the service startup time-out of 30 seconds. If a service cannot report that startup completed after 30 seconds, the service control manager (SCM) stops the service.

The URLs to update the CTL changed with this update. Therefore, if previous URLs were hard-coded as exceptions in the firewall or proxy, or if there is no Internet access on the computer, the CTL cannot be updated.

To download the latest CTLs, use the following updated URLs:

For more information about the issue, click the following article number to view the article in the Microsoft Knowledge Base:

Resolution

To work around this problem, configure the computer so that the network does not retrieve trusted and untrusted CTLs. To do this, use one of the following methods:

Validate that boundary firewalls, router access rules, and downstream proxy servers enable systems that have update 2677070 installed to contact Microsoft Update. For more information about this requirement, see the following article in the Microsoft Knowledge Base. (This includes the URLs that the CTL update accesses.)

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Change the Group Policy settings. To do this, follow these steps:

Under the Computer Configuration node in the Local Group Policy Editor, double-click Policies.

Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.

In the details pane, double-click Certificate Path Validation Settings.

Click the Network Retrieval tab, click to select the Define these policy settings check box, and then click to clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.

Click OK, and then close the Local Group Policy Editor.

Modify the registry. To do this, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKLMSoftwarePoliciesMicrosoftSystemCertificates

Right-click AuthRoot, select New, and then click DWORD.

Type DisableRootAutoUpdate, and then press Enter.

Right-click DisableRootAutoUpdate, and then click Modify.

In the Value data box, type 1, and then click OK.

Exit Registry Editor, and then restart the computer.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl

Right-click Control, point to New, and then click DWORD Value.

In the New Value box, type ServicesPipeTimeout, and then press Enter.

Right-click ServicesPipeTimeout, and then click Modify.

Click Decimal, type the number of milliseconds that you want to wait until the service times out, and then click OK.

For example, if you want to wait 60 seconds before the service times out, type 60000.

Exit Registry Editor, and then restart the computer.

More Information

For more information about the Windows root certificate program, certificates, certificate trust, and the certificate trust list, see the «More Information» section of the following article in the Microsoft Knowledge Base:

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Источник

Symptoms

Consider the following scenario:

You are running Microsoft SharePoint Server 2010 together with Windows Server 2008 or with Windows Server 2008 R2 on a computer that is not connected to the Internet.

After you apply the update that is described in Microsoft Knowledge Base article 2677070 to Windows Server 2008 or Windows Server 2008 R2, you restart the server.

In this scenario, the following services may not start on the SharePoint server immediately after you restart the server:

SharePoint 2010 Administration Service

Claims To Windows Token service (C2WTS)

Additionally, the following errors are logged in Event Viewer on the SharePoint server:

Error starting SharePoint 2010 Administration Service: Error: 1053: The service did not respond to the start or control request in a timely fashion.

Event ID 7009: A timeout was reached (30000 milliseconds) while waiting for the SharePoint 2010 Administration service to connect

You encounter similar error messages when you try to start the Claims To Windows Token service (C2WTS).

Cause

This issue occurs because of an inability to retrieve trusted and untrusted certificate trust lists (CTLs). If the system does not have access to Windows Update, either because the system is not connected to the Internet or because Windows Update is blocked by firewall rules, the network retrieval times out before the service can continue its startup procedure. In some cases, this network retrieval time-out may exceed the service startup time-out of 30 seconds. If a service cannot report that startup completed after 30 seconds, the service control manager (SCM) stops the service.

The URLs to update the CTL changed with this update. Therefore, if previous URLs were hard-coded as exceptions in the firewall or proxy, or if there is no Internet access on the computer, the CTL cannot be updated.

To download the latest CTLs, use the following updated URLs:

For more information about the issue, click the following article number to view the article in the Microsoft Knowledge Base:

Resolution

To work around this problem, configure the computer so that the network does not retrieve trusted and untrusted CTLs. To do this, use one of the following methods:

Validate that boundary firewalls, router access rules, and downstream proxy servers enable systems that have update 2677070 installed to contact Microsoft Update. For more information about this requirement, see the following article in the Microsoft Knowledge Base. (This includes the URLs that the CTL update accesses.)

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Change the Group Policy settings. To do this, follow these steps:

Under the Computer Configuration node in the Local Group Policy Editor, double-click Policies.

Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.

In the details pane, double-click Certificate Path Validation Settings.

Click the Network Retrieval tab, click to select the Define these policy settings check box, and then click to clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.

Click OK, and then close the Local Group Policy Editor.

Modify the registry. To do this, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKLMSoftwarePoliciesMicrosoftSystemCertificates

Right-click AuthRoot, select New, and then click DWORD.

Type DisableRootAutoUpdate, and then press Enter.

Right-click DisableRootAutoUpdate, and then click Modify.

In the Value data box, type 1, and then click OK.

Exit Registry Editor, and then restart the computer.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Click Start, click Run, type regedit in the Open box, and then click OK.

Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl

Right-click Control, point to New, and then click DWORD Value.

In the New Value box, type ServicesPipeTimeout, and then press Enter.

Right-click ServicesPipeTimeout, and then click Modify.

Click Decimal, type the number of milliseconds that you want to wait until the service times out, and then click OK.

For example, if you want to wait 60 seconds before the service times out, type 60000.

Exit Registry Editor, and then restart the computer.

More Information

For more information about the Windows root certificate program, certificates, certificate trust, and the certificate trust list, see the «More Information» section of the following article in the Microsoft Knowledge Base:

2677070 An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

Источник

Claims to windows token service

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have configured a web part in SharePoint 2010. The environment consists of 1 WFE, 1 APP, 1 SQL, 1 AS server all on Windows Server 2008 R2 Sp1 OS. I have configured C2WTS. The user domainfarmaccountuser is also part of WSS_WPG group but i still get the following error:

Answers

Initially C2WTS config file allowed callers had only 1 entry of WSS_WPG. In this case C2WTS was actually not working although c2WTSTest.exe mentioned it would work.

To make C2WTS work i made two changes:

1. Changes to C2WTS config file:

Above shows that i added Authenticated Users

2. Added NT AuthoritySystem to local WSS_WPG group

The above was tough to figure out since i felt that this should have been done automatically by the service.

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes farmaccountuser is local admin.

C2WTS domain account is also local admin. I followed the Kerberos guide step by step.

Does the C2WTS user also have the following rights on the server:

Act as part of the operating system

Impersonate a client after authentication

Logon as a service

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes did do those as well.

Just to be exact, i have followed all the steps detailed in the article at:

The event viewer shows me following error message:

The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.

Silly question, but after adding it to the Local Admins group, did you force the account to log off of the system?

Have you modified, either via GPO or manually the SDDL of the Security Event Log?

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Trevor, no problem i dont mind being elaborate.

I logged in using FarmAccountUser who was already local admin on the server(WFE and AppServer). While logged on as FarmAccountUser i configured C2WTS, also added the C2WTSSvcAccount to Local Admin and then logged off. Later logged on as FarmAccountUser which didnt help. Then finally restarted both WFE and AppServer. From CA i changed the service account C2WTS service from Local System to C2WTSSvcAccount. C2WTS is configured on both WFE and AppServer, although i understand it shouldnt run on WFE. But if i stop the server on WFE the error doubles up. I get below error in addition to the earlier error that I posted. Hence i had to start C2WTS on WFE as well.

I ran c2WTSTest.exe to check if C2WTS is configured properly. I get below message when i run the tool, which indicates that the service is running properly i guess.

Services running on the servers are as follows:

Источник

Claims to windows token service

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have configured a web part in SharePoint 2010. The environment consists of 1 WFE, 1 APP, 1 SQL, 1 AS server all on Windows Server 2008 R2 Sp1 OS. I have configured C2WTS. The user domainfarmaccountuser is also part of WSS_WPG group but i still get the following error:

Answers

Initially C2WTS config file allowed callers had only 1 entry of WSS_WPG. In this case C2WTS was actually not working although c2WTSTest.exe mentioned it would work.

To make C2WTS work i made two changes:

1. Changes to C2WTS config file:

Above shows that i added Authenticated Users

2. Added NT AuthoritySystem to local WSS_WPG group

The above was tough to figure out since i felt that this should have been done automatically by the service.

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes farmaccountuser is local admin.

C2WTS domain account is also local admin. I followed the Kerberos guide step by step.

Does the C2WTS user also have the following rights on the server:

Act as part of the operating system

Impersonate a client after authentication

Logon as a service

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Yes did do those as well.

Just to be exact, i have followed all the steps detailed in the article at:

The event viewer shows me following error message:

The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.

Silly question, but after adding it to the Local Admins group, did you force the account to log off of the system?

Have you modified, either via GPO or manually the SDDL of the Security Event Log?

————————
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Trevor, no problem i dont mind being elaborate.

I logged in using FarmAccountUser who was already local admin on the server(WFE and AppServer). While logged on as FarmAccountUser i configured C2WTS, also added the C2WTSSvcAccount to Local Admin and then logged off. Later logged on as FarmAccountUser which didnt help. Then finally restarted both WFE and AppServer. From CA i changed the service account C2WTS service from Local System to C2WTSSvcAccount. C2WTS is configured on both WFE and AppServer, although i understand it shouldnt run on WFE. But if i stop the server on WFE the error doubles up. I get below error in addition to the earlier error that I posted. Hence i had to start C2WTS on WFE as well.

I ran c2WTSTest.exe to check if C2WTS is configured properly. I get below message when i run the tool, which indicates that the service is running properly i guess.

Services running on the servers are as follows:

Источник

Claims to Windows Token Service (c2WTS) not starting after rebooting server

Symptom

There are occasions where Claims To Windows Token Service (c2WTS) is unable to start automatically after a reboot. The Application Event Log will also show that c2WTS timed out, and, in a later entry that Cryptographic Services Service was started. When c2WTS starts automatically, the Application Event Log will show Cryptographic Services Service starting before c2WTS. This can happen specially in SharePoint 2010 when Claims to Windows Service is configured in one or more servers.

Cause

Claims To Windows Token Service (c2WTS) has a dependency on Cryptographic Services but this dependency is not added to the service definition. Since the execution order of the services are not guaranteed to happen in any specific order unless it is defined in the service dependencies, it may lead to intermittent problems where c2WTS service will time out and fail to start. Observing the Application Event Viewer, you can see that Cryptographic Services Service was trying to start while c2WTS was also starting and it timed out just before Cryptographic Services Service has started.

c2WTS is part of the Windows Identity Foundation framework (WIF) which is one of the dependencies of SharePoint. The framework installation does not include the service dependency automatically.

Resolution

The solution is to make sure that Cryptographic Services Service is guaranteed to start before c2WTS starts by explicitly adding the dependency in the service definition. These steps will add the dependency:

1. Open the command-prompt window.

2. Type: sc config c2wts depend= CryptSvc
3. Find the Claims to Windows Token Service in the services console (click Start | Run | services.msc).

4. Open the properties for the service.

5. Check the Dependencies tab. Make sure Cryptographic Services is listed.

The next time the system reboots, Cryptography Services will start before c2WTS starts which resolves the dependency problem and the intermittent problem. If you are using SharePoint 2010 this must be done in all servers running the service.

More Information

Identity delegation for PerformancePoint Services (SharePoint Server 2010)

Источник

Print | posted on Tuesday, June 02, 2015 9:05 PM

Recently I’ve done a few pieces of work with SharePoint 2013 Business Intelligence and I have also delivered the “legendary”* Kerberos and Claims to Windows Service talk a few times this year. This reminded me to post my Windows PowerShell snippets for the required Active Directory configuration.

This topic area is perhaps one of the most misunderstood areas of SharePoint Server, and there is an utterly staggering amount of misinformation, out of date information, single server documentation and good old fashioned 100% bullshit out there. That’s a surprise with SharePoint stuff, huh?

Every guide or document out there that I could find talks to configuring Delegation using Active Directory Users and Computers (ADUC). They all also reference configuring Local Security Policy manually, or via Group Policy (without providing the details).

Of course there’s nothing wrong with doing it that way, and it sure makes for a better explanation of the concepts. However back in 2009 when we were working on pre-release materials I put together some Windows PowerShell to achieve the same configuration. So here they are in all their very simple glory.

* “Legendary” – I don’t know about that so much, but the Kerberos talks and in particular the AuthN+Z module of the SharePoint 2007, 2010 and 2013 MCM programs were recently described to me as such by five different SharePoint luminaries with rock solid credibility. Those people know who they are.

Every time I give this talk I get hassled for the “magic scripts”. They aren’t magic, but they always seem to surprise people as there is a misconception that delegation settings cannot be set using Windows PowerShell!

As you should be aware, in order to configure identity delegation for a Web Application in Claims mode within SharePoint Server 2010 or 2013 we must configure Kerberos Constrained Delegation with Protocol Transition. No ifs, no buts. It’s the only way it can work because in Claims mode there is no identity with which to perform either impersonation, basic delegation or true Constrained Delegation using Kerberos.

Thus, we make use of a component of the Windows Identity Framework, the Claims to Windows Token Service (C2WTS) to mock real delegation using a Windows Logon Token. C2WTS itself makes use of Service For User (S4U). S4U does NOT perform real delegation, it cannot because there are no user credentials to delegate. It instead grabs a bunch of SIDs for the user (in this case a service identity). What all this means is that there is a hard requirement to use Protocol Transition. Protocol Transition is named in the UI of ADUC as “Use any authentication protocol”.

Thus, in order to set things up, our settings in Active Directory for the C2WTS service identity and the application pool identity of the service application endpoint must be configured to perform Kerberos Constrained Delegation using Protocol Transition to the back end services.

In the example below I am allowing the C2WTS account to delegate to SQL Server Database Services and SQL Server Analysis Services using the SPNs which already exist on their service accounts. I of course repeat the exact same configuration on the application pool identity of the service application endpoint.

In order to complete this configuration using ADUC we are told we must create a “mock” or “fake” Service Principal Name (SPN) on the accounts first. Otherwise the Delegation tab in the account properties does not show up.

The reality is we can easily configure the attributes we are interested in using ADUC in Advanced Features mode, or ADSIEdit. However, there must be an SPN for the delegation to succeed. So it’s not a “mock” SPN at all. It’s not just about exposing the delegation tab. We must have a SPN!

It’s a complete breeze to configure the same settings using the Active Directory module for Windows PowerShell.

• The services to delegate to are exposed by the AD schema extended attribute msDS-AllowedToDelegateTo. This can be manipulated using the standard Set-ADUser –Add pattern. As can the SPN itself. 
   
• The setting for Protocol Transition is actually a UserAccountControl attribute.  It’s enumeration is ADS_UF_TRUSTED_FOR_DELEGATION or 524288. Remember this attribute is a cumulative bitmask. But the thing is we DON’T need to care! We don’t need some stinky “library” or utility function to manage the bitmask stuff or any of that noise. It can all be handled with the Set-ADAccountControl cmdlet with the –TrustedToAuthForDelegation parameter.
   
• Note TrustedToAuthForDelegation == Protocol Transition, –TrustedForDelegation == Kerberos Only

And that’s it. Two cmdlets basically. A complete snap. Now as always, there’s some slinging needed to do this neatly for real requirements and perform end to end configuration. Here’s the Windows PowerShell script I use for basic setups:

<#
    Configures accounts in Active Directory to support identity delegation
    spence@harbar.net
    February 16th 2009

    1. Configures SPNs for SQL DB and SQL AS
       - does not check for duplicates
    2. Configures SPNs for SharePoint service identities
       (C2WTS and Service App Endpoint Identity)
    3. Configures Kerberos Constrained Delegation with 
       Protocol Transition to SPNs in #2
    
#>
Import-Module ActiveDirectory

## VARS
$sqlDBaccount = "sqldb"
$sqlASaccount = "sqlas"
$c2wtsAccount = "c2wts"
$servicesAccount = "sppservices"

$c2wtsSpn = "SP/c2wts"
$servicesSpn = "SP/Services"
$sqlDbSpns = @("MSSQLSvc/fabsql1.fabrikam.com:1433", "MSSQLSvc/fabsql1:1433")
$sqlAsSpns = @("MSOLAPSvc.3/fabsql1.fabrikam.com", "MSOLAPSvc.3/fabsql1")
$delegateToSpns = $sqlDbSpns + $sqlAsSpns
## END VARS

$delegationProperty = "msDS-AllowedToDelegateTo"

Write-Host "Configuring SPNs for SQL Server Services..."
$account = Get-ADUser $sqlDBaccount
$sqlDbSpns | %  {Set-AdUser -Identity $account -ServicePrincipalNames @{Add=$_}}
$account = Get-ADUser $sqlASaccount
$sqlAsSpns | %  {Set-AdUser -Identity $account -ServicePrincipalNames @{Add=$_}}

function ConfigKCDwPT($account, $spn) {
    $account = Get-ADUser $account
    $account | Set-ADUser -ServicePrincipalNames @{Add=$spn}
    $account  | Set-ADObject -add @{$delegationProperty=$delegateToSpns}
    Set-ADAccountControl $account -TrustedToAuthForDelegation $true
}

Write-Host "Configuring KCDwPT for C2WTS and Services Account..."
ConfigKCDwPT $c2wtsAccount $c2wtsSpn
ConfigKCDwPT $servicesAccount $servicesSpn

Write-Host "KCDwPT configuration complete!"

OK, so that’s the AD account configuration settings all taken care of. What about the C2WTS itself?

If we run C2WTS as it’s default identity, LocalSystem, we don’t need to do anything. But that’s a really stupid configuration. Why? Because in a real farm you have more than one machine running C2WTS. That means multiple points of configuration (on each computer object in AD). In addition any mistakes you make during configuration (say you fat finger the SPN) require a machine restart for corrections to take effect.  Thus there is a compromise between manageability, configuration approach and security.

The reality is that the security element of the compromise is completely null and void from a technical or information security perspective. The old arguments about TCB are now completely out-dated, and besides were invented by people who didn’t know information security and were designed for single server solutions! However, if you are unlucky enough to work with those customers with out-dated security policies it remains part of the compromise on those grounds alone.

Everyone else with any sense will change the identity to a named service account. If we do this, we also have to grant additional User Rights Assignments to the account in order for it to be able to call S4U. These are Act as part of the Operating System and Impersonate a Client after Authentication. The account must also be a member of the Local Administrators group on each server it runs. All of this can be done via Computer Management and Local Security Policy, or properly via Group Policy.

However it’s also a complete snap to configure this stuff using Windows PowerShell, making use of an old school utility NTRights from the Windows Server Resource Kit or the Carbon library. Here’s the script:

<#
    Configures C2WTS service identity with appropriate user rights
    spence@harbar.net
    February 16th 2009

    1. Configures Local Admins memebership
    2. Configures User Rights Assignments using NTRights 
       (update with path to WSRK)
    3. Configures User Rights Assignments using Carbon 
       (http://sourceforge.net/projects/morgansource/files/
       Third-Party-Sources/Carbon-1.6.0.zip/download)
    
#>
asnp Microsoft.SharePoint.PowerShell

## VARS
$user = "fabrikamc2wts"
$CarbonDllPath = "C:ToolsCarbon-1.6.0CarbonbinCarbon.dll"
## END VARS


# adds user to local admins group
NET LOCALGROUP Administrators $user /ADD

# sets up the neccessary local user rights assignments using NTRights
C:ToolsrkNTRights.exe +r SeImpersonatePrivilege -u $user
C:ToolsrkNTRights.exe +r SeTcbPrivilege -u $user

# sets up the neccessary local user rights assignments
[Reflection.Assembly]::LoadFile($CarbonDllPath)
[Carbon.Lsa]::GrantPrivileges($user, "SeImpersonatePrivilege")
[Carbon.Lsa]::GrantPrivileges($user, "SeTcbPrivilege")

Note we do NOT have to set the c2wts account to Logon as a Service, as this User Rights Assignment is granted when we change the service identity within SharePoint…..

On a related note, I’ve also been asked for my snippets for managing the C2WTS process identity. TechNet has incorrect scripts for this work, which will only ever work on a single server farm (ooops!). Here’s how to change it properly, and also how to reset it back to LocalSystem (properly!).

<#
    Configures C2WTS service identity 
    spence@harbar.net
    February 16th 2009

    1. Sets dependency
    2. Sets desired process identity
#>
asnp Microsoft.SharePoint.PowerShell

## VARS
$accountName = "FABRIKAMc2wts"
$serviceInstanceType = "Claims to Windows Token Service"
## END VARS

sc.exe config c2wts depend=CryptSvc

# configure to use a managed account
# Should use farm, otherwise in multi server farm you have an array of objects!
$farmServices = Get-SPFarm
$c2wts = $farmServices.Services | Where {$_.TypeName -eq $serviceInstanceType}
$managedAccount = Get-SPManagedAccount $accountName
$c2wts.ProcessIdentity.CurrentIdentityType = "SpecificUser";
$c2wts.ProcessIdentity.ManagedAccount = $managedAccount
$c2wts.ProcessIdentity.Update();
$c2wts.ProcessIdentity.Deploy();
$c2wts.ProcessIdentity 

# reset to local system
# Should use farm, otherwise in multi server farm you have an array of objects!
$farmServices = Get-SPFarm
$c2wts = $farmServices.Services | Where {$_.TypeName -eq $serviceInstanceType}
$c2wts.ProcessIdentity.CurrentIdentityType=0; #LocalSystem
$c2wts.ProcessIdentity.Update();
$c2wts.ProcessIdentity.Deploy();
$c2wts.ProcessIdentity 

Note I use this script to also configure the missing dependency on the Windows Service itself. We can of course start the C2WTS easily as well:

# start c2wts on server(s)
$servers = @("FABSP1", "FABSP2")
foreach ($server in $servers)
{
    Get-SPServiceInstance -Server $server | Where {$_.TypeName -eq $serviceInstanceType} | Start-SPServiceInstance
}

Nice and easy. No pointy clickity click click or “Working on it…” needed. The entire end to end configuration in Windows PowerShell takes less than 90 seconds.

s.