Why does an IpcChannel tell me, "Cannot open an anonymous level security token?"

Question

I have a pretty simple client-server app that I am using to separate two components that can't live together in the same process. When developing them (the server is an exe, the client is a library), all my unit tests are happy as pigs in manure. When I move on to re-using the library elsewhere, I get the following exception:

System.Runtime.Remoting.RemotingException: An error occurred while processing the request on the server: System.Security.SecurityException: Cannot open an anonymous level security token.

   at System.Security.Principal.WindowsIdentity.GetCurrentInternal(TokenAccessLevels desiredAccess, Boolean threadOnly)
   at System.Security.Principal.WindowsIdentity.GetCurrent()
   at System.Runtime.Remoting.Channels.Ipc.IpcServerTransportSink.ServiceRequest(Object state)
The Zone of the assembly that failed was:
MyComputer.

I have set up the remoting on both sides in code, rather than config files for simplicity at this stage. They are effectively identical:

BinaryClientFormatterSinkProvider client = new BinaryClientFormatterSinkProvider();
BinaryServerFormatterSinkProvider server = new BinaryServerFormatterSinkProvider();
server.TypeFilterLevel = TypeFilterLevel.Full;

Hashtable config = new Hashtable();
config["name"] = "SomeName";
config["portName"] = "SomePortName";

config["typeFilterLevel"] = "Full";
config["impersonate"] = "true";
config["tokenImpersonationLevel"] = "Impersonation";
config["useDefaultCredentials"] = "True";
config["secure"] = "True";

Channel = new IpcChannel(config, client, server);

So the question is: Why would the remoting framework want to create an anonymous token when impersonation is enabled? I've completely run out of places to look for answers on this.

Answer 1

I also have this problem and can confirm that it happens only with secure channels with impersonation enabled.

I posted here: http://social.msdn.microsoft.com/Forums/en-US/netfxremoting/thread/b612c035-464d-4346-a075-dc2b784e8a70

... but I also haven't received a response, yet. Still looking for answers - this is a major show-stopper in our application.

Have you managed to resolve this issue, yet?