Make sure to run this executable as the service account under which Excel Calculation Service is running. If you are not sure what account that is, first go to Central Admin’s “Security” page:

Then under “General Security” chose “Configure Service Accounts”:

In the drop down list on the right side you are looking for a “Service Application Pool” which contains your “Excel Services Application Web Service Application” (in the middle list). The account at the bottom would be the account you want to make sure you run the test application as to accurately simulate what ECS is doing when you are actually using SharePoint. Using the wrong account might give misleading results.

You must provide the User Principle Name (UPN) of the interactive user to the test application. All users have an implicit UPN which can be expressed as <user>@<domain> (I would be “leegr@redmond”). You may also have been given an explicit UPN which might look slightly different (although the implicit UPN would still work). If you are concerned that you are not using the right UPN, you can dig through the ULS log to find the UPN associated with the failure. This is the log entry that I got when I turned the c2wts service off:

SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName=’REDMOND\leegr’, UPN=’leegr@microsoft.com’. UPN is required when Kerberos constrained delegation is used.

Note that the bit about “Kerberos” can be ignored because we do not require Kerberos constrained delegation to work (and neither does c2wts … it just returns a limited token in this case which is fine for us). Also, your log entry might look a bit different since I don’t know if they output different things to the log based on the exception type at this level.

To compile this code, you need to link to:

• Microsoft.IdentityModel
• System
• System.Core
• System.IdentityModel
• System.ServiceModel

using System;
using System.Security.Principal;
using System.ServiceModel;
using System.ServiceModel.Security;
using Microsoft.IdentityModel.WindowsTokenService;

namespace C2WTSTest
{
    class Program
    {
        static void OutputUsage()
        {
            Console.WriteLine(“Usage:”);
            Console.WriteLine(“/tc2wtstest.exe <upn>”);
            Console.WriteLine(“/tExample: c2wtstest.exe dwickert@redmond”);
        }

        static void Main(string[] args)
        {
            if ((args.Length != 1) || (string.Compare(args[0], “/?”) == 0) || (string.Compare(args[0], “-?”) == 0) || (string.Compare(args[0], “?”) == 0))
            {
                OutputUsage();
                return;
            }

            string upn = args[0];

            WindowsIdentity windowsIdentity = null;
            if (!String.IsNullOrEmpty(upn))
            {
                try
                {
                    Console.WriteLine(“Attempting to acquire windows identity for upn: ‘{0}’”, upn);
                    windowsIdentity = S4UClient.UpnLogon(upn);
                }
                catch (SecurityAccessDeniedException)
                {
                    Console.WriteLine(“Could not map the upn claim to a valid windows identity. Security Access Denied”);
                    return;
                }
                catch (EndpointNotFoundException)
                {
                    Console.WriteLine(“Could not map the upn claim to a valid windows identity because the c2wts service was unavailable”);
                    return;
                }
                catch (FaultException e)
                {
                    Console.WriteLine(“Could not map the upn claim to a valid windows identity because the c2wts service returned a fault”);
                    Console.WriteLine(e.ToString());
                    return;
                }
                catch (Exception e)
                {
                    Console.WriteLine(“Could not map the upn claim to a valid windows identity because of an unexpected exception”);
                    Console.WriteLine(e.ToString());
                    return;
                }
            }
            else
            {
                throw new Exception(“No UPN claim found”);
            }

            using (WindowsImpersonationContext ctxt = windowsIdentity.Impersonate())
            {
                Console.WriteLine(“Successfully acquired token and impersonated user: ‘{0}’”, WindowsIdentity.GetCurrent().Name);
            }

        }
    }
}

HTH
Lee

Here is a quick list of most likely causes for this error and how to debug and fix them (in order based on my experience of likelihood to be the root cause):

• Is the Claims to Windows Token Service started on the server running Excel Calculation Service (ECS)? For detailed information on the Claims to Windows Token Service (c2wts), you can read the msdn article. This service is turned on when doing a “New Farm” installation of PowerPivot, but if you do an “Existing Farm” installation, or have Excel Calculation Service (ECS) running on a different machine, the Claims to Windows Token Service might not be started. Check to make sure that this service is running on every server on which ECS is running. You can validate this via the “Services on Server” option in SharePoint’s Central Administration web site but it is also important to make sure that this is running from Service Control Manager (SCM accessed via services.msc). There is a known issue after reboot where the c2wts fails to start because of an unexpressed startup dependency on the crypto service. I will add a link to the KB when it is available but until then you can add the dependency manually from SCM or from an administrative command prompt with “sc.exe config c2wts depend= cryptsvc”.This will prevent the problem from reappearing after your next reboot. As per http://powerpivotgeek.com/2010/01/18/why-you-shouldnt-stop-start-analysis-services-from-scm-when-running-in-sharepoint-integration-mode/, you should not manage SharePoint services from SCM, however SCM is the truth when it comes to whether a service is running and so you should always double check by looking at the state in SCM. If SharePoint indicates that the service is started but it is not actually running per SCM, it is safe to start it from SCM (alternatively you could stop and start it from SharePoint Central Administration). As well as simply managing this service, SharePoint configures the security permissions for this service automatically as part of their setup so that all SharePoint Shared Services (which includes ECS) can use it. If you find that the service is stopped on the machine running ECS, start it. After starting this service, you should not need to do any type of  IisReset to see the system start working.
• Is your machine connected to the network? Dave has written a good blog on this also (http://powerpivotgeek.com/2009/11/06/taking-your-server-off-the-network/). If you are actually trying to run a PowerPivot demo with a machine which is not on the network, follow the steps in Dave’s blog to configure ECS to use a set of stored credentials for the PowerPivot datasource. If you are not doing this on purpose, then connect back to the network.
• The final cause would be that for some reason other than network connectivity, the Claims to Windows Token Service is not able to convert the SAML claims token to a Windows User security token. Dave provides a lot of details on these potential issues. Some quick questions to ask yourself:
  • Is the client user account (the logged in user who is browsing the workbook in IE) a domain account? If the account is a local machine account, then the Claims to Windows Token service will not be able to retrieve a Windows user security token. We do not support this scenario in V1 of PowerPivot. Interactive users must be domain users. For demo purposes in a bind you might try the workaround Dave provided for taking the server off of the network, but I have not personally tested it in this case.
  • Is the client user account in a different domain than the SharePoint servers? This is completely supported, but there must be a trust relationship established between the two domains. You could verify if a missing trust issue is causing your problems by logging in as a user account in the same domain as the SharePoint servers and try interacting with the workbooks (note that you had to have given that user access to the workbook). If it works for users in the same domain but not for users in other domains, it might be an issue with cross domain trust. Contact your domain admin to figure out what the relationships are setup as.
  • What account is the Claims to Windows Token Service running as? By default it is configured to run as Local System, and I am not aware of the reasons for changing this configuration (the msdn article also refers to the fact that it should be running as Local System). While there might be a good reason for trying to change it, it is possible that the person who altered it did not understand the implications of this change. You should probably track down the person who changed it and get an understanding of why. If you have permissions, switch it back to Local System and try the scenario again. If it works, you will need to determine why it was changed in the first place.
  • If you have gotten this far and none of the above have solved your issue, then there is the possibility that you have some custom AD configuration which is causing the issue. Dave points out one possibility:
    

    The account being used as the Excel Services service account must have AD rights to be able to query the object. One place where we know this restriction comes into play is if you have configured your domain controller to have a subgroup under “Users”, e.g. “Service Accounts”, which is a separate AD group that derives from “Users” –> but I am sure that there are more. AD rights for service accounts is a common problem across all of SharePoint.

    What Dave describes is one possibility where an AD configuration could cause this issue. As we discover more potential AD configurations that could cause this issue, we will try to update this list. If you are comfortable building your own test application and have gotten this far without figuring it out (and feel very confident that it is not #1), you can try running the test application we have posted here to manually test your ability to acquire a Windows Identity.

Hopefully this list will help you quickly debug and fix this issue on your system. HTH

Lee

First, Excel Services requires that a domain controller be available for data access when using Windows authentication for a connection (see my earlier posting, http://powerpivotgeek.com/2009/11/06/taking-your-server-off-the-network/). Interestingly it isn’t Excel Services specifically that has this requirement, rather it is the SharePoint infrastructure component called the Geneva Token Service (GTS) that Excel Services uses requires access to the domain controller for a S4U logon to impersonate the Windows user. S4U cannot use cached credentials.

The second restriction is also a consequence of GTS. GTS requires that all domains have two-way trust relationships in order to perform its logons. A common old-style domain configuration is to have a single dedicated “account” domain (where users live) – and then multiple “resource” domains (where your servers, printers and other resources live). Typically the resource domains trust the account domain; but the account domain does not trust the resource domains (a so-called ‘one-way trust’). Service accounts live in the resource domains and thus do not have account-level access. This is a good thing. Many of the Microsoft lab domains work this way. Unfortunately if you install SharePoint in such an environment, you will find that Excel Services returns an error: “The data connection uses Windows Authentication and Excel Services is unable to delegate user credentials.“ SharePoint requires a two-way trust between domains if your machine lives in one domain and your users live in another.