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

Setting the endpoint identity on the client side will not help you, as the issue is the security context in which your client code is executing, not the configuration of the endpoint. As KennyW explains, if you access the SharePoint application using the full domain name of the machine, the impersonation token in the web server process (which provides your SharePoint user identity under Windows authentication) will be obtained via Kerberos and have membership of the NETWORK USERS group. If you use just the machine name, the optimization Kenny refers to gets you a logon token via NTLM which is not in the NETWORK USERS group and is therefore not denied access by the ACLs which WCF puts both on the pipe and on the shared memory object where the server publishes the actual pipe name.

The error There was no endpoint listening at net.pipe://localhost... does not necessarily mean that there is no WCF service listening on such a named pipe endpoint: it can also (and in this case does) mean that although there is one, you don't have sufficient access rights to know about it, because you have a remote logon.

Answer 2

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.