The Named Pipes Had a Party and Imposters Were Not Invited
Don't pretend to be anyone, it can lead to disastrous consequences!
I learned this the hard way this week with PowerShell remoting and WCF's named pipes.
As my current company had a large amount of integration tests that needed to be executed via scripting. I created a c# commandlet wrapper around vstest.console.exe that composed the test category query, copied dependencies, published the results etc. This was then to be called remotely using PowerShell remoting.
I mostly followed Keith Hill's blog post on how to set up credssp and delegate credentials, in a similar fashion to Kerberos.
vstest.console.exe starts up one or many vstest execution engine processes in clr2/clr4 and x86/x64 flavours, depending on the configurations passed and the test category query string. The parent process communicates with the child processes via wcf named pipes in the format net.pipe:///TestExecutor/.
After running the script everything appeared to work as designed, except when reviewing the child process with taskmanager and procmon, the child process named vstestexecutionengine.exe would only stay up for 60 seconds and the memory would not increase much over the base instantiation of 8MB. Based on when I had run the tests locally on the machine, the memory consumption should have sky rocketed.
The 60 second timeout was a total read herring and led me down the path of investigating all sorts of wsman client and server timeouts and memory maximums and PSSession timeout properties, based on the surface evidence that I had this seemed like a sound approach. Not a chance...
I then modified the C# commandlet to verbose log all of the standard output and standard errors from the vstest console process and this yielded the result that led me to the solution.
"Error: Failed to initialize client proxy: could not connect to .
Error: There was no endpoint listening at net.pipe://localhost/TestExecutor/4504 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."
I found an enlightening blog post from someone called Kenny W on the subject that finally gave me the answer.
"User tokens that are marked with an impersonate flag* are placed in the NETWORK USER group, its SID is explicitly denied access to WCF named pipes, as a security design concept"
*using Kerberos/Credssp/some other credential delegation authentication protocol
In the end to allow me to remotely start up the processes within the commandlet I had to psexec (sysinternals) as system. Not elegant, but the only workaround I had available.
Useful Links: