Setting SPN on endpointaddress for NetNamedPipe service endpoint

Question

I'm getting the "There was no endpoint listening at net.pipe://localhost" error as described in other places but I cannot seem to find a real answer.

This is a great identifier of the problem: http://kennyw.com/indigo/102

When using WCF, Windows authentication is performed through SSPI-Negotiate, which in most cases will select Kerberos as the actual authentication mechanism. However, if the target SPN passed to SSPI is a well formed SPN for the local computer account (e.g. host/[dns machine name]) then Negotiate will use NTLM (loopback optimization) and the access token will not have the Network SID (and therefore will be usable with NetNamedPipes).

But it doesn't tell me how to resolve the issue. I am creating my endpoint programmatically.

var binding = new NetNamedPipeBinding();
binding.Security.Mode = NetNamedPipeSecurityMode.Transport;
binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;

var id = EndpointIdentity.CreateSpnIdentity("host/" + Environment.MachineName);
var endpointAddress = new EndpointAddress(new Uri(serviceClientUrl), id);

var client = new ServiceClient(binding, endpointAddress);

I'm guessing that my issue is in the CreateSpnIdentity but I'm not sure what value to use.

Additional Info: To elaborate on this for more context. The Wcf service is hosted as a Windows Service running under the NetworkService account (I've tried Local System). The service is created using the default NetNamedPipeBinding constructor:

host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");

I've created a SharePoint webpart that uses this service. The kicker is that if the SharePoint site is set to forms based authentication or just the machine name is used in the url under Windows Authentication then there are no issues. ONLY if the fully qualified machine name is used for the url under Windows authentication do I get the above error.

I'm pretty sure this has to do with the NTLM Kerberos issues descibed in the article but I'm not sure how to get around it.

Answer 1

NamedPipe has been made a pain in the backside after Hardening: http://msdn.microsoft.com/en-us/library/bb757001.aspx It actually made me change from NamedPipe to TCP while I needed to communicate on the same machine.

Now this does not mean this is your problem. If you are running under one account and trying to connect under a different account, this will usually fail since named pipes are no longer created as global (unless it is LocalSys).

My suggestion is:

1) Eliminate all security from your service. After all, NamedPipe runs on the same machine and I believe normally no security should be needed. 2) Try connecting. if it fails, use SysInternals ProcExplorer to see what objects process has started. If it has a named pipe then it is the hardening.

If you give more info I should be able to help you more.