Verifying whether the broken piece is c2WTS or Active Directory

If you have tried my tool to troubleshoot c2WTS with SharePoint, c2WTSTester, verified that the service is running as expected, the account used by SharePoint is valid in c2WTS but you still failed to receive a valid token for some error that does not make much sense, fear no more. It may be that c2WTS is not the problem but rather a victim of some Active Directory misfortune. In the cases I supported where the problem was not c2WTS misconfiguration, the two main reasons were:

2. Customer is running c2WTS service under SYSTEM or NETWORK credentials and when c2WTS is called the machine is kicked off from the domain and the connection is only re-established when the machine is rebooted. This happens specially in Virtual Machines or restored machines because the generated password for the machine does not match the password in one or more domain controllers (NETWORK and SYSTEM identify in the network as DOMAIN\MACHINAME$ and passes a previously exchanged random password created when the machine joins). This error is the worst for it may happen randomly (DCs in round-robin and the one with bad password happens to be the one authenticating at the time). This problem can be resolved by rejoining the domain or resetting the machine password: http://support.microsoft.com/kb/325850

Identifying the problem

c2WTS is a wrapper for the Windows API function LsaLogonUser which cannot be called from a process that is not running in full trust (as sandboxed or non-administrative SharePoint pages). .NET offers an interface to this API function via WindowsIdentity constructor which also requires full trust. So, in order to applications running in less privilege to acquire a token based on a UPN, a middleware service running in full trust acquire the token in its behalf. This service as you may have imagined is the Claims to Windows NT Token Service (c2WTS). The full service wrapper will eventually at some point just run this code impersonating the service account (which by default is SYSTEM):

As a wrapper c2WTS includes some overhead that may difficult the identification of the main problem. So, c2WTSTester will identify the common wrapper problems (service configuration and access to the service) but it will return a generic error if the problem is in Active Directory configuration.

I put together a new test application that bypasses c2WTS and emulates the core functionality: the token acquisition based on the provided upn. I am listing the code below and at the end I provide a link to download the application executable and the source code if you are interested in modifications. Besides testing the name resolution, it also helps identify Kerberos delegation problems as it lets you choose a target to be reached by the acquired token. It accepts either a URL (http or https) or a share (starting with \\). If you wish to test a WCF service, modify the source code to add a reference to the service, create a proxy and call a method.

Another common scenario is to run c2WTS as SYSTEM or NETWORK. In this case, please download psexec from SysInternals here: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and run this command in a elevated command prompt to open another command prompt as SYSTEM account:
c:\sysinternals\psexec64 \\localhost -s -i cmd.exe OR c:\sysinternals\psexec \\localhost -s -i cmd.exe for 32-bits systems. From this command prompt run the application.